Programmation événementielle : exercices corrigés de Terminale SI

Rappelle ce qui compte comme événement : une action de l'opérateur (clic, saisie au clavier, déplacement de souris) ou un changement d'état de variable ⁵.

Teste a : un clic sur un bouton est une action de l'opérateur. C'est un événement.

Teste c : la saisie au clavier est citée parmi les événements. C'est un événement.

Teste d : le déplacement de la souris en est un aussi, même si le programme choisit de l'ignorer ensuite. C'est un événement.

Teste e : un changement d'état de variable fait partie des événements possibles ⁵. C'est un événement.

Écarte b et f : ce sont des instructions ordinaires, exécutées quand le programme les atteint. Rien d'extérieur ne les déclenche, elles relèvent d'un déroulement séquentiel.

Rappelle la structure : la boucle principale comporte une section qui détecte les événements et une section qui les gère ⁵.

Liste les événements de la période : 3 clics, 12 frappes, 5 déplacements.

Additionne, puisque chacun est géré une fois : $3 + 12 + 5 = 20$.

Réponds à la question 2 : c'est la section de détection qui repère la frappe ; la section de gestion n'intervient qu'ensuite pour réagir.

Identifie les deux événements et leur gestionnaire : un clic sur « plus » modifie l'état n de +1, un clic sur « moins » le modifie de −2. Le programme est défini par ces réactions ⁵.

Calcule l'effet des 7 clics « plus » : $7 \times 1 = 7$.

Calcule l'effet des 3 clics « moins » : $3 \times (-2) = -6$.

Additionne à la valeur de départ : $0 + 7 - 6 = 1$.

Question 2 : sans plancher, les modifications s'additionnent, et l'addition ne dépend pas de l'ordre. Le résultat est donc toujours 1.

Question 3 : avec le plancher à 0, la suite « moins, puis plus » donne 0 puis 1, alors que « plus, puis moins » donne 1 puis 0 (le résultat −1 est ramené à 0). L'ordre compte désormais.

Calcule le nombre de tests de la solution A : $\dfrac{60}{0{,}5} = 120$.

Retire les tests qui ont détecté un appui : $120 - 4 = 116$ tests ne détectent rien.

Pour la solution B, le gestionnaire ne s'exécute qu'à la réception d'un événement : il s'exécute 4 fois ⁵.

Compare : la solution A relève du déroulement séquentiel, auquel s'oppose la programmation événementielle ⁵. Ici, le programme événementiel se définit par ses réactions, pas par une vérification permanente.

Pars de l'état initial : consigne = 19,0.

Traite les événements un à un, dans l'ordre d'arrivée : plus → 19,5 ; plus → 20,0 ; plus → 20,5 ; moins → 20,0.

Traite reset : la consigne est réaffectée à 19,0, quelle que soit sa valeur précédente.

Traite les deux derniers : moins → 18,5 ; moins → 18,0.

Réponds à la question 3 : le gestionnaire de reset remplace la valeur au lieu de la modifier. L'état avant lui n'a donc plus d'influence sur la suite.

Pose l'hypothèse : un traitement n'est pas interrompu par l'arrivée d'un autre événement ⁵. Les gestionnaires se suivent donc sans chevauchement.

Cumule les durées avant « Stop » : $15 + 40 + 25 = 80$ ms. Le traitement de « Stop » commence à $t = 80$ ms.

Ajoute la durée de son gestionnaire : $80 + 10 = 90$ ms. Il se termine à $t = 90$ ms.

Interprète : l'ordre de traitement impose 80 ms d'attente avant même de commencer l'arrêt. Pour un ordre de sécurité, c'est lent : on cherche à raccourcir les gestionnaires qui précèdent ou à placer l'arrêt en tête.

Retiens que cette approche ne dit rien sur la durée réelle des gestionnaires : ces valeurs sont des données de l'énoncé, que l'on mesurerait sur le système.

Rappelle la règle : tant qu'un gestionnaire s'exécute, il n'est pas interrompu par un autre événement ⁵. Les saisies sont mises en attente.

Calcule l'accumulation : $2 \times 5 = 10$ événements en attente à la fin de l'export.

Décris le symptôme : l'interface semble figée, car la section de gestion ne reprend la main qu'à la fin du gestionnaire ; les 10 saisies sont traitées d'un coup ensuite.

Choisis une correction : découper l'export en lots courts (par exemple 100 lignes par appel) et relancer le lot suivant par un nouvel événement, afin que les saisies passent entre deux lots.

Vérifie la cohérence : chaque lot est un petit gestionnaire, la boucle principale peut alors détecter et traiter les saisies entre deux lots.

Liste les événements : appui sur la télécommande, détection d'obstacle, fin de course « ouvert », fin de course « fermé ». Ce sont des changements d'état du système qui déclenchent des réactions, et le programme se définit par elles ⁵.

Associe les gestionnaires : télécommande → lancer l'ouverture ou la fermeture selon l'état ; obstacle → arrêter le moteur ; fin de course ouvert → couper le moteur et passer l'état à « ouvert » ; fin de course fermé → couper le moteur et passer l'état à « fermé ».

Identifie l'état à mémoriser : une variable etat valant « ouvert », « fermé », « en ouverture » ou « en fermeture ». Sans elle, le même bouton ne saurait pas quoi faire.

Calcule le débit maximal : $1\,000 \text{ ms} \div 8 \text{ ms} = 125$ événements par seconde, puisque les traitements ne se chevauchent pas ⁵.

Justifie la question 4 : un événement d'obstacle arrive parmi d'autres ; plus les gestionnaires qui le précèdent sont longs, plus l'arrêt du moteur est retardé. Un gestionnaire d'obstacle court, qui ne fait que couper le moteur, limite ce délai.