IHM, événements et démarche de projet
Tu réserves une place de TER sur ton téléphone : tu touches un bouton, la page change, ton billet arrive. Qui a « entendu » ton clic ? Que se passe-t-il entre ton téléphone et le serveur de la SNCF ? Et comment une équipe d'élèves peut-elle fabriquer une application comme celle-là sans se perdre ? Voilà les trois questions de cette page.
Composants graphiques et événements
Une IHM (interface homme-machine) est ce qui permet à l'utilisateur de dialoguer avec un programme : fenêtre, page web, écran tactile.
Une interface est construite avec des composants graphiques (on dit aussi widgets) :
| Composant | Rôle |
|---|---|
| bouton | déclencher une action |
| zone de saisie | écrire du texte |
| case à cocher, bouton radio | choisir une ou plusieurs options |
liste déroulante (<select>) |
choisir dans une liste |
| étiquette (label) | afficher un texte |
Le programme n'attend pas dans un ordre fixé : c'est l'utilisateur qui décide. On parle de programmation événementielle. Un événement est une action de l'utilisateur ou du système : clic, appui sur une touche, survol, fin d'un délai.
À chaque événement qu'on veut traiter, on associe une fonction : la fonction de rappel (callback). Le programme la lance tout seul quand l'événement se produit. Le programme principal se termine par une boucle d'événements qui attend et distribue les événements.
En Python, la bibliothèque tkinter permet de créer une IHM. Voici un exemple minimal :
import tkinter as tk
def clic():
etiquette.config(text="Bonjour " + saisie.get())
fenetre = tk.Tk()
saisie = tk.Entry(fenetre)
bouton = tk.Button(fenetre, text="Saluer", command=clic)
etiquette = tk.Label(fenetre, text="")
saisie.pack()
bouton.pack()
etiquette.pack()
fenetre.mainloop()
Ici command=clic associe la fonction clic à l'événement « clic sur le bouton ». Remarque : on écrit clic et non clic() : on donne la fonction, on ne l'exécute pas tout de suite.
Dans une interface graphique, on distingue des composants (widgets) et des événements. a) Citer trois composants graphiques usuels (par exemple : bouton, zone de saisie,…
Dans une interface graphique, on distingue des composants (widgets) et des événements.
- a) Citer trois composants graphiques usuels (par exemple : bouton, zone de saisie, case à cocher).
- b) Citer trois événements qu'un utilisateur peut déclencher.
- c) Expliquer en une phrase le rôle d'une fonction de rappel (callback) associée à un bouton.
On souhaite réaliser avec tkinter une petite IHM de conversion d'euros en dollars (taux : 1 € = 1,08…
On souhaite réaliser avec tkinter une petite IHM de conversion d'euros en dollars (taux : 1 € = 1,08 $).
- a) Lister les composants nécessaires (étiquette, zone de saisie, bouton, zone d'affichage).
- b) Décrire l'événement qui déclenche le calcul et la fonction de rappel associée.
- c) Écrire la fonction de rappel qui lit la valeur saisie, calcule la conversion et gère le cas d'une saisie non numérique.
Interaction sur le Web : HTML, JavaScript et requêtes HTTP
Sur le Web, l'interface est une page. On sépare deux choses :
-
HTML décrit la page et ses composants (
<form>,<input>,<button>,<select>) ; -
JavaScript programme le comportement : il réagit aux événements (
onclick, etc.).
<button id="reserver">Réserver</button>
Un script JavaScript associe à l'événement click de ce bouton une fonction de rappel. Cette fonction s'exécute en réaction au clic. Le script s'exécute dans le navigateur (le client). Mais certaines actions nécessitent le serveur : enregistrer une réservation, vérifier un mot de passe. Le navigateur envoie alors une requête HTTP et le serveur renvoie une réponse.
Un formulaire envoie les données saisies :
<form action="/inscription" method="post">
<input type="text" name="nom">
<input type="email" name="mail">
<input type="submit" value="Valider">
</form>
L'attribut action donne la ressource visée, method la méthode, et chaque name désigne un paramètre.
Pourquoi deux méthodes ? GET sert à demander une page (une recherche, un lien partageable). POST sert à envoyer des données qui modifient quelque chose ou qui sont confidentielles (connexion, inscription).
La réponse du serveur contient un code de statut et, en général, une page. 200 signifie « OK, la requête a réussi » ; 404 « ressource introuvable » ; 500 « erreur du serveur ».
Le S de HTTPS signifie secure : les échanges entre le navigateur et le serveur sont chiffrés. Un attaquant qui écoute le réseau d'un café (Wi-Fi public) voit qu'on contacte le site, mais ne peut pas lire les données échangées. HTTPS ne protège pas contre un site malhonnête, ni contre un ordinateur infecté, ni contre un serveur mal programmé : le chiffrement ne garantit que le transport.
Un formulaire web envoie des données à un serveur avec la méthode GET ou POST. a) Indiquer laquelle de ces deux méthodes place les données dans l'URL. b) Pour un…
Un formulaire web envoie des données à un serveur avec la méthode GET ou POST.
- a) Indiquer laquelle de ces deux méthodes place les données dans l'URL.
- b) Pour un formulaire de connexion avec mot de passe, quelle méthode choisir ? Justifier.
- c) Que signifie le « S » de HTTPS et quel est son intérêt ?
Une page web contient le formulaire suivant : a) Quelle requête HTTP est envoyée lors de la validation ? Où se trouvent les données ? b) Quelle serait l'URL de la…
Une page web contient le formulaire suivant :
<form action="/inscription" method="post">
<input type="text" name="nom">
<input type="email" name="mail">
<input type="submit" value="Valider">
</form>
- a) Quelle requête HTTP est envoyée lors de la validation ? Où se trouvent les données ?
- b) Quelle serait l'URL de la requête si la méthode était
get, avecnomvalantDupontetmailvalantd@ex.fr?
- c) Expliquer ce que le serveur renvoie en réponse et le rôle du code de statut 200.
On étudie un site de réservation de billets de train de la région Occitanie. a) Expliquer pourquoi transmettre un numéro de carte bancaire par GET est dangereux, même en…
On étudie un site de réservation de billets de train de la région Occitanie.
- a) Expliquer pourquoi transmettre un numéro de carte bancaire par GET est dangereux, même en HTTPS.
- b) Expliquer ce que HTTPS protège effectivement contre un attaquant qui écoute le réseau d'un café, et ce qu'il ne protège pas.
- c) Citer une vérification à faire côté serveur même si le formulaire contrôle déjà les champs côté navigateur, et justifier.
Une IHM pas à pas : le jeu du morpion
Une IHM a besoin d'un état mémorisé entre deux événements. Pour un morpion (grille 3 × 3) :
-
grille: tableau de tableaux contenant"","X"ou"O"; -
joueur: le joueur dont c'est le tour ; -
fini: un booléen indiquant si la partie est terminée.
Événements : un clic sur chacune des 9 cases. La fonction de rappel clic(i, j) reçoit la position de la case.
Pour détecter un gagnant, on parcourt les lignes, les colonnes et les deux diagonales :
def gagnant(grille):
lignes = []
for i in range(3):
lignes.append(grille[i])
lignes.append([grille[0][i], grille[1][i], grille[2][i]])
lignes.append([grille[k][k] for k in range(3)])
lignes.append([grille[k][2 - k] for k in range(3)])
for l in lignes:
if l[0] != "" and l[0] == l[1] == l[2]:
return l[0]
return None
Et la fonction de rappel, qui traite tous les cas :
def clic(i, j):
global joueur, fini
if fini or grille[i][j] != "":
return # coup refusé
grille[i][j] = joueur
boutons[i][j].config(text=joueur)
if gagnant(grille) is not None:
fini = True
else:
joueur = "O" if joueur == "X" else "X"
On modélise une IHM de jeu du morpion (grille 3 × 3) par un tableau de tableaux grille contenant "", "X" ou "O", et un bouton par case. a) Décrire les événements à gérer…
On modélise une IHM de jeu du morpion (grille 3 × 3) par un tableau de tableaux grille contenant "", "X" ou "O", et un bouton par case.
- a) Décrire les événements à gérer et l'état à mémoriser (joueur courant, fin de partie).
- b) Écrire une fonction
gagnant(grille)qui renvoie"X","O"ouNone.
- c) Écrire la fonction de rappel
clic(i, j)qui joue un coup si la case est libre, en précisant les cas à traiter.
Démarche de projet
Au moins un quart de l'horaire de NSI est consacré à des projets menés en équipe de 2 à 4 élèves. Un projet se prépare.
Ce qui n'en fait pas partie : une décision de détail prise après les tests (la couleur d'un bouton) ou le nom de la personne qui code la page d'accueil (c'est de l'organisation).
Ensuite on :
-
découpe le projet en tâches (interface, logique, données, tests) et on les répartit ;
-
fixe des jalons (points d'étape) avec un critère de validation chacun ;
-
teste : chaque exigence du cahier des charges doit avoir au moins un test ;
-
travaille en équipe : gestion de versions du code (par exemple Git), revues de code croisées, réunions courtes ;
-
évalue l'écart entre le résultat final et le cahier des charges : pour chaque exigence, atteinte, partielle ou non atteinte.
Une mairie de Strasbourg souhaite une application de réservation de salles. Parmi les éléments suivants, indiquer ceux qui relèvent du cahier des charges : (1) la liste…
Une mairie de Strasbourg souhaite une application de réservation de salles. Parmi les éléments suivants, indiquer ceux qui relèvent du cahier des charges : (1) la liste des fonctionnalités attendues, (2) le choix de la couleur d'un bouton après les tests, (3) les contraintes de délai, (4) le nom du développeur chargé de la page d'accueil, (5) les utilisateurs visés.
Une équipe de trois élèves d'un lycée de Bordeaux conçoit un jeu de quiz en Python. a) Rédiger un court cahier des charges (quatre exigences au moins). b) Proposer un…
Une équipe de trois élèves d'un lycée de Bordeaux conçoit un jeu de quiz en Python.
- a) Rédiger un court cahier des charges (quatre exigences au moins).
- b) Proposer un découpage en tâches avec une répartition entre les trois élèves.
- c) Décrire deux tests qui permettent de vérifier que le projet respecte le cahier des charges.
Un projet de calendrier partagé pour le club de théâtre d'un lycée de Nantes est confié à quatre élèves pendant huit semaines. a) Rédiger le cahier des charges…
Un projet de calendrier partagé pour le club de théâtre d'un lycée de Nantes est confié à quatre élèves pendant huit semaines.
- a) Rédiger le cahier des charges fonctionnel (fonctionnalités, contraintes, utilisateurs).
- b) Proposer un calendrier de projet avec jalons et critères de validation pour chaque jalon.
- c) Expliquer comment organiser le travail collaboratif (versions du code, répartition, revues) et comment évaluer l'écart entre le résultat final et le cahier des charges.
Retour au début : le clic sur « Réserver » déclenche un événement, une requête POST chiffrée en HTTPS part vers le serveur, qui répond avec un code de statut ; et l'application a été construite à partir d'un cahier des charges.