Un programme modulaire

Au début d’une tâche de programmation, on peut penser à notre solution comme un seul programme :

Par contre, on a souvent à faire au moins les trois étapes suivantes dans chaque programme qui interagit avec un utilisateur :

Si on connaît les détails de la tâche, on peut probablement diviser l’étape “Actions” encore selon les différentes tâches à réaliser :

Ce qu’on vient de faire est une décomposition du problème selon une approche descendante : on a pris un problème complexe et on l’a divisé en plus petits problèmes. Chaque petit problème est plus facile à résoudre que le problème global.

En programmation, on peut utiliser des méthodes pour résoudre chaque petit problème.

Un projet modulaire

On peut appliquer la même approche à la planification d’un projet dans n’importe quelle domaine.

Par exemple, un projet de recherche qui commence comme ceci :

Peut être décomposé en étapes comme ceci :

Voyant les étapes exposées comme ça, on peut mieux prévoir le temps nécessaire ou mieux s’organiser en équipe pour répartir les tâches.

Diagramme de dépendances

Certaines étapes ou modules d’un projet ne peuvent pas se faire sans que d’autres ne soient complétées. Un diagramme de dépendances illustre ces relations entre les modules.

On a déjà vu un diagramme de flux (qui montre la séquence des étapes) dans une leçon précédente. Un diagramme de dépendances est différent sur plusieurs points :

• Il ne montre pas ce qui se passe dans les détails mais identifie seulement les “modules” ou les “étapes” du projet.
• Il ne montre pas l’ordre d’exécution mais plutôt quelle étape dépend de quelle autre étape.

Le projet de recherche

Ici on compare les deux types de diagrammes pour le projet de recherche :

Avez-vous remarqué que la direction des flèches est inversée entre les deux diagrammes? C’est parce que le diagramme de dépendances commence avec le projet complet et regarde ce qui est nécessaire pour le rendre… réponse : que le projet soit rédigé. Et pour rédiger le projet, on a besoin de quoi?… réponse : les notes de recherche. Et pour faire les notes, on a besoin de quoi?… réponse : les sources d’information, etc. Ici les flèches indiquent les dépendances. Si on a une flèche de A vers B, ça veut dire que A dépend de B.

Dans le diagramme de flux, c’est l’opposé : on commence avec la première étape à réaliser. Ensuite, on regarde ce qui doit se passer après. Et après, et après, jusqu’à la fin du projet. Si on a une flèche de A vers B, ça veut dire que B est l’étape qui suit A.

C’est naturel que les flèches soient inversées entre les deux diagrammes. Si A dépend de B, alors A doit attendre que B soit fait. Cela nous donne :

• flèche de dépendance de A vers B
• flèche de séquence de B vers A

Le programme modulaire

Maintenant on fait le même exercice pour le programme modulaire :

Ici la relation entre les deux types de diagrammes n’est pas aussi claire. Entre autres, on ne peut pas regarder le diagramme de flux et savoir, avec certitude, si une étape dépend de l’étape précédante ou non. De l’autre côté, il n’y a aucun lien direct entre les “modules” Accueil, Actions et Au revoir dans le diagramme de dépendances alors rien ne suggère une séquence sauf notre expérience qu’un accueil vient avant un au revoir.

En général, on produit chaque type de diagramme indépendamment en appliquant les concepts de chacun :

• le diagramme de flux montre toujours la séquence d’exécution des étapes;
• le diagramme de dépendances montre les dépendances entre les différents modules.

Chaînes d’appels

Dans les diagrammes de dépendances, les modules sont liées dans des chaînes de dépendance. Les modules en programmation sont souvent des méthodes. Dans ce contexte on parle de chaînes d’appels, parce qu’une méthode doit appeller les autres méthodes qu’elle a besoin d’utiliser.

Si une méthode à plusieurs dépendances, il y a des branches qui se forment dans le diagramme, créant autant de chaînes d’appels que de branches. Notre exemple de programme modulaire a donc ces cinq chaînes d’appels car la méthode Actions dépend de trois méthodes, triplant le nombre de chaînes passant par elle :

Au début d’une chaîne d’appels (le bloc avec aucune flèche entrante), on a la méthode dépendante d’une autre. À la fin d’une chaîne d’appels, on a une méthode qui n’a pas de dépendances (aucune flèche sortante), qui est indépendante.

Si on veut profiter pleinement de la décomposition (plusieurs problèmes plus simples au lieu d’un grand problème), on ne peut pas commencer par écrire les instructions pour les méthodes dépendantes car il faudra aussi immédiatement écrire les instructions pour toutes les autres méthodes plus bas dans la chaîne d’appels (la première méthode dépend d’eux)… on n’a pas vraiment simplifié notre tâche! Par contre, si on commence avec une des méthodes indépendantes, on peut écrire le code juste pour cette méthode et la tester. On a juste un petit problème à résoudre. Ensuite, on peut soit choisir une autre méthode indépendante à faire ou bien la prochaine méthode plus haut dans la chaîne d’appels. Dans chaque cas, on reste avec juste un petit problème à résoudre dans l’immédiat. Mais peu à peu, tous les modules du projet se réalisent.

Refactoriser - quand on a déjà tout écrit

Parfois on n’a pas prévu découper notre programme en plus petites méthodes, mais la taille du programme ou sa complexité ou le besoin de réutiliser plusieurs fois le même code nous pousse à le faire. Réorganiser le code sans changer son comportement s’appelle refactoriser. Il n’y a pas de planification, juste un besoin pressant pour la décomposition, pour la création de modules.

La plupart du temps, surtout en commençant à programmer, c’est dur de savoir quand quelque chose sera trop complexe avant de l’avoir écrit, alors la refactorisation est souvent ce qui motive les premières expériences avec le code modulaire.