Introduction

Qu’est-ce qu’un module ?

1. Unité de mesure (architecture, technique, physique, math.)
2. Unité constitutive d’un ensemble
   Les morceaux qui doivent être mis ensemble

Modules de matériel

Comment les mettre ensemble est évident.

• des contraintes physiques bien connues

Modules de logiciel

Quand est-ce que les morceaux sont mis ensemble ?

1. Phase de programmation
   morceaux: tâches affectées aux programmeurs
2. Phase d’assemblage
   morceaux: programmes compilés (assemblés) séparément
3. Phase de chargement
   morceaux: segments chargés (références internes)

On ne devrait pas confondre les trois concepts.

• Contraintes différentes
  • Phase de programmation :
      cohérence intellectuelle pour un programmeur
      capacité de comprendre, vérifier
      facilité de changement
  • Phase d’assemblage :
      conflits de noms
  • Phase de chargement :
      capacité de mémoire
• Poursuite d’une coïncidence peut résulter en inefficacité
  • Modules de phase de programmation peuvent ne pas être de bons modules de chargement.
  • Modules de phase de programmation ne doivent pas être nécessairement compilés séparément (même s’il y a des coûts supplémentaires)

Dans ce cours, les modules sont toujours des entités de conception et de changement.

1. Unités de conception indépendante et de changement.
2. Un critère de décomposition est nécessaire.
3. Hiérarchie: modules peuvent être sous-divisés.
4. Critères d’arrêt :
   1. Si petits que des changements n’apportent rien.
   2. Redésigner = rejeter.
   3. Le coût de spécification ne peut pas dépasser des bénéfices, ces derniers dépendent de l’usage futur.

Principes de conception

• dissimulation de l’information
  (on ne peut pas la sous-estimer)
• s’il est probable que certains détails du système peuvent changer indépendamment alors ils doivent être secrets de modules différents
• la structure de données d’un module peut être accédée seulement par les programmes de ce module
• estimation de la probabilité de changements peut être difficile dans certains cas
  facteurs essentiels :
  • expérience passée
  • connaissances du domaine
  • connaissances de la technologie (matériel et logiciel)

Buts de la structure modulaire

• But principal :
  • réduction des coûts du logiciel suite aux faits que la conception et la révision de modules sont faites indépendamment
• Buts spécifiques :
  • la structure de chaque module doit être suffisamment claire pour qu’on puisse la comprendre entièrement
  • il devrait être possible de changer l’implémentation d’un module sans avoir connaissance de l’implémentation des autres et sans en affecter le comportement
  • la facilité avec laquelle les changements pourraient être faits dans la conception devrait refléter la probabilité que de tels changements seront nécessaires;
    • les changements plus probables devraient se faire sans modifier les interfaces des modules;
    • les changements moins probables peuvent impliquer des modifications dans les interfaces des modules qui sont petits et pas trop utilisés;
    • seulement les changements très peu probables peuvent exiger des modifications dans les interfaces des modules largement utilisés
  • il devrait être possible de faire un gros changement du logiciel sous forme de plusieurs changements indépendants appliqués à des modules simples; le nombre de modules à analyser à la fois ne peut pas être trop élevé (le nombre acceptable < 20)
    (s’il n’y a pas de changement d’interface les programmeurs qui modifient des modules simples ne sont pas obligés de communiquer entre eux)
  • un ingénieur logiciel devrait être capable de comprendre les responsabilités d’un module sans devoir comprendre sa conception interne
  • un lecteur avec un souci bien défini devrait être capable d’identifier les modules pertinents sans devoir étudier des modules non pertinents
    (ça implique que le lecteur devrait être capable de faire la distinction sans regarder les composantes des modules)
  • le nombre de branches dans chaque module non-terminal doit être suffisamment petit pour que les designers puissent trouver des arguments convaincants que les sous-modules n’ont pas des responsabilités partagées et qu’ils couvrent toutes les responsabilités du module