Conception modulaire : Fonctions et interactions

1. Qu'est-ce que l'Architecture Modulaire ?

Imaginez construire une voiture. Plutôt que de fabriquer une seule pièce massive, on conçoit des modules indépendants : le moteur, le système de freinage, la transmission, etc. Chaque module a une fonction précise et peut être développé, testé, et même remplacé indépendamment des autres. Ils communiquent via des interfaces bien définies (des câbles, des axes, etc.).

En algorithmique, c'est le même principe. Au lieu d'écrire un long bloc de code séquentiel, nous le décomposons en modules, qui sont nos fonctions et procédures.

Pour bien comprendre la philosophie derrière cette approche, je vous invite à lire une courte introduction sur le sujet.

2. Principes d'une Bonne Architecture Modulaire

Décomposer un programme, c'est bien. Mais le faire intelligemment, c'est mieux. Une bonne architecture modulaire suit deux principes fondamentaux qui sont essentiels pour écrire du code de qualité.

Pour découvrir ces principes, je vous propose de consulter une présentation sur l'analyse modulaire.

Retenons ces deux idées maîtresses :

1. Haute Cohésion : Chaque module doit avoir une seule et unique responsabilité. Une fonction nommée CalculerMoyenneEtAfficherResultat a une faible cohésion. Il vaut mieux la diviser en deux fonctions : CalculerMoyenne et AfficherResultat. C'est le principe de responsabilité unique.

2. Faible Couplage : Les modules doivent être aussi indépendants que possible les uns des autres. Ils communiquent uniquement via leurs paramètres et valeurs de retour, sans dépendre de variables globales ou de détails internes d'autres modules. Un faible couplage permet de modifier un module sans risquer de "casser" tout le reste du programme.

3. Application au Projet : Le Gestionnaire de Contacts

Appliquons ces principes à notre projet. Nous allons définir la liste des fonctions (notre architecture) en nous basant sur les fonctionnalités identifiées dans la première leçon.

Pour chaque fonction, nous allons définir sa signature :

• Nom : Verbe d'action clair (ex: AjouterContact).
• Rôle : Une phrase décrivant sa responsabilité unique.
• Paramètres : Les données dont elle a besoin pour travailler (entrées) et celles qu'elle doit modifier (entrées/sorties).
• Valeur de retour : Ce qu'elle produit (sortie).

Le Programme Principal et les Fonctions Utilitaires

Le cœur de notre application sera une boucle qui affiche un menu et attend le choix de l'utilisateur. Cela nous suggère déjà une première fonction très simple et cohésive :

• Nom : Procedure AfficherMenu()
• Rôle : Afficher les options disponibles (Ajouter, Lister, Rechercher, Supprimer, Quitter).
• Paramètres : Aucun.
• Valeur de retour : Aucune.

Nous aurons aussi souvent besoin d'afficher les détails d'un seul contact. Créons une fonction "utilitaire" pour cela :

• Nom : Procedure AfficherUnContact(contact_a_afficher)
• Rôle : Afficher le nom, prénom et téléphone d'un contact formaté de manière lisible.
• Paramètres : contact_a_afficher (Type: Contact, Mode: Entrée).
• Valeur de retour : Aucune.

Les Fonctions Métiers

Maintenant, définissons les fonctions pour chaque grande fonctionnalité.

1. Rechercher un contact : C'est une opération fondamentale qui sera probablement réutilisée (par ex. avant d'ajouter un contact pour éviter les doublons, ou avant de le supprimer).

   • Nom : Fonction RechercherContact(annuaire, nb_contacts, nom, prenom)
   • Rôle : Cherche un contact par son nom et prénom dans l'annuaire.
   • Paramètres :
     • annuaire (Type: TABLEAU DE Contact, Mode: Entrée)
     • nb_contacts (Type: ENTIER, Mode: Entrée)
     • nom (Type: CHAINE, Mode: Entrée)
     • prenom (Type: CHAINE, Mode: Entrée)
   • Valeur de retour : L'indice du contact dans le tableau s'il est trouvé, sinon -1 (une valeur conventionnelle pour "non trouvé").

2. Lister les contacts :

   • Nom : Procedure ListerContacts(annuaire, nb_contacts)
   • Rôle : Parcourt l'annuaire et affiche chaque contact.
   • Paramètres :
     • annuaire (Type: TABLEAU DE Contact, Mode: Entrée)
     • nb_contacts (Type: ENTIER, Mode: Entrée)
   • Valeur de retour : Aucune.
   • Interaction : Cette procédure fera une boucle et appellera AfficherUnContact pour chaque élément.

4. Exercice : Définissez le reste de l'architecture

Maintenant, à vous de jouer ! En suivant le modèle ci-dessus, définissez la signature et le rôle des fonctions manquantes pour les fonctionnalités "Ajouter" et "Supprimer".

Votre mission :

Définissez la signature complète pour :

1. Procedure AjouterContact(...)
2. Procedure SupprimerContact(...)

Pensez aux questions suivantes :

• De quelles données ces fonctions ont-elles besoin ?
• Doivent-elles modifier des données comme l'annuaire ou le nombre de contacts ? (Pensez au mode Entrée/Sortie pour les paramètres).
• Vont-elles faire appel à d'autres fonctions que nous avons déjà définies (comme RechercherContact) ?

5. Schéma des Interactions

Voici une vue d'ensemble de l'architecture que nous venons de concevoir, montrant comment les modules s'appellent entre eux :

Programme Principal
│
├── Appelle AfficherMenu()
│
├── Appelle AjouterContact(annuaire, nb_contacts)
│   └── Appelle RechercherContact(annuaire, ...)
│
├── Appelle ListerContacts(annuaire, nb_contacts)
│   └── Appelle AfficherUnContact(contact)  // (dans une boucle)
│
├── Appelle SupprimerContact(annuaire, nb_contacts)
│   └── Appelle RechercherContact(annuaire, ...)
│
└── ... (autres fonctions comme une recherche simple et affichage)

Cette structure hiérarchique est claire, chaque fonction a un rôle défini, et les interactions sont maîtrisées. C'est la marque d'une conception logicielle robuste.

Conclusion

Félicitations ! Vous venez de concevoir l'architecture complète de notre application. Ce n'est plus une simple liste de fonctionnalités, mais un plan de construction détaillé.

Les points clés à retenir sont :

• L'architecture modulaire consiste à décomposer un programme en fonctions (modules) indépendantes.
• Une bonne architecture vise la haute cohésion (chaque module fait une seule chose) et le faible couplage (les modules sont indépendants).
• Définir la signature d'une fonction (nom, rôle, paramètres, retour) est l'acte de conception fondamental.
• Les interactions entre modules se font via des appels de fonction, en passant des données par paramètres.

Nous avons maintenant le plan des fonctionnalités, le modèle de données, et l'architecture modulaire. La table est mise ! Dans la prochaine leçon, nous passerons enfin à l'écriture : nous allons implémenter en pseudo-code chacune des fonctions que nous venons de définir pour donner vie à notre gestionnaire de contacts.