INFORMATIQUE

DOMAINE TECHNIQUE GENERAL La présente invention concerne la spécification et l'architecture de modules issus d'activités d'ingénierie système, d'ingénierie équipement. Cette invention intègre en particulier un procédé de détection de problèmes de testabilité d'un module informatique. ETAT DE L'ART

Les aéronefs de dernière génération recourent massivement à l'informatique et utilisent pour cela des équipements électroniques qui embarquent du logiciel.

Les normes ARP4754 et DO-178 fixent les conditions de sécurité applicables aux équipements électroniques embarquant des logiciels critiques utilisés dans des aéronefs.

Elles présentent cinq niveaux de criticité (de A à E) appelés niveaux DAL (« Development Assurance Level »), culminant au niveau A : un défaut du système ou sous-système étudié peut provoquer un problème catastrophique pouvant compromettre la sécurité du vol ou l'atterrissage, voire provoquer un crash de l'avion.

En fonction du niveau DAL retenue pour le système, les preuves à apporter quant à l'efficacité du processus de développement, et vis-à-vis de la fiabilité du produit qui en résulte, sont plus ou moins nombreuses. Ainsi, le degré de description formelle des architectures et des spécifications du produit va dépendre du niveau DAL. Ensuite, des procédures de test doivent permettre de vérifier les propriétés du produit pour s'assurer que ces propriétés répondent correctement aux exigences rédigées dans les spécifications. Un effort est aujourd'hui porté sur l'obtention d'une méthode fiable et reproductible permettant d'automatiser le test de composants logiciels critiques (jusqu'au niveau DO-178 DAL A), qu'ils soient générés automatiquement ou manuellement, et ce quelle que soit la complexité des systèmes à tester. A ce titre, la demande de brevet FR1459321 propose un framework de test offrant d'excellents résultats.

Toutefois, on constate que l'effort de vérification pourrait être réduit en amont, d'une part en anticipant des difficultés de « non testabilité » (par exemple certains composants d'une architecture produit s'avèrent mal instrumentés et certains tests ne peuvent être mis en œuvre, ce qui empêche une vérification complète du produit) et d'autre part en limitant le phénomène dit de « surspécification » qui démultiplie artificiellement et inutilement le nombre d'exigences (qui seront ultérieurement à vérifier).

En effet, bien que les causes racines de ces problématiques de testabilité

(sous le terme de « problématiques de testabilité », on désignera de façon générale les problématiques impactant la mise en œuvre des tests et on entendra en particulier aussi bien les erreurs de non-testabilité que la sur-spécification) soient très souvent le résultat de l'activité d'architecture, leurs effets n'apparaissent que tardivement dans la mesure où ils sont seulement détectés lors de la vérification du produit implémenté, entraînant de fortes reprises, des retards, et des coûts associés.

Alors, seules les erreurs de non-testabilité sont généralement traitées, la sur-spécification étant souvent conservés dans le produit (car détectée trop tardivement pour être corrigée sans risquer de remettre en cause le crédit déjà obtenus lors des tests). Ce type de gaspillage est impactant sur toute la durée de service du produit (problèmes de maintenabilité, etc.)

Il serait ainsi souhaitable de disposer d'une solution fiable et légère permettant de détecter les risques de sur-spécification et de non testabilité (et de façon générale de traiter les problématiques de testabilité) dès les phases d'architecture et de spécification des produits, de sorte à diminuer sensiblement le coût et le temps des procédures de vérification et de certification.

PRESENTATION DE L'INVENTION

Selon un premier aspect, la présente invention se rapporte donc à un procédé de détection de problèmes de testabilité d'un module informatique défini : - d'une part par des premières instructions de code en un langage de modélisation, lesdites premières instructions de code représentant une pluralité de blocs dudit module informatique repartis en un ou plusieurs composants et une pluralité de relations entre les blocs et/ou les composants ;

- d'autre part par des deuxièmes instructions de code en un langage textuel, lesdites deuxièmes instructions de code représentant une liste de spécifications chacune associée à une capabilité et définissant au moins un flux d'informations au niveau de la capabilité ;

le procédé étant caractérisé en ce qu'il comprend la mise en œuvre par des moyens de traitement de données d'un équipement d'étapes de :

(a) Expression des premières et deuxièmes instructions de code chacun sous une forme de modèle instanciant un méta-modèle commun mettant en correspondance d'une part les blocs avec les capabilités, et d'autre part lesdites relations avec lesdits flux d'informations ;

(b) Synchronisation en un modèle consolidé des modèles associés respectivement aux premières et deuxièmes instructions de code ;

(c) Expression à partir dudit modèle consolidé d'un graphe dans lequel les blocs et les composants sont des nœuds, et les relations sont des arêtes ; (d) Calcul par un algorithme de parcours de graphe de la largeur et/ou de la profondeur dudit graphe ;

(e) Emission d'un signal indiquant un problème de testabilité du module informatique si au moins une desdites largeur et profondeur calculées est supérieure à un seuil prédéfini.

Selon d'autres caractéristiques avantageuses et non limitatives :

• ledit langage de modélisation est un langage de programmation graphique, et ledit langage textuel étant un langage de description d'exigences ;

• ledit seuil prédéfini est trois;

· l'étape (d) comprend également le calcul du nombre de composants dans le module, du nombre de blocs pour chaque composant, et du nombre de spécification pour chaque bloc, l'étape (e) comprenant également l'émission d'un signal indiquant un problème de testabilité du module informatique si au moins l'un de ces nombres calculés est supérieur à un seuil prédéfini ;

• l'étape (b) comprend préalablement la vérification de la cohérence des modèles associés respectivement aux premières et deuxièmes instructions de code, l'étape (e) comprenant également l'émission d'un signal indiquant un problème de testabilité du module informatique si au moins une incohérence entre les modèles est identifiée ;

• la largeur du graphe correspond au plus grand nombre de blocs le long d'un chemin dans les arêtes du graphe représentatives de flux d'informations de type donnée, entre deux informations de type donnée observables ;

• la profondeur du graphe correspond au plus grand nombre de blocs le long d'un chemin dans les arêtes du graphe représentatives de flux d'informations de type commande, entre deux informations de type commande observables ;

• une information observable est une information d'entrée ou de sortie d'un composant, ou une information fournie par un bloc d'instrumentation ;

• le procédé comprend une étape subséquente (f) de génération d'instructions de code dans un langage de programmation procédurales à partir des premières instructions de code si aucun problème de testabilité n'est signalé à l'étape (e) ;

• le procédé comprend une étape subséquente (f) d'instanciation dans un système des instructions de code générées dans un langage de programmation procédurales.

Selon un deuxième aspect, l'invention concerne un équipement de détection de problèmes de testabilité d'un module informatique défini :

- d'une part par des premières instructions de code en un langage de modélisation, lesdites premières instructions de code représentant une pluralité de blocs dudit module informatique repartis en un ou plusieurs composants et une pluralité de relations entre les blocs et/ou les composants ;

- d'autre part par des deuxièmes instructions de code en un langage textuel, lesdites deuxièmes instructions de code représentant une liste de spécifications chacune associée à une capabilité et définissant au moins un flux d'informations au niveau de la capabilité ; l'équipement étant caractérisé en ce qu'il comprend des moyens de traitement de données configurés pour la mise en œuvre de :

- un module d'expression des premières et deuxièmes instructions de code chacun sous une forme de modèle instanciant un méta-modèle commun mettant en correspondance d'une part les blocs avec les capabilités, et d'autre part lesdites relations avec lesdits flux d'informations ;

- un module de synchronisation en un modèle consolidé des modèles associés respectivement aux premières et deuxièmes instructions de code ;

- un module d'expression à partir dudit modèle consolidé d'un graphe dans lequel les blocs et les composants sont des nœuds, et les relations sont des arêtes ;

- un module de calcul par un algorithme de parcours de graphe de la largeur et/ou de la profondeur dudit graphe ;

- un module d'émission d'un signal indiquant un problème de testabilité du module informatique si au moins une desdites largeur et profondeur calculées est supérieure à un seuil prédéfini.

Selon un troisième et un quatrième aspect, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon le premier aspect de l'invention de détection de problèmes de testabilité d'un module informatique ; et des moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé le premier aspect de l'invention de détection de problèmes de testabilité d'un module informatique.

PRESENTATION DES FIGURES

D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels :

- la figure 1 représente un système pour la mise en œuvre du procédé selon l'invention ; - les figures 2a-2b représentent respectivement des exemples de premières et deuxièmes instructions pour un même module informatique;

- les figures 3a-3b comparent un exemple d'architecture d'un module informatique présentant un problème de cohérence avec les spécifications, et le même exemple corrigé ;

- les figures 4a-4b illustrent la largeur et la profondeur d'un graphe utilisé dans le procédé selon l'invention ;

- les figures 5a-5b comparent un exemple d'architecture d'un module informatique pour lequel une non-testabilité est détectée, et le même exemple corrigé ;

- la figure 6 représente un exemple d'architecture d'un module informatique pour lequel une sur-spécification est détectée.

DESCRIPTION DETAILLEE

Environnement matériel

En référence à la figure 1 , le présent procédé est un procédé de détection de problèmes de testabilité d'un module informatique.

Le procédé est mis en œuvre via un équipement 1 qui peut être n'importe quel poste informatique comprenant des moyens de traitement de données 1 1 (par exemple un processeur), des moyens de stockage de données 12 (par exemple un disque dur) et des moyens d'affichage d'une interface graphique 13 (par exemple un écran).

Des moyens de saisie 14 (tels qu'un clavier et une souris) permettent à un utilisateur souhaitant utiliser le procédé (et/ou programmer graphiquement) d'interagir avec l'interface graphique 13. Il est à noter que le présent procédé n'est pas limité à l'utilisation d'un poste de travail, et que d'autres types d'équipements tels qu'un serveur peuvent tout à fait être utilisés. Instructions de code

Comme expliqué le présent procédé peut être mis en œuvre en amont de la conception du module informatique.

Ainsi par « module informatique », on entend avant tout des premières instructions de code en un langage de modélisation (un langage de programmation graphique tel que proposé par des outils du type Artisan Studio, Rhapsody, Entreprise Architect, SIRIUS) à partir desquelles seront ultérieurement générées des instructions de code en un langage de programmation procédurale (ou algorithmique : par langage de programmation procédural on entend un paradigme de programmation dans lequel une « procédure » contient simplement une série d'étapes à réaliser, à chacune desquelles d'autres procédures peuvent être appelée, voire la procédure elle-même (récursivité). Ces instructions constituent un code source, en un langage procédural comme C (ou par exemple un langage orienté objet de type Java), destiné à être compilé en un code exécutable puis à être embarqué (la terminologie « enfoui » est utilisée pour illustrer le fait que le module est inaccessible par un utilisateur) sur un calculateur 21 d'un appareil 2, en particulier un véhicule tel qu'aéronef, un équipement de sécurité tel qu'une système de planification et de restitution de mission ou un système de combat individuel, etc.

Le module informatique peut être logiciel et/ou matériel, c'est-à-dire que tout ou partie de ses composants (voir plus loin) peuvent être in fine sous la forme d'un jeu de données chargeables et exécutables (« software »), ou directement sous la forme d'un équipement présentant une configuration physique permettant la mise en œuvre des fonctionnalités prévues.

Dans le premier cas, l'embarquement consiste en général en l'écriture du code du composant logiciel dans une mémoire (en particulier morte) du calculateur 21 , en vue d'une exécution par un processeur du calculateur 21 . Dans le second cas, où le module est typiquement mis en œuvre par un circuit logique de type FPGA, l'embarquement consiste en une reconfiguration adéquate du circuit logique (faisant partie du calculateur 21 ), ou à la réalisation d'un circuit intégré de type ASIC (« Application-Specific Integrated Circuit ») conforme à la configuration du FPGA et son intégration dans le calculateur 21 . Le présent procédé ne sera limité à aucun de ces cas dans la mesure où il concerne la partie amont de la production du module, indépendamment de ses conditions ultérieures d'implémentation.

En cas de génération des instructions dans le langage de programmation procédurale, les moyens de traitement de données 1 1 génèrent et stockent sur les moyens de stockage de données 12 ces instructions de code en utilisant une bibliothèque de règles de génération dudit langage de programmation procédurale à partir du langage de modélisation.

On comprendra que la génération automatique de code et son embarquement sont des techniques bien connues de l'homme du métier qui sont optionnelles dans le présent procédé.

Le présent procédé n'a ainsi besoin que :

- d'une part des premières instructions de code en un langage de modélisation (lesquelles définissent « l'architecture fonctionnelle » et « l'architecture organique » du module) ; et

- d'autre part des deuxièmes instructions de code en un langage textuel (lesquelles définissent les « spécifications » du module) ;

Les premières et deuxièmes instructions de code sont à la fois liées et complémentaires, et sont toutes les deux nécessaires pour définir complètement le module et permettre sa vérification.

Les premières instructions de code représentent l'architecture globale et fonctionnelle du module, et l'expriment en une pluralité de blocs dudit module informatique repartis en un ou plusieurs composants (i.e. des groupes de blocs) et une pluralité de relations entre les blocs et/ou les composants. En d'autres termes, le module comprend un ou plusieurs composants, chaque composant comprenant un ou plusieurs blocs (appelés aussi « capabilités ») qui définissent une unité fonctionnelle, c'est-à-dire une fonction ou partie de fonction projetée sur le composant.

Chaque bloc reçoit des entrées, leur applique des traitements, et émet des sorties (notamment à destination d'autres blocs), de sorte à établir des flux d'informations (c'est-à-dire des entrées et/ou des sorties d'informations) entre les blocs. Les premières instructions définissent cela comme une pluralité de relations entre les blocs et/ou les composants.

Les relations, appelées aussi « couplages », portent ainsi soit sur des données, par exemple des valeurs de grandeurs fournies en continu, des valeurs discrètes ou encore des valeurs de paramètres de fonctions ; soit sur des commandes, par exemple des événements de synchronisation comme des appels de fonctions, des interruptions, des séquencements, etc.

On comprendra donc que les informations peuvent être de type donnée ou de type commande, et on utilisera le terme d'information pour désigner indifféremment les deux types d'informations, c'est à dire à la fois les données et les commandes.

Les informations peuvent être soit locales (c'est-à-dire qu'elles n'ont d'existence qu'au sein du composant) soit entrant/sortant du composant (c'est-à- dire reçues depuis l'extérieur ou transmises vers l'extérieur).

Chaque bloc (et similairement chaque composant) présente au moins une information d'entrée et/ou au moins une information de sortie, i.e. au moins un flux d'informations au niveau du bloc.

Une telle représentation permet d'avoir une vue globale de l'architecture du module, avec les interactions entre blocs (composant, fonction et/ou capabilité). Un exemple est visible sur la figure 2a.

Les deuxièmes instructions de code se présentent quant à elles sous la forme d'une liste de spécifications, c'est-à-dire comme expliqué d'exigences à satisfaire par le module. Le langage des deuxièmes instructions est un langage textuel, en particulier un langage dédié de description d'exigences. On citera par exemple DXL du logiciel DOORS. Les spécifications/exigences sont chacune associées à une capabilité et définissent une liste de flux d'informations (d'entrées et/ou de sorties d'informations) au niveau de la capabilité (on comprendra que le terme capabilité est utilisé pour les spécifications et le terme bloc est utilisé dans l'architecture, mais qu'il s'agit de la même entité dès lors qu'une fonction a été projeté sur un composant). Plus précisément, chaque « paragraphe » des deuxièmes instructions correspond à l'ensemble des spécifications associées à une capabilité, et donc définit cette capabilité. Chaque spécification est exprimée comme une condition (typiquement en pseudo-langage) portant sur les entrées ou les sorties du bloc correspondant à la capabilité, comme on voit sur la figure 2b qui représente un exemple de spécifications correspondant à l'architecture de la figure 2a.

Comme l'on voit l'architecture et les spécifications comprennent des contenus différents, mais doivent présenter une cohérence. Par exemple, Chaque sortie impliquée dans une spécification d'une capabilité doit se retrouver dans les relations du bloc correspondant de l'architecture, sous peine de quoi des erreurs peuvent se retrouver dans le produit suivant le référentiel (spécification ou architecture) utilisé par le développeur. Ces incohérences peuvent également induire que la spécification ne peut pas être intégralement vérifiée (voir les variables entourées dans chacune des figures 2a et 2b).

De façon habituelle, les spécifications définissent le cahier des charges que l'on doit respecter en créant l'architecture (en d'autres termes, les premières instructions sont écrites en connaissant les secondes instructions), c'est pourquoi des incohérences entre les premières et les deuxièmes instructions de code ne devraient normalement pas avoir lieu. On verra plus tard que dans un mode de réalisation préféré la cohérence est également vérifiée.

Procédé

Le présent procédé vise à détecter les problématiques potentielles de testabilité, en l'espèce la « non-testabilité » (impossibilité de vérifier directement le comportement d'un bloc, on verra des exemples plus loin) et la « surspécification » (complexification inutile des spécifications).

Pour cela, le procédé commence par la mise en œuvre par les moyens de traitement de données 1 1 d'une étape (a) d'expression des premières et deuxièmes instructions de code chacune sous une forme de modèle instanciant un méta-modèle commun mettant en correspondance lesdites relations avec lesdits flux d'informations.

Plus précisément, on a expliqué que les premières et les deuxièmes instructions contiennent chacune une part commune de contenu, et une part propre (par exemple, l'architecture des composants est propre aux premières instructions, et le contenu des spécifications est propre aux secondes instructions). Le méta-modèle définit un format commun qui met en regard les premières et deuxièmes instructions, et identifie les éléments pivots. Ce format de méta-modèle peut être implémenté dans deux outils distincts, un outil de gestion des architectures et un outil de gestion des spécifications par exemple de sorte à renseigner automatiquement chacun des deux modèles dès que l'on travaille sur les premières et/ou les deuxièmes instructions de code.

Le modèle associé aux premières instructions et le modèle associé aux deuxièmes instructions correspondent chacun à une instance du méta-modèle (i.e. une représentation des premières/deuxièmes instructions conformément audit format commun).

A partir de l'équivalence bloc/capabilité, le méta-modèle met en correspondance lesdites relations (dans l'architecture) avec lesdits flux d'informations (dans les spécifications), qui correspondent en effet aux mêmes notions.

Le format associé est typiquement basé sur du langage de balisage générique tel que XML (extensible Markup Langage) ou un langage dédié (DSL, domain spécifie langage).

On connaît des outils adaptés, par exemple Artisan Studio, Rhapsody, Entreprise Architect, ou SIRIUS pour la partie architecture (l'instanciation du méta- modèle se fait en utilisant des scripts java), et DOORS déjà évoqué ou encore Polarion, PTC Integrity pour la partie spécifications (l'instanciation du méta-modèle se fait en utilisant des scripts DXL). On connaît par ailleurs des technologies telles que Capella ayant déjà développé leur DSL utilisable pour le méta-modèle. Dans une seconde étape (b), les moyens de traitement de données 1 1 synchronisent en un modèle consolidé (c'est-à-dire mutuellement enrichi, i.e. mettant en commun leur contenu) les modèles associés respectivement aux premières et deuxièmes instructions de code : le modèle consolidé comprend l'ensemble des renseignements portés par chacun des modèles architecture/spécification.

Dans une première variante, on fait l'hypothèse qu'il n'y a pas d'incohérences entre les premières et les deuxièmes instructions de code, i.e. que le contenu « en double » n'est pas contradictoire. La synchronisation consiste simplement à combiner tous les renseignements trouvés dans l'un et/ou l'autre des modèles.

La synchronisation peut alors être sur demande, et de façon préférée elle a lieu en permanence.

II est en effet possible de lier le modèle d'architecture et le modèle de spécification de telle sorte que tout impact sur l'un des modèles soit automatiquement transposé sur les autres et réciproquement, en d'autres termes qu'ils soient en bijection. Cela permet de « propager » toute mise à jour. Par exemple, tout changement de contenu du référentiel d'exigence (ajout d'une donnée à calculer, etc.) a un impact visible sur l'architecture.

Dans une seconde variante (par exemple si la synchronisation n'a pas été faite au fil de l'eau), des incohérences peuvent exister entre les premières et les secondes instructions de code, et l'étape (b) peut à ce titre comprendre préalablement la vérification de la cohérence des modèles associés respectivement aux premières et deuxièmes instructions de code, c'est-à-dire la vérification de leur bijection : tout ce qui est contenu dans l'un doit être dans l'autre et réciproquement. On note que cette vérification peut être mise en œuvre automatiquement au fur et à mesure de la création du module informatique, de sorte à renvoyer en cas d'incohérence un message d'erreur (une alerte) au plus tôt, i.e. à un stade ou la correction est aisée et encore peu coûteuse. En cas d'incohérence détectée, un signal indiquant l'anomalie est en effet émis, et le procédé interrompu.

Pour cela les moyens de traitement de données 1 1 implémentent une ou plusieurs règles de vérification.

Une première règle est que :

- d'une part chaque information (d'entrée ou de sortie) impliquée dans une relation d'un bloc est utilisée au moins une fois dans les spécifications de la capabilité correspondant audit bloc, et

- d'autre part que chaque information utilisée dans les spécifications d'une capabilité est définie dans une relation du bloc correspondant à ladite capabilité.

En d'autres termes on vérifie qu'ils n'y a pas de contradiction manifeste entre l'architecture et les spécifications. Dans le cas contraire, on sait déjà que certaines spécifications ne peuvent être respectées par l'architecture en l'état et que des corrections sont nécessaires.

La seconde règle pouvant être vérifiée pour tester la conformité est :

- chaque information sortant d'un bloc doit être consommée par un autre bloc ou envoyée hors du composant ;

- chaque information entrant dans un bloc doit être produite par un autre bloc ou reçue par le composant ;

En d'autres termes on vérifie que toutes les informations (données/commandes) consommées ont été produites auparavant, et que toutes les informations produites sont consommés. Dans le cas contraire, on sait déjà que certaines spécifications n'ont pas été respectées.

La figure 3a représente un exemple d'architecture pour la cohérence n'est pas vérifiée, et la figure 3b représente le même exemple corrigé.

Dans la figure 3a, la commande s2 et la donnée d3 reçues par le composant CSC1 ne sont pas consommés par un bloc, la commande s4 devant être exportée par le bloc CSC1_Capability1 et être importée par le bloc CSC1_Capability2 est manquante, la donnée d9 reçue par le bloc CSC2_Capability1 n'est pas importée par le composant CSC2 au contraire des données d6 et d8 qui manquant, la donnée d1 1 produite par le bloc CSC2_Capabilité2 n'est pas exportée par le composant CSC2, et la commande s13 est exportée par le composant CSC2 alors qu'elle n'est pas produite par le bloc CSC2_Capabilité2.

Une exception à ces règles est qu'une information soit étiquetée « SPARE=true », c'est-à-dire « de rechange », ce qui signifie qu'elle est optionnelle. C'est par exemple le cas de la commande s10 de ces exemples.

Une fois l'étape (b) terminée, on considère que l'équivalence entre l'architecture et les spécifications est établie. Dans une étape (c), les moyens de traitement de données 1 1 expriment à partir dudit modèle consolidé un graphe dans lequel les blocs (ou capabilités) et les composants sont des nœuds, et les relations et les flux (en d'autres termes les entrées et/ou sorties d'informations, qu'elles soient en local ou vers/depuis l'extérieur d'un composant) sont des arêtes (en particulier des arêtes orientées dans le sens production vers consommation, i.e. des arcs). En d'autres termes, les arêtes sont représentatives d'échanges d'informations entre blocs (ou depuis/vers l'extérieur).

Par exemple, deux sommets représentant deux blocs qui respectivement produisent et consomment la même information sont connectés par un arc. Alternativement, tous les sommets représentant des blocs d'un composant sont connectés par un arc au sommet représentant le composant s'ils importent ou exportent des informations depuis/vers l'extérieur du composant.

De façon préférée, les données et les commandes sont représentés par deux types d'arcs de sorte à les distinguer.

Outre Sirius évoqué avant, on citera EuGENia Live ; AToM3, MeatEdit+ ou

Poséidon permettant d'exprimer un DSL en graphe.

On note que la représentation graphique de l'architecture est déjà un graphe en soi (il n'y a pas besoin d'en générer un), à condition de bien percevoir les sommets et les arêtes. Dans la suite de la présente description, on utilisera de telles représentations à titre d'exemple de graphes. Cette étape d'expression consiste ainsi seulement à identifier dans les modèles les entités qui sont constitutives d'un graphe au sens mathématique, c'est-à-dire les sommets et les arcs.

On utilise les propriétés de la théorie des graphes pour identifier des signes représentatifs des problématiques de testabilité évoquées avant.

Ainsi, dans une étape (d) un algorithme de parcours de graphe est utilisé pour calculer la largeur et/ou de la profondeur dudit graphe : de tels algorithmes de parcours de graphe sont connus, optimisés et permettent d'obtenir rapidement les paramètres requis.

Par « largeur de graphe », on entend la longueur de la plus longue chaîne liant deux données observables, c'est-à-dire une donnée d'entrée et une donnée de sortie d'un composant du module. Il s'agit ainsi du niveau maximal de transformation d'une donnée d'entrée (on ne suit que les arêtes « flux de données » et pas les arêtes « flux de commandes »). En d'autres termes, la largeur est la longueur du plus long flux d'informations de type donnée.

La largeur est exprimée en nombre de nœuds (blocs) rencontrés, qui est égale au nombre d'arêtes de la chaîne moins un. La largeur peut être calculée composant par composant (largeur de sous-graphe), et on prend au final la valeur maximale des largeurs de sous-graphes comme largeur du graphe. En référence à l'exemple de la figure 4a, on voit que trois blocs doivent être parcourus (soit quatre arêtes) entre l'entrée et la sortie du composant Componentl .

Similairement, par « profondeur de graphe », on entend la longueur de la plus longue chaîne liant deux commandes observables c'est-à-dire une commande d'entrée et une commande de sortie d'un composant du module, c'est-à-dire pour reformuler encore des commandes accessibles depuis les bornes d'un composant du module. On ne suit que les arêtes « flux de commandes » et pas les arêtes « flux de données ». En d'autres termes, la profondeur est la longueur du plus long flux d'informations de type commande.

La profondeur est exprimée en nombre de nœuds (blocs) rencontrés, qui est égale au nombre d'arêtes de la chaîne moins un. La profondeur peut être calculée composant par composant (profondeur de sous-graphe), et on prend au final la valeur maximale des profondeurs de sous-graphes comme profondeur du graphe. En référence à l'exemple de la figure 4b, on voit que trois blocs doivent être parcourus (soit quatre arêtes) entre l'entrée et la sortie du composant Componentl .

En remarquant que chaque chaîne d'une entrée à une sortie d'un composant est cyclique (puisque le composant est nœud de départ et d'arrivée), la largeur du graphe est la taille moins un du plus grand cycle d'arêtes de type flux de données, et la profondeur du graphe est la taille moins un du plus grand cycle d'arêtes de type flux de commandes.

Chacune des deux grandeurs largeur et profondeur est comparée à un seuil maximal, et il est ainsi possible de se limiter à une comparaison du maximum de la largeur et la profondeur avec un seuil unique. Ce maximum peut être directement calculé comme la taille moins un du plus grand cycle d'arêtes.

La largeur et la profondeur du graphe sont représentatives d'un niveau de complexité du module, et en particulier de l'accessibilité de certaines capabilités lors du test d'exigences. En pratique, si au moins une desdites largeur et profondeur calculées est supérieure à un seuil prédéfini, certaines spécifications sont jugées non testables. Un tel seuil permet de borner la complexité et la granularité des spécifications d'un composant, afin d'inciter à remonter le niveau de granularité des exigences, introduire des points de testabilité, ou diviser le composant en sous-composants et introduire une démarche de conception incrémentale.

Le seuil prédéfini est paramétrable en fonction de la complexité intrinsèque du module développé, mais de façon préférée il est au maximum égal à trois (à la fois pour la profondeur et la largeur). A des niveaux plus bas (par exemple Configuration Software Unit, CSU en logiciel), il peut être choisi égal à deux voire à un . En effet, si l'on prend l'exemple de la figure 4a, lors de phase de tests on peut seulement contrôler les informations reçues en entrée du composant, et vérifier les informations en sortie du composant car seul le composant a une existence physique. Ainsi, pour pouvoir stimuler et observer les entrées/sorties de la capabilité 1 .2 pour s'assurer que l'implémentation faite est conforme des exigences rédigées aux bornes de cette capabilité, il est nécessaire de connaître les transformations faites par les capabilités intermédiaires (en l'occurrence ici par les capabilités 1 .1 et 1 .3) : ni l'entrée de la capabilité 1 .2 ni sa sortie n'est connue avec précision. Si la capabilité 1 .3 donne les bons résultats, on peut supposer que les trois capabilités 1 .1 à 1 .3 fonctionnent, mais il n'est statistiquement pas impossible que deux erreurs se soient compensées.

Le fait de limiter à trois voire moins garantit une visibilité suffisante sur les capabilités lors des tests : on ne rencontrera pas de problème de non-testabilité. En pratique, seul un seuil égal à un permet d'avoir pour toutes les capabilités toutes les entrées et toutes les sorties directement stimulables et observables.

La figure 5a représente un exemple plus complexe dans lequel la largeur est six. En effet le chemin le plus long est donné par les capabilités 3.1 + 3.2 + 3.4 + 3.5 + 3.6 + 3.7. Ainsi en pratique les données A, B, C, D, E, H et K sont observables de façon fiable (A, B, C, D et E sont le résultat d'au maximum deux capabilités, et H et K sont directement observables via la sortie). Ainsi, les capabilités 3.6, 3.7 et 3.8 présentent des problèmes de testabilité.

La figure 5b représente une modification de l'architecture de la figure 5a permettant, tout en respectant les mêmes spécifications, de limiter la largeur du graphe à trois (et donc de rendre toutes les capabilités plus aisément testables). Pour cela, il est proposé tout d'abord de sortir les blocs correspondants aux capabilités 3.6 et 3.7 et de les disposer dans un nouveau composant (New Component). La donnée F devient une donnée de sortie de l'ancien composant et une donnée d'entrée du nouveau composant, c'est-à-dire une donnée observable.

En suite la testabilité de la capabilité 3.8 (et indirectement celle de la capabilité 3.9) est améliorée grâce à l'intégration dans l'architecture d'un bloc d'instrumentation qui permet de générer une donnée D de test (« stub »), ce qui réduit la complexité pour les données J et K. Ainsi, puisque le composant 3.8 est instrumenté, le plus long chemin devient 3.1 + 3.2 + 3.4

Dans une étape finale (e), la testabilité du module est évaluée en fonction des valeurs de largeur/profondeur calculées (et le cas échéant des tests supplémentaires de cohérence). En particulier, un signal indiquant un problème de testabilité du module est émis (exemple un message d'erreur sur l'interface 13) si au moins une desdites largeur et profondeur calculées est supérieure au seuil prédéfini.

En l'espèce, si le seuil prédéterminé est trois, l'architecture de la figure 5a aurait conduit à l'émission dudit signal, mais pas celle de la figure 5b.

On note que des vérifications supplémentaires peuvent être mises en œuvre lors cette étape. Notamment, comme représenté par la figure 6, il est possible d'utiliser les seuils supplémentaires relatifs au nombre de composants, au nombre de capabilités par composants et au nombre d'exigences par composant.

A un « haut » niveau (dit HLR en logiciel), on peut s'autoriser à manipuler 10 composants x 10 capabilités x 10 exigences (comme représenté sur la figure 6, qui représente un exemple dépassant ces seuils et donc caractéristique d'une surspécification), soit 1000 exigences, ce qui par retour d'expérience convient aux systèmes les plus complexes, tels que les systèmes de navigation inertielle.

A un « bas » niveau (dit LLR en logiciel, par exemple CSU), on peut s'autoriser à manipuler 1 composants x 10 capabilités x 10 exigences (puisque le seuil de complexité est limité à 1 , il ne peut y avoir qu'une capabilité par composant, ce qui permet de vérifier intégralement les exigences), soit 100 exigences, ce qui par retour d'expérience convient aux systèmes les plus complexes, tels que les systèmes de navigation inertielle. Système

Selon un deuxième aspect, l'invention concerne un équipement 1 pour la mise en œuvre du précédent procédé, i.e. la détection de problèmes de testabilité d'un module informatique défini :

- d'une part par des premières instructions de code en un langage de modélisation, lesdites premières instructions de code représentant une pluralité de blocs dudit module informatique repartis en un ou plusieurs composants et une pluralité de relations entre les blocs et/ou les composants ;

- d'autre part par des deuxièmes instructions de code en un langage textuel, lesdites deuxièmes instructions de code représentant une liste de spécifications chacune associée à une capabilité et définissant au moins un flux d'informations au niveau de la capabilité.

L'équipement 1 est en particulier un poste de génération de code informatique.

Cet équipement comprend des moyens de traitement de données 1 1 (par exemple un processeur) configurés pour la mise en œuvre de :

- un module d'expression des premières et deuxièmes instructions de code chacun sous une forme de modèle instanciant un méta-modèle commun mettant en correspondance d'une part les blocs avec les capabilités, et d'autre part lesdites relations avec lesdits flux d'informations ;

un module de synchronisation en un modèle consolidé des modèles associés respectivement aux premières et deuxièmes instructions de code ;

- un module d'expression à partir dudit modèle consolidé d'un graphe dans lequel les blocs et les composants sont des nœuds, et les relations sont des arêtes ;

- un module de calcul par un algorithme de parcours de graphe de la largeur et/ou de la profondeur dudit graphe ;

- un module d'émission d'un signal indiquant un problème de testabilité du module informatique si au moins une desdites largeur et profondeur calculées est supérieure à un seuil prédéfini. Produit programme d'ordinateur

Selon un troisième et un quatrième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution (en particulier sur les moyens de traitement 1 1 de l'équipement 1 ) de détection de problèmes de testabilité d'un module informatique, ainsi que des moyens de stockage lisibles par un équipement informatique (notamment une mémoire 12 de l'équipement 1 ) sur lequel on trouve ce produit programme d'ordinateur.