Les insuffisances de la démarche en l’état

Pour l’utilisateur averti, HiLeS Designer est un outil efficace pour construire une représentation graphique « amont » d’un système. Il faut s’interroger, à l’usage, si la représentation du composant élémentaire est suffisamment riche pour illustrer tous les cas possibles de comportement et de fonctionnement. Cependant, la représentation HiLeS est complexe, peu lisible et rigide pour le concepteur qui souhaiterait voir l’état d’avancement de son travail sous différents angles : représentation architecturale, représentation métier ou bien, simplement le réseau de Pretri décrivant la commande associée au système. Cet aspect devra être développé dans l’avenir en conformité avec les recommandations de SysML™.

La relation au logiciel n’a pas été traitée au fond. Les exemples du chapitre quatre nous aideront à formuler des recommandations dans ce sens.

Notre approche est conçue comme le cœur d’une plate-forme de conception, dans ce contexte d’autres insuffisances sont apparues. Ci-dessous, le récapitulatif des déficiences que nous avons pu constater et qui certainement vont représenter des points à développer ou à améliorer dans des travaux ultérieurs.

Chapitre 3 : Une plate-forme de conception amont 101

• Capture de spécifications : Malgré nos recommandations de « bonne pratique » il

manque encore une procédure formelle de capture des spécifications. Pour l’instant, nous nous sommes fortement appuyés sur le savoir-faire du concepteur pour identifier les états principaux des systèmes et pour construire son environnement de fonctionnement à partir du cahier des charges. Eventuellement l’utilisation des cas d’utilisation et des diagrammes de séquence UML pourra définir un outillage complémentaire facilitant l’entrée aux représentations HiLeS. Cette aide à la capture devrait être complétée par des critères de classification des spécifications permettant d’établir des rapports hiérarchiques dès le départ de la modélisation.

• La traçabilité : Pour pouvoir répondre aux besoins de certification, il est nécessaire que

soit définie une structure de données permettant de suivre la prise en compte et la déclinaison des besoins dans un projet HiLeS. Pour cela, nous devons pouvoir développer encore plus le concept des CDF proposés précédemment (§2.9.1.7). Nous pensons que les CDF vont servir de base pour nourrir un système de documentation partagée du projet permettant de suivre la prise en compte pas à pas des besoins dans la démarche descendante. Cela s’inscrit dans une démarche d’écriture de fiches documentaires compatibles avec le standard XML, pour pouvoir les partager avec d’autres outils.

• Lisibilité : La sémantique de HiLeS devient très vite compliquée. En outre, nous n’avons

que la possibilité de « voir » un niveau de représentation par bloc à la fois. L’utilisateur peut facilement naviguer dans les projets HiLeS en utilisant la fonction « go inside » et l’explorateur de projets (§2.9.1.1). Mais la disponibilité d’un aperçu général du projet est tout à fait urgente. Nous pouvons envisager par la suite des « points de vue » complémentaires permettant de donner à l’utilisateur plusieurs aperçus simplifiés du projet :

Une première option est l’élaboration d’un arbre simplifié du projet. (A terme il faudra prendre en compte les conclusions des initiatives comme SysML pour élaborer des représentations compatibles et standardisées).

Une deuxième option, pour faciliter la visualisation des séquences fondamentales du système ainsi que son comportement de base, est une représentation « sans blocs ». De cette façon le concepteur aura une visualisation construite uniquement par des réseaux de Petri, simplification qui peut avoir lieu niveau par niveau.

• Simulation pas à pas avec TINA. Ce sera souhaitable de pouvoir exécuter des

simulations pas à pas sur TINA permettant de suivre état par état les évolutions du système. Pour l’instant nous n’avons pas le mécanisme de dialogue entre HiLeS Designer et TINA différents du transfert de fichiers décrit dans §3.4 qui reste à développer.

• Génération systématique et automatique de code VHDL-AMS pour des outils

commerciaux. La génération du code 100% utilisable dépend de l’outil de simulation ciblé.

Ceci implique le besoin de définir des « Templates » pour que le code soit généré en adéquation aux particularités de chaque outil. Pour l’instant nous avons implémenté une première version compatible avec SystemVision® de chez Mentor Graphics afin de pouvoir tester notre proposition. Un aspect très important, non seulement pour la génération automatique de code, mais aussi pour la structure générale des modèles HiLeS en VHDL- AMS peut être la définition de règles ou de méthodes d’écriture formelles. Parmi les travaux actuels, la méthode a-FSM inventée par Y Hervé [Her03] semble pouvoir se rapprocher conceptuellement de notre démarche. Le principe des a-FSM est la définition

des états fonctionnels d’un système et l’identifications des conditions de transition entre les états. Ces éléments constituent la base du modèle VHDL-AMS : les équations du modèle sont écrites pour chaque état. Le rapprochement avec notre démarche est clair car notre proposition à base de réseaux de Petri et blocs peut être interprétée en termes des a-FSM. • Vérification formelle du code VHDL-AMS. Plus important que la génération de code pour

un outil spécifique, la qualité des modèles produits est cruciale. Vu que la tâche d’écriture des fonctions élémentaires (description interne des blocs fonctionnels) est réservée au concepteur, le code VHDL-AMS est de son entière responsabilité. HiLeS Designer ne comporte pas de fonctionnalités tournées vers la vérification du code, ni au niveau syntaxique ni au niveau de la structure du code.