Programmer un système

Programmer un système revient à traduire un comportement attendu en décisions explicites. Les entrées apportent des informations : un bouton, un capteur ou un message. Les sorties commandent des actions ou renseignent l’utilisateur. L’état mémorise ce qui doit être conservé entre deux instants. Une lampe commandée par appuis successifs doit savoir si elle est déjà allumée ; la seule position actuelle du bouton ne suffit pas à déterminer son prochain état.

Un algorithme décrit les opérations et leurs règles d’enchaînement indépendamment d’un langage particulier. Un programme les exprime dans un langage exécutable. En première, l’étude du comportement séquentiel et des structures algorithmiques permet de rendre ces règles compréhensibles avant de dépendre d’une carte ou d’une bibliothèque. On définit les types des données : un booléen pour un état vrai ou faux, un entier pour un compteur, une valeur numérique avec unité pour une mesure.

La spécification indique ce que le système doit faire dans chaque situation pertinente. Pour la lampe, l’état initial est éteint. Chaque nouvel appui inverse l’état. Tant que le bouton reste maintenu, aucun nouvel événement n’est produit. Cette précision évite un comportement imprévisible : une boucle rapide qui inverse l’état à chaque lecture du bouton maintenu peut allumer et éteindre la lampe de nombreuses fois pendant un seul geste.

Un diagramme d’états-transitions représente les états et les événements qui permettent d’en changer. Il faut identifier l’état initial, lire les transitions sortantes et vérifier que les conditions ne se contredisent pas. Un état représente une situation durable ; une transition représente un changement. Les actions associées peuvent avoir lieu lors du changement ou pendant l’état, selon la convention annoncée. Le dessin ne dispense pas de préciser les règles en langage clair.

Une séquence exécute des opérations dans un ordre défini. Une condition choisit une action selon une expression booléenne. Une répétition exécute plusieurs fois un ensemble d’opérations. Une fonction rassemble un traitement identifié avec des paramètres et éventuellement un résultat. Ces structures se combinent : une boucle de commande lit les entrées, calcule une décision et actualise les sorties. L’ordre doit éviter de décider à partir de valeurs anciennes tout en affichant des valeurs nouvelles.

Une affectation remplace la valeur d’une variable ; un test d’égalité compare deux valeurs. Dans un langage comme Python, le signe simple = sert à affecter et le double == à comparer. La condition d’un algorithme doit toutefois être comprise avant sa traduction syntaxique. Pour une commande autorisée lorsque la réserve est suffisante et la demande présente, les deux conditions doivent être vraies. Le mot et désigne une conjonction ; le mot ou n’impose pas nécessairement les deux conditions.

Une condition doit traiter les valeurs limites. Pour un seuil de 30, « mesure strictement inférieure à 30 » exclut 30, alors que « inférieure ou égale à 30 » l’inclut. Il faut conserver le sens de l’exigence. Les unités doivent également correspondre : comparer un temps en millisecondes à un seuil en secondes sans conversion crée une erreur logique qui peut rester invisible dans une simple lecture du code.

Une fonction de décision peut recevoir les valeurs d’entrée et renvoyer une commande, sans modifier directement le matériel. Cette séparation permet de tester les décisions avec des données connues. Une autre partie du programme applique la commande sur la sortie appropriée. Il est alors plus facile de distinguer une erreur de logique d’une erreur de raccordement ou de conversion. Le nom de la fonction et ses paramètres doivent exprimer leur rôle.

Une commande peut être décrite par un chronogramme, qui montre sa valeur au cours du temps. Les changements de niveau doivent correspondre aux événements de la spécification. Le tracé de la lampe distingue ainsi deux instants de bascule et les périodes de maintien. La sortie logique indique l’ordre envoyé à l’éclairage ; elle ne prouve pas que la source lumineuse fonctionne effectivement. Pour observer l’effet réel, il faudrait une mesure ou une autre vérification.

La détection d’un nouvel appui peut comparer la lecture courante du bouton à la précédente. Un passage de relâché à appuyé constitue l’événement retenu. Après le traitement, on mémorise la lecture courante pour le cycle suivant. Une donnée ancienne doit être mise à jour au bon moment : l’écraser avant la comparaison ferait perdre l’information du changement. Les contacts matériels peuvent aussi présenter des rebonds ; leur traitement appartient à la mise en œuvre du dispositif choisi.

Lorsque plusieurs conditions sont vraies simultanément, il faut une règle de priorité. Considère une pompe d’exercice : une demande d’arrosage peut être vraie au moment où la réserve devient indisponible. La commande doit rester arrêtée si la présence de réserve est une condition obligatoire. Une écriture composée de plusieurs conditions indépendantes peut donner le dernier mot à la mauvaise branche. Une décision unique, calculée depuis toutes les entrées, rend la priorité visible.

Les temporisations doivent être exprimées avec une origine et une durée. Si une sortie doit rester active pendant une durée donnée après un événement, mémorise l’instant de cet événement et compare le temps écoulé au seuil. Une attente bloquante peut empêcher de lire d’autres entrées pendant ce délai. Le choix dépend donc des réactions attendues ; il ne faut pas supposer que le système observe continuellement le monde pendant qu’il attend.

Un test d’algorithme part d’un état initial et d’une suite d’entrées, puis compare les états et sorties obtenus aux valeurs attendues. Un test isolé avec toutes les conditions favorables ne suffit pas. Pour une commande à deux conditions booléennes, examine les quatre combinaisons possibles. Pour un seuil numérique, teste une valeur inférieure, l’égalité et une valeur supérieure. Pour un système à mémoire, teste aussi plusieurs événements successifs et des périodes sans événement.

La trace d’exécution note les valeurs des variables à des étapes choisies. Elle permet de comprendre une erreur d’initialisation, une inversion de condition ou une mise à jour prématurée. Il est utile d’indiquer séparément les entrées lues, l’état avant décision, l’état après décision et la sortie commandée. Cette représentation évite de confondre la valeur qui a déclenché une action avec une valeur lue plus tard.

Après correction, rejoue les anciens tests. La modification d’une branche peut résoudre un cas tout en en cassant un autre. Une simulation logique vérifie le comportement du modèle pour les cas explorés ; elle ne prouve pas que le capteur fonctionne, que les broches sont correctement raccordées ou que l’actionneur reçoit la puissance nécessaire. Les essais matériels suivent le protocole fourni et les consignes du professeur, avec des limites de fonctionnement connues.

Retrouve /exercices dans l’espace S’entraîner. Pour poursuivre, la comparaison entre simulation et expérimentation permettra de distinguer le comportement prévu du comportement réellement observé.