2. Programmation orientée événements
 

ous les versions actuelles de Windows, système multi-tâches préemptif sur micro-ordinateur, les concepts quant à la programmation par événement restent sensiblement les mêmes que sous les anciennes versions.

Nous dirons que le système d’exploitation passe l’essentiel de son " temps " à attendre une action de l’utilisateur (événement). Cette action déclenche un message que le système traite et envoie éventuellement à une application donnée.

Une définition de la programmation orientée événement :
Logique selon laquelle un programme est construit avec des objets et leurs propriétés et d’après laquelle seules les interventions de l’utilisateur sur les objets du programme déclenchent l’exécution des routines associées.


Par la suite nous allons voir dans de ce chapitre que la programmation d’une application " windows-like " est essentiellement une programmation par événements associée à une programmation classique.

Nous pourrons construire un logiciel qui réagira sur les interventions de l’utilisateur si nous arrivons récupérer dans notre application les messages que le système envoie. Or l’environnement Delphi de Borland, comme d’ailleurs avant lui le Visual Basic de Microsoft, autorise la consultation de tels messages d’un façon simple et souple.
 
  • L’approche événementielle intervient principalement dans l’interface entre le logiciel et l’utilisateur, mais aussi dans la liaison dynamique du logiciel avec le système, et enfin dans la sécurité.
  • L’approche visuelle nous aide et simplifie notre tâche dans la construction du dialogue homme-machine.
  • La combinaison de ces deux approches produit un logiciel habillé et adapté au système d’exploitation.

 
Il est possible de relier certains objets entre eux par des relations événementielles. Nous les représenterons par un graphe (structure classique utilisée pour représenter des relations).

Lorsque l’on utilise un système multi-fenêtré du genre windows, l’on dispose du clavier et de la souris pour agir sur le système. En utilisant un RAD visuel, il est possible de construire un logiciel qui se comporte comme le système sur lequel il s’exécute. L’intérêt est que l’utilisateur aura moins d’efforts à accomplir pour se servir du programme puisqu’il aura des fonctionnalités semblables au système. Le fait que l’utilisateur reste dans un environnement familier au niveau de la manipulation et du confort du dialogue, assure le logiciel d’un capital confiance de départ non négligeable.
 

  

3. Normalisation du graphe événementiel
 
PanneauProgEvenement.dif

Il n’existe que peu d’éléments accessibles aux débutants sur la programmation orientée objet par événements à cause de la nouveauté du terrain d’activité. Nous construisons une démarche méthodique en partant de remarques simples que nous décrivons sous forme de schémas dérivés des diagrammes d'états d'UML. Ces schémas seront utiles pour nous aider à décrire et à implanter des relations événementielles en Delphi et dans un autre RAD événementiel.

 
Voici deux remarques qui pour l’instant sont suffisantes à nos activités de programmation. Dans une interface windows-like nous savons que:
 
  • Certains événements déclenchent immédiatement des actions comme par exemple des appels de routines système.
  • D’autres événements ne déclenchent pas d’actions apparentes mais activent ou désactivent certains autres événements système.

Nous allons utiliser ces deux remarques pour conduire notre programmation par événements. Nous commencerons par le concept d’activation et de désactivation, les autres événements fonctionnant selon le même principe. Dans un enseignement sur la programmation événementielle, nous avons constaté que ce concept était suffisant pour que les étudiants comprennent les principes de l’approche événementielle.
     
    Cette notation de graphe événementiel est destinée à s'initier à la pratique de la description d'au maximum 4 types de réactions d'un objet sur la sollicitation d'un seul événement.

    Remarques :
    • L'arc nommé, représentant l'activation d'une méthode correspond très exactement à la notation UML de l'envoi d'un message.

      •  
    • Lorsque nous voudrons représenter d'une manière plus complète d'autres réactions d'un seul objet à plusieurs événements différents, nous pourrons utiliser la notation UML réduite de diagramme d'état pour un objet (réduite parce qu'un objet visuel ne prendra pour nous, que 2 états: activé ou désactivé).

     

    3.2 les diagrammes d'états UML réduits

    Nous vous livrons ci-dessous la notation générale de diagramme d'état en UML, les cas particuliers et les détails complets sont décrits dans le document de spécification d'UML.


     

    Voici les diagrammes d'états réduits extraits du graphe événementiel précédent, pour les objets Evt-1 et Evt-2 :

    ..... etc...

    Nous remarquerons que cette écriture, pour l'instant, ne délivre pas plus de sens que le graphe précédent qui comporte en sus la vision globale des interrelations entre les objets.

    Ces diagrammes d'états réduits deviennent plus intéressants lorsque nous voulons exprimer le fait par exemple, qu'un seul objet Obj1 réagit à 3 événements (événement-1, événement-2, événement-3). Dans ce cas décrivons les portions de graphe événementiel associés à chacun des événements :

    Réaction de obj1 a l'événement-1 :

    Réaction de obj1 a l'événement-2 :


     

    Réaction de obj1 a l'événement-3 :

    Synthétisons dans un diagramme d'état réduit les réactions à ces 3 événements :

    Lorsque nous jugerons nécessaire à la compréhension de relations événementielles dans un logiciel visuel, nous pourrons donc utiliser ce genre de diagramme pour renforcer la sémantique de conception des objets visuels. La notation UML sur les diagrammes d'états comprend les notions d'état de départ, de sortie, imbriqué, historisé, concurrents...

    Lorsque cela sera nécessaire nous utiliserons la notation UML de synchronisation d'événements :
     
    ev1      ev2

        ev3    		     ev4

    ev5     ev6

    schéma :
    schéma :




    4. Tableau des actions événementielles

    L’exemple de graphe événementiel précédent correspond à une application qui serait sensible à 5 événements notés EVT-1 à EVT-5, et qui exécuterait 3 procédures utilisateur. Nous notons dans un tableau (nommé " tableau des actions événementielles ")les résultats obtenus par analyse du graphe précédent, événement par événement..
     
    EVT-1
    EVT-3 activable

    EVT-4 activable
    EVT-2
    		 Appel de procédure utilisateur "chargement-1"

    désactivation de l’ événement EVT-2
    EVT-3
    		 Appel de procédure utilisateur "Analyser"

    EVT-2 activable
    EVT-4 EVT-2 désactivé 

    EVT-5 activable
    EVT-5 EVT-4 désactivé immédiatement

    Appel de procédure utilisateur "chargement-2"

    Nous joignons à ce tableau une table des états des événements dès le lancement du logiciel (elle correspond à l’état initial des objets). Par exemple ici :
     
    Evt1 activé
    Evt2 désactivé
    Evt3 activé
    Evt4 activé
    Evt5 désactivé 

    etc...
     
     

    5. Interfaces liées à un graphe événementiel

    construction d’interfaces liées au graphe précédent
     

    Elaborons maintenant à partir du graphe événementiel précédent, une interface windows-like (construite avec des objets Delphi) qui lui soit associée :
     
    Dans l’exemple de droite,(i1,i2,i3,i4,i5)est une permutation sur (1,2,3,4,5) .
     
     

    Ce qui nous donne déjà 5!=120 interfaces possibles avec ces objets et uniquement avec cette topologie. 

         		Interface n°1 

    La figure précédente montre une IHM (construite avec des objets Delphi) à partir du graphe événementiel étudié plus haut. Ci-dessous deux autres structures d’interfaces possibles avec les mêmes objets combinés différemment et associés au même graphe événementiel :
     


              Interface n°2
              Interface n°3

    Pour les choix n°2 et n°3, il y a aussi 120 interfaces possibles)…
     
     

6. Avantages et modèle de développement RAD visuel

L’approche uniquement structurée (privilégiant les fonctions du logiciel) impose d’écrire du code long et compliqué en risquant de ne pas aboutir, car il faut tout tester afin d’assurer un bon fonctionnement de tous les éléments du logiciel.

L’approche événementielle préfère bâtir un logiciel fondé sur une construction graduelle en fonction des besoins de communication entre l’humain et la machine. Dans cette optique, le programmeur élabore les fonctions associées à une action de communication en privilégiant le dialogue. Ainsi les actions internes du logiciel sont subordonnées au flux du dialogue.
 
 

Avantages liés à la programmation par RAD visuel
 

  • Il est possible de construire très rapidement un prototype.
  • Les fonctionnalités de communication sont les guides principaux du développement (approche plus vivante et attrayante).
  • L’étudiant est impliqué immédiatement dans le processus de conception - construction.
  • L’étudiant acquiert très vite comme naturelle l’attitude de réutilisation en se servant de " logiciels en kit " (soit au début des composants visuels ou non, puis par la suite ses propres composants).
  • Il n’y a pas de conflit ni d’incohérence avec la démarche structurée : les algorithmes étant conçus comme des boîtes noires permettant d’implanter certaines actions, seront réutilisés immédiatement.
  • La méthodologie objet de COO et de POO reste un facteur d’intégration général des activités du programmeur.
  • Les actions de communications classiques sont assurées immédiatement par des objets standards (composants visuels ou non) réagissant à des événements extérieurs.
  • Le RAD fournira des classes d’objets standards non visuels (extensibles si l’étudiant augmente sa compétence) gérant les structures de données classiques (Liste, arbre, etc..). L’extensibilité permet à l’enseignant de rajouter ses kits personnels d’objets et de les mettre à la disposition des étudiants comme des outils standards.
    •       

    Modèles de développement avec un RAD visuel objet

    Le développement avec ce genre de produit autorise une logique générale articulée sur la combinaison de deux modèles de développement :
     
     

    6.1 le modèle de la spirale (B.Boehm) en version simplifiée


    Modèle dans lequel la programmation exploratoire est utilisée sous forme de prototypes simplifiés cycle après cycle. L'analyse s'améliore au cours de chaque cycle et fixe le type de développement pour ce tour de spirale.
     
     

    6.2 le modèle incrémental

    Qui permet de réaliser chaque prototype avec un bloc central au départ, s'enrichissant à chaque phase de nouveaux composants et ainsi que de leurs interactions. Associé à un cycle de prototypage dans la spirale, une seule famille de composants est développée pour un cycle fixé.
     
     
    prototype 1 :

     
     

     

    		 prototype 2 :
    prototype 3 :
    		        etc...

     

    Ce modèle de développement à l'aide d'objets visuels ou non, fournira en fin de parcours un prototype opérationnel qui pourra s'intégrer dans un projet plus général.

    Nous verrons sur des exemples comment ce type d'outil peut procurer aussi des avantages au niveau de la programmation défensive.