Skip to main content

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 32

Concevoir un programme modulaire : la conversion de devises

Recommended resources

Bonjour !

Dans la leçon précédente, nous avons exploré la stratégie "diviser pour régner" en apprenant à décomposer un problème complexe en fonctions modulaires. Vous avez vu que cette approche est la clé pour écrire des algorithmes lisibles, maintenables et robustes — des qualités essentielles pour atteindre votre objectif d'écrire du "code clean".

Aujourd'hui, nous passons de la théorie à la pratique. L'objectif de cette leçon est de mettre en application directe cette compétence de modularité. Nous allons concevoir, étape par étape, un algorithme complet mais simple : un convertisseur de devises. Nous allons spécifiquement nous concentrer sur la séparation des tâches : la saisie des données, le calcul, et l'affichage du résultat, chacune dans son propre module.

Cette leçon conclut notre module sur les fonctions et la modularité, en synthétisant tout ce que nous avons appris dans un exemple concret et pratique.

1. La Stratégie : Analyse et Décomposition

Avant d'écrire la moindre ligne de pseudo-code, un bon développeur analyse le problème et planifie sa solution. Notre problème est le suivant : "Créer un algorithme qui convertit un montant en euros (EUR) vers des dollars américains (USD) et affiche le résultat."

Appliquons une méthode structurée :

  1. Entrées (Inputs) : De quoi avons-nous besoin pour commencer ?

    • Le montant en euros que l'utilisateur souhaite convertir. C'est un nombre, probablement avec des décimales, donc de type réel.
  2. Traitement (Processing) : Quelle est la logique de transformation ?

    • La conversion elle-même. La formule est : montant_en_usd = montant_en_eur * taux_de_change. Nous utiliserons un taux de change fixe pour simplifier.
  3. Sorties (Outputs) : Quel est le résultat attendu ?

    • Un message clair affichant le montant original en EUR et le montant converti en USD.

Maintenant, décomposons ces trois phases en modules (fonctions/procédures). C'est une pratique très courante qui consiste à séparer les "préoccupations" (separation of concerns). Un module gère l'interaction avec l'utilisateur, un autre la logique métier (le calcul), et un dernier la présentation du résultat.

Cette structure est un standard en programmation. Pour vous en convaincre, je vous invite à consulter la ressource suivante qui utilise une approche identique pour un problème différent.

Chapitre 7 — La modularité et la décomposition d’un programme

L'article 'Chapitre 7 — La modularité et la décomposition d’un programme' illustre parfaitement la structure que nous allons construire. Il utilise un exemple de gestion de notes, mais le principe de décomposition est universel.

Lisez la section intitulée 'Qu’est-ce qu’un module ?'. Observez attentivement comment l'algorithme est découpé en trois fonctions logiques : LireNotes(), CalculMoyenne() et AfficherRésultat(). Nous allons suivre exactement ce modèle.


2. Conception de nos Modules

En nous inspirant de cette structure, nous pouvons définir nos propres modules pour le convertisseur de devises :

  1. SaisirMontant() : Ce module demandera à l'utilisateur le montant à convertir. Puisqu'il doit fournir une valeur (le montant) à l'algorithme principal, ce sera une Fonction qui retourne un réel.
  2. ConvertirEnUSD() : Ce module effectuera le calcul. Il a besoin du montant en EUR pour travailler (un paramètre d'entrée) et doit fournir le résultat du calcul (une valeur de retour). Ce sera donc une Fonction.
  3. AfficherResultat() : Ce module se chargera d'afficher le résultat final de manière conviviale. Il a besoin des montants de départ et d'arrivée pour les afficher, mais il n'a pas besoin de retourner une valeur à l'algorithme principal. Ce sera donc une Procédure.

L'image ci-dessous illustre le modèle d'une fonction comme ConvertirEnUSD. Elle reçoit une donnée en entrée, la traite, et renvoie une nouvelle donnée en sortie.

Modélisation d'une Fonction
Cette image schématise le rôle d'une fonction : elle prend des 'entrées' (paramètres), exécute un 'traitement' interne, et produit des 'sorties' (valeur de retour). C'est une boîte noire qui accomplit une tâche spécifique.

3. Écriture du Pseudo-code Modulaire

Maintenant que notre plan est clair, nous pouvons écrire le pseudo-code. Nous commencerons par déclarer nos constantes et nos variables globales, puis nous définirons chaque module, et enfin nous écrirons l'algorithme principal qui orchestre le tout.

// -----------------------------------------------------
// PROGRAMME : Convertisseur de Devises Modulaire
// RÔLE : Convertir un montant d'EUR en USD.
// -----------------------------------------------------

// --- Déclarations Globales ---
Algorithme ConvertisseurDevises
  // Constante pour le taux de change
  CONSTANTE TAUX_EUR_USD : réel = 1.08

  // Variables pour l'algorithme principal
  Var
    montant_eur, montant_usd : réel

// --- Définition des Modules ---

// Module 1: Saisie des données
// Rôle: Demander un montant à l'utilisateur et le retourner.
Fonction SaisirMontant() : réel
  Var
    montant_saisi : réel
  Début
    Ecrire("Veuillez saisir le montant en EUR à convertir :")
    Lire(montant_saisi)
    // Idéalement, on ajouterait une vérification pour s'assurer
    // que le montant est positif.
    Retourner montant_saisi
  FinFonction

// Module 2: Calcul de la conversion
// Rôle: Appliquer le taux de change.
// Entrée: montant_a_convertir (réel)
// Sortie: montant_converti (réel)
Fonction ConvertirEnUSD(montant_a_convertir : réel) : réel
  Début
    Retourner montant_a_convertir * TAUX_EUR_USD
  FinFonction

// Module 3: Affichage du résultat
// Rôle: Présenter le résultat à l'utilisateur.
// Entrées: m_eur (réel), m_usd (réel)
Procédure AfficherResultat(m_eur : réel, m_usd : réel)
  Début
    Ecrire(m_eur, " EUR équivaut à ", m_usd, " USD.")
  FinProcédure

// --- Corps de l'Algorithme Principal ---
Début
  // 1. Obtenir le montant de l'utilisateur en appelant le module de saisie.
  montant_eur ← SaisirMontant()

  // 2. Calculer le nouveau montant en appelant le module de conversion.
  montant_usd ← ConvertirEnUSD(montant_eur)

  // 3. Afficher le tout en appelant le module d'affichage.
  AfficherResultat(montant_eur, montant_usd)
Fin

Analyse du résultat :

Regardez le corps de l'algorithme principal (entre Début et Fin). Il est incroyablement simple et se lit presque comme une phrase en français : "Saisir un montant, le convertir, puis afficher le résultat". Toute la complexité est cachée (encapsulée) dans les modules. C'est là toute la puissance de la modularité : elle rend le code clair, logique et facile à suivre.


4. Mise en Pratique : À vous de Concevoir !

Pour vous assurer que le concept est bien ancré, je vous propose un petit exercice de conception. Vous n'avez pas besoin d'écrire tout le pseudo-code, mais simplement de réfléchir à la structure modulaire.

Le document suivant contient un exercice qui se prête très bien à la décomposition.

[PDF] Programmation

Le document '[PDF] Programmation' propose un exercice sur l'analyse de températures. C'est un cas d'étude parfait pour appliquer notre méthode de décomposition.

Dans les 'Annexes: Exercices Niveau 2', trouvez l'Exercice 10 (page 44). Lisez l'énoncé. Concentrez-vous sur les trois premières demandes : calculer la moyenne, afficher la température la plus haute, et afficher la plus basse. Comment décomposeriez-vous ce problème en fonctions/procédures ? Listez les modules que vous créeriez, leur rôle, leurs entrées (paramètres) et leur sortie éventuelle (valeur de retour).

Après avoir réfléchi, comparez votre proposition avec la solution ci-dessous.

Cliquez ici pour voir une proposition de structure modulaire

Pour résoudre le problème des températures pour une ville (en supposant que les N températures sont stockées dans un tableau), une bonne décomposition serait :

  • SaisirTemperatures(N : entier) : tableau de réels

    • Rôle : Demander à l'utilisateur de saisir N températures et les retourner dans un tableau.
    • Type : Fonction.
  • CalculerMoyenne(tab_temp : tableau de réels) : réel

    • Rôle : Parcourir le tableau, calculer la moyenne et la retourner.
    • Type : Fonction.
  • TrouverMax(tab_temp : tableau de réels) : réel

    • Rôle : Parcourir le tableau pour trouver la valeur maximale et la retourner.
    • Type : Fonction.
  • TrouverMin(tab_temp : tableau de réels) : réel

    • Rôle : Parcourir le tableau pour trouver la valeur minimale et la retourner.
    • Type : Fonction.
  • AfficherRapport(moyenne : réel, max : réel, min : réel)

    • Rôle : Afficher un résumé complet des analyses.
    • Type : Procédure.

L'algorithme principal appellerait ces fonctions successivement pour construire et afficher le rapport final.


Conclusion

Félicitations ! Vous venez de compléter le module sur les fonctions et la modularité. Vous avez non seulement appris à créer des fonctions, mais surtout à les utiliser comme des outils stratégiques pour concevoir des algorithmes propres et bien structurés.

Les points clés de cette leçon :

  • Application de la modularité : Nous avons conçu un algorithme complet en séparant les tâches de saisie, de calcul et d'affichage.
  • Conception avant codage : Analyser un problème en termes d'entrées, de traitement et de sorties est la première étape vers une solution robuste.
  • Lisibilité du code : Un algorithme principal qui orchestre des appels de fonctions est bien plus simple à comprendre et à maintenir.

Cette compétence est un pilier fondamental qui vous servira tout au long de votre parcours, particulièrement lorsque vous aborderez la programmation en Java.


Et après ?

Maintenant que nous savons comment organiser la logique de nos programmes, nous allons nous intéresser à des manières plus puissantes d'organiser nos données. La prochaine leçon débutera le module 6 et introduira une structure de données essentielle : les tableaux à deux dimensions, aussi appelés matrices. Ils sont indispensables pour travailler avec des données organisées en lignes et en colonnes, comme des grilles, des tables ou des images.