C'est rigolo comme formule quand on pense que c'est dans le ferroviaire, l'aéronautique et le spatiale qu'on cherche le plus à faire du développement piloté par les modèles :D
Oui mais bon, on s'éloigne d'UML qui contient plusieurs centaines de concepts, c'est trop pour comprendre toutes les subtilités.
Du coup, on écrit des spécifications au travers de modèles que l'on transpose ensuite dans le langage cible.
Pas forcément. La mode est de décrire l'architecture, tu as en gros 3 graph : le fonctionnelle (l'ensemble des fonctions de ton code + ou -), le logiciel (en gros les paquets autour des fonctions, qui dialogue avec un Os, et gère la redondance, et les paquets réseau), et le hardware (cpu+réseau).
Une fois que tu as tout ça, tu peux générer tous les stub C de communication pour chacun des ordinateurs de ton architecture (startup code, les différents channels et leur config). Tu peux faire les tables de routages des switch (AFDX). Tu peux faire ta configuration vxworks pour chaque instance de l'OS (du xml). Tu peux générer la doc d'interface (API, ...). Et si tu change les entrées/sorties, tu régénères tout d'un clic.
Le contenu des fonctions n'est pas détaillé, et doit être remplit par du "code classique".
C'est une approche puissante, car tu peux jeter l'un des 3 graphs, si tu change de hardware, ou si le hardware est imposé, mais le logiciel est nouveau.
[^] # Re: la spec, c'est le code
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Développement très rapide d’applications libres : Extended Man/XML Frames. Évalué à 3.
Oui mais bon, on s'éloigne d'UML qui contient plusieurs centaines de concepts, c'est trop pour comprendre toutes les subtilités.
Pas forcément. La mode est de décrire l'architecture, tu as en gros 3 graph : le fonctionnelle (l'ensemble des fonctions de ton code + ou -), le logiciel (en gros les paquets autour des fonctions, qui dialogue avec un Os, et gère la redondance, et les paquets réseau), et le hardware (cpu+réseau).
Une fois que tu as tout ça, tu peux générer tous les stub C de communication pour chacun des ordinateurs de ton architecture (startup code, les différents channels et leur config). Tu peux faire les tables de routages des switch (AFDX). Tu peux faire ta configuration vxworks pour chaque instance de l'OS (du xml). Tu peux générer la doc d'interface (API, ...). Et si tu change les entrées/sorties, tu régénères tout d'un clic.
Le contenu des fonctions n'est pas détaillé, et doit être remplit par du "code classique".
C'est une approche puissante, car tu peux jeter l'un des 3 graphs, si tu change de hardware, ou si le hardware est imposé, mais le logiciel est nouveau.
"La première sécurité est la liberté"