Prototypes et Simulateurs

L'architecture d'une application est définie par les relations (Interfaces et comportement dynamique) entre les modules qui la composent. Certaines de ces interfaces sont prédéfinies (par exemple l'accès au système d'exploitation), d'autres sont à définir (accès au matériel, remontée des erreurs, contrôle d'un essai, ..). De l'architecture dépendent notamment :

  • Le coût et les délais de réalisation
  • La solidité de l'application
  • Les possibilités d'évolution

Comme il est quasiment impossible de réaliser une architecture d'application satisfaisante au premier essai. J'essaie de procéder de la manière suivante :

  • Définir un modèle : choix des rôles des modules et définition d'interfaces simples (voire simplistes).
  • Réaliser un prototype dès le début du projet, de 1 semaine à 1 mois selon l'ampleur du problème.
  • Ecrire du code et le valider dans la même journée.
  • Implémenter des fonctions, expérimenter, rectifier le modèle, en cycles itératifs d'environ 2 semaines.
  • Au début de chaque cycle, il faut en fixer les objectifs attendus.
  • Un cycle se termine lorsque les objectifs attendus sont atteints, ou lorsqu'ils ont fait apparaître un défaut du Modèle.

Très souvent il est nécessaire de disposer d'un simulateur logiciel permettant de faire fonctionner le prototype en l'absence de tout ou partie du matériel. Cela permet :

  • De commencer les développements en l'absence du matériel, qui cesse d'être la ressource critique
  • De disposer de jeux de Tests Unitaires, qui ne peuvent par définition pas exister si l'on utilise les instruments réels (nécessité des branchements manuels, temps de réponse, ..).
  • De travailler avec des debuggers (points d'arrêt, pas à pas, ..) sans être soumis aux contraintes de temps du monde réel.