Le passage des spécifications à un modèle formel

Cette étape est sûrement la plus difficile à résoudre en terme d’outils d’aide à la conception. Nous l’avons abordé dans une publication collective [KHG+04] et nous l’approchons en collaboration avec nos collègues du groupe ISI au LAAS (Ingénierie Système et Intégration) dans le cadre du projet

interne MOCAS [Too04], que notre travail a contribué à initier. Nous présentons ce projet, plus en détails dans l’annexe A.

Pour le concepteur, le problème se pose comme le besoin d’extraire les éléments suivants des spécifications textuelles :

• Une définition claire, bien comprise, du système, de ses objectifs techniques et non techniques.

• Une identification des fonctions principales qui composent ce système en distinguant toutes celles qui font l’objet d’innovations de celles qui sont de « simples » réutilisations. • L’anticipation de tous les modes d’interaction du système avec son environnement

d’utilisation et les procédures de vérification qui pourront et devront être appliquées sur la représentation virtuelle et sur la réalisation matérielle finale.

Sans avoir résolu totalement le problème, grâce aux traitements de quelques exemples, [HSE+03] [HEP03] [MCEB04] [HEP+03] [PHM+04], voici les pistes que nous pensons être des éléments de progrès.

3.3.1 La représentation élémentaire HiLeS

Figure 3-5. Exemple d’un module HiLeS.

Un bloc HiLes modélise une ou plusieurs fonctions par la durée globale d’exécution, identifie les entrées/sorties et dispose d’un élément de synchronisation : mise en route, arrêt, par exemple. Cette représentation est, au delà de la modélisation fonctionnelle ou comportementale,

la représentation générique la plus riche possible. Sous cette forme ou sous des formes équivalentes, elle s’impose comme une étape importante (conception amont) dans la représentation d’un système. Elle est suffisante pour les premières vérifications fonctionnelles, structurelles ou séquentielles.

Notre objectif est de retrouver cette représentation à tous les niveaux pour pouvoir appliquer une démarche descendante systématique.

Chapitre 3 : Une plate-forme de conception amont 77

• Niveau zéro : fonction système, spécifications du fonctionnement global, identifications des

acteurs extérieurs, entrées/sorties. Ce niveau zéro de représentation constitue l’environnement du système et dans la plupart des cas est défini ou imposé par le cahier des charges.

• Les niveaux 1, 2, 3 : Sont une décomposition hiérarchique statique de la fonction système,

c’est-à-dire une déclinaison en sous fonctions de plus en plus détaillées jusqu’à l’identification de toutes les fonctions élémentaires souhaitables pour le système. La connaissance experte est essentielle, elle s’applique à la lecture du document des spécifications en s’appuyant éventuellement sur un dictionnaire de fonctions que nous préconisons d’établir, ainsi que sur une taxonomie des spécifications, incontournable au moment de définir les dépendances hiérarchiques et les priorités du système. Le rôle de

l’ingénieur est crucial car c’est lui qui va identifier les états fonctionnels du système.

Cette démarche de simple description permet aussi d’identifier et de différencier les blocs et les sous-ensembles correspondants à la réutilisation d’acquis antérieurs.

La question qui se pose à ce stade de la description est double :

• Définir les interactions pour identifier les hiérarchies fonctionnelles et les interconnexions entre fonctions.

• Définir les séquences pour identifier et décrire tous les états du système.

Pour ce faire, nous préconisons d’inventorier les modes d’utilisation et les exigences sécuritaires et d’en définir les séquences. Là encore un inventaire pré-établi (checklist) peut

accélérer la procédure : mise en route, arrêt, arrêts d’urgence, exécution des fonctionnalités

programmées, tests embarqués, tests externes, etc. Chacune de ces procédures fera l’objet d’une représentation totale de la séquence correspondante et des éventuelles interactions entre les processus.

L’identification des interactions et des modes séquentiels des cas d’utilisation est très vite un travail d’une grande complexité que la disponibilité de méthodes et d’outillages spécialisés peut rendre plus rapide et plus performant. Il paraît plus stratégique d’opérer de manière : « Top-Down ». On écrit les diagrammes d’interaction entre les séquences dont on a établi l’inventaire, puis on décrit chaque séquence avec ses temporisations. Cependant, il y a probablement des cas où l ‘approche « bottom-up » s’impose.

Au bilan de cette étape, on dispose d’une représentation complète, hiérarchique et temporisée. Exprimée en réseaux de Petri, cette architecture fonctionnelle temporisée peut être l’objet d’une vérification systématique. Pour ce faire, une dernière étape est l’extraction du réseau de Petri

complet ou partiel, représentant le système ou un sous-système, chaque fonction étant représentée par son délai d’exécution.

3.3.2 La relation aux représentations UML

Comme nous l’avons déjà souligné, les méthodes et outils dédiés à la traduction des spécifications textuelles en un modèle formel permettant de réaliser la vérification et le choix architectural sont encore à développer. Les recommandations précédentes que nous avons déduites

du traitement de quelques exemples, doivent être approfondies. Toutefois, nous pensons pouvoir insister sur l’intérêt des composantes suivantes :

• La description très détaillée du niveau zéro,

• La description fonctionnelle hiérarchique en s’appuyant sur un inventaire de séquences type,

• La représentation formelle pour laquelle nous préconisons d’utiliser les réseaux de Petri, • L’extraction du modèle complet « Réseau de Petri » pour pouvoir faire appel à une

procédure de vérification.

Evidement, il faut que cette démarche descendante soit standardisée et nous attendons avec impatience la consolidation du langage SysML (§1.6.2) en cours de création à l’heure actuelle, issu de UML2. En l’état, nous pouvons faire les rapprochements suivants entre les recommandations que nous avons exprimées et la représentation UML.

Tableau 3-1 Rapprochement de nos recommandations avec les orientations SysML.™

Nos recommandations Représentation équivalente SysML™ (UML2)

Niveau 0 Contexte

Niveaux 1, 2, 3… Cas d’utilisation et représentations hiérarchiques Représentation des séquences du système à base de

réseaux de Petri.

Diagrammes d’activité et de séquence

Fiche des informations complémentaires Diagramme de besoins et matrice de traçabilité.

L’intérêt de cette standardisation est qu’elle va apporter l’interopérabilité des représentations avec des opérateurs ergonomiques apportant au concepteur des vues de l’ensemble et des « zooms » fonctionnels. L’intérêt de notre représentation par réseaux de Petri reste entier pour réaliser les simulations « haut-niveau » et la vérification de la conformité avec les spécifications.

A long terme, il sera possible de proposer, sur la base de cette procédure standard, un véritable guide de rédaction de spécifications et donc d’envisager des automatismes de capture et d’interprétation, telles que celle que nous avons proposé dans le deuxième chapitre de ce mémoire (§2.6).