La pratique de l'Extreme Programming est encore assez peu répandue pour le développement de logiciels embarqués.LES ALÉAS DE L'EMBARQUÉ
En plus de difficultés classiques rencontrées en développement de logiciels, ce secteur est également confronté à des problèmes bien spécifiques.
Le logiciel est souvent couplé à un HardWare (HW) et un OperatingSystem (OS) spécifiques. Parfois même, le HW et l'OS sont développés en parallèle du logiciel et ne sont donc disponibles que tard dans le projet et en faibles quantités. Ainsi, l'intégration avec le HW et l'OS est du type Big-Bang et trop tardive. L'activité de test est alors peu efficace puisque essentiellement composée de séances de debug sur la cible. Aussi, il est regrettable de vérifier des algorithmes métier complexes sur un environnement aussi peu ergonomique que la carte embarquée.
Enfin, les développeurs sont confrontés au temps-réel, à la concurrence et au ressources limitées en charge de calcul et en mémoire.
Historiquement, les projets embarqués ont plutôt la réputation d'être marqués par les processus, les outils, la documentation et la recherche de la conformité aux plans. Bref, nous sommes bien loin du développement logiciel agile.
EXTRÊME PROGRAMMING EMBARQUÉ
Pourtant, certaines pratiques techniques de l'Extreme Programming se révèlent être une grande aide au développement de logiciels embarqués.
La pratique du pilotage par les tests (TDD) amène naturellement à découpler le code. Pour un logiciel embarqué cela conduit à isoler et réduire les dépendances vers le HW et l'OS pour de simples raisons de testabilité. Une telle conception pilotée par les tests permet alors de jouer des suites de tests sur une machine de développement (et non sur la cible) avec des mocks et stubs du HW et de l'OS. Ainsi, la quasi-totalité du code est testée et intégrée bien avant la disponibilité du HW et de l'OS!
Lorsque la cible est enfin disponible, les suites de tests sont rejouées sur celle-ci. Avec un langage de programmation tel que Ada, la construction des suites de tests avec une version native de la runtime Ada embarquée permet même de rejouer les tests sur la cible sans adaptation particulière (autre que la compilation croisée pour le processeur cible).
Le plus étonnant est que l'indisponibilté du HW et de l'OS, jadis une difficulté, est dévenue un atout! En effet, le découplage exigé par le TDD et rendu possible par un langage de programmation orienté-objet impose de bien concevoir les dépendances en séparant les problèmes. Les interfaces avec le HW et l'OS sont donc isolées du code métier. Les algorithmes métier complexes sont testés d'un côté sur une machine de développement et les les interfaces avec le HW et l'OS sont testés par ailleurs sur la cible.
Ainsi, gràce à la confiance que le développeur a en son code pleinement testé, il sait que les problèmes qu'il rencontrera (peut-être tardivement) en intégrant sur la cible ne concerneront plus que les interfaces avec le HW et l'OS, le temps-réel, la concurrence et les ressources limitées en mémoire et charge de calcul.
EXTRÊME SÛRETÉ
Parfois les logiciels embarqués sont également critiques, c'est à dire sûrs de fonctionnement. Je consacrerai un prochain billet sur cette difficulté additionnelle.
Lorsque je travaillais chez Matra Défense, nous avions fait tourner nos Test Unitaires écrits en C sur la machine cible, et cela nous avait posé des problèmes sur les librairies mathématiques. En effet, les précisions de ces librairies sur la machine hôte et cible etaient différentes et nous ne pouvions pas utiliser le même corps de TU. Nous avons donc modifié le TU mais in fine pour nous rendre compte que nous ne trouvions rien de plus en utilisant la machine cible. Nous avions donc abandonné cette pratique qui consistait à rejouer les tests sur la machine cible.
RépondreSupprimerQu'en est-il chez toi, avez-vous trouvé, avec le même jeu de test, des erreurs de code sur la machine cible que vous n'aviez pas trouvé sur la machine hôte ?
Pour ton 1er point, nous essayons d'utiliser une version native de la librairie mathématique enbarquée sur cible. Néanmoins, nous retrouvons ton problème initial de précision lorsque le processeur cible et le processeur natif ne proposent pas les mêmes flottants.
RépondreSupprimerPour ton 2ème point, il est vrai que nous n'identifions pas (ou très peu) de problèmes en rejouant les tests unitaires sur la cible. Par contre, dans la mesure où ces tests sont automatisés, où ils vérifient leurs propres résultats et où leur conception est compatible de la machine cible - le coût du rejeu sur cible est grandement diminué. L'objectif est alors d'identifier au plus tôt dans le temps les éventuels (même rares) problèmes. L'objectif est aussi de se familiariser avec la cible au plus tôt en embarquant du code au plus tôt.
Ok, la familiarisation avec la cible me paraît etre une raison suffisante pour faire la manip ... au moins tant que la cible n'est pas familière :)
RépondreSupprimerOK, ce que je pense que tu essayes de me faire dire est que jouer les tests développeur sur la cible est surtout une manière de répondre à des objectifs de certification de logiciels embarqués ET critiques.
RépondreSupprimerC'est dit ;o)
Ce sera l'objet de mon prochain billet.