FR3045860A1 - Procede de detection de problemes de testabilite d'un module informatique - Google Patents
Procede de detection de problemes de testabilite d'un module informatique Download PDFInfo
- Publication number
- FR3045860A1 FR3045860A1 FR1562987A FR1562987A FR3045860A1 FR 3045860 A1 FR3045860 A1 FR 3045860A1 FR 1562987 A FR1562987 A FR 1562987A FR 1562987 A FR1562987 A FR 1562987A FR 3045860 A1 FR3045860 A1 FR 3045860A1
- Authority
- FR
- France
- Prior art keywords
- code instructions
- blocks
- graph
- testability
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 47
- 238000012545 processing Methods 0.000 claims abstract description 13
- 238000004422 calculation algorithm Methods 0.000 claims abstract description 8
- 238000012795 verification Methods 0.000 claims description 11
- 238000004590 computer program Methods 0.000 claims description 7
- 238000004364 calculation method Methods 0.000 claims description 5
- 238000013507 mapping Methods 0.000 claims description 2
- 238000012360 testing method Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 3
- 238000011144 upstream manufacturing Methods 0.000 description 3
- 238000012937 correction Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000003116 impacting effect Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 241000266331 Eugenia Species 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000008094 contradictory effect Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011176 pooling Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
- 238000010998 test method Methods 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
- G06F11/3616—Software analysis for verifying properties of programs using software metrics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3676—Test management for coverage analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
- G06F16/288—Entity relationship models
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9024—Graphs; Linked lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/35—Creation or generation of source code model driven
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Debugging And Monitoring (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
La présente invention concerne 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 représentant des blocs repartis en un ou plusieurs composants et des relations entre les blocs et/ou les composants ; - d'autre part par des deuxièmes instructions de code en un langage textuel 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 (11) d'un équipement (1) 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 les mettant en correspondance (b) Synchronisation en un modèle consolidé des modèles associés; (c) Expression à partir dudit modèle consolidé d'un graphe ; (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.
Description
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 oeuvre, 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 oeuvre 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 11 (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, rembarquement 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, rembarquement 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 11 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 11 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 11 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.
Il 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 11 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 d11 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 11 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 noeuds (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 11 (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 11 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.
Claims (13)
- REVENDICATIONS1. Procédé de détection de problèmes de testabilité d’un module i 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é" dé blocs dudit modulé informatique fèpërtis éri 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 (11) d’un équipement (1 ) 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.
- 2. Procédé selon la revendication 1, dans lequel ledit langage de modélisation est un langage de programmation graphique, et ledit langage textuel étant un langage de description d’exigences.
- 3. Procédé selon l’une des revendications 1 et 2, dans lequel ledit seuil prédéfini est trois.
- 4. Procédé selon l’une des revendications 1 à 3, dans lequel l’étape (d) comprend également le calcul du nombre de composants dans le module informatique, du nombre de blocs pour chaque composant, et du nombre de spédfieâtîor» pour chaque bloc, l’étape (e) comprénantègâlement l’émission d’un signal indiquant un problème de testabilité du module informatique si au moins l’un de ces npmbres calculés est supérieur à un seuil prédéfini.
- 5. Procédé selon l’une des revendications 1 à 4, dans lequel 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.
- 6. Procédé selon l’une des revendications 1 à 5, dans lequel 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.
- 7. Procédé selon l’une des revendications 1 à 6, dans lequel 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.
- 8. Procédé selon l’une des revendications 6 et 7, dans lequel une information observable est une information d’entrée ou de sortie d’un composant, ou une information fournie par un bloc d’instrumentation.
- 9. Procédé selon l’une des revendications 1 à 8, comprenant 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).
- 10. Procédé selon la revendication 9, comprenant une étape subséquente (F) d’instanciation dans un système (2) des instructions de code générées dans un langage de programmation procédurales.
- 11. Equipement (1) 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 (1) étant caractérisé en ce qu’il comprend des moyens de traitement de données (11 ) 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.
- 12. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 de détection de problèmes de testabilité d’un module informatique, lorsque ledit programme est exécuté sur un ordinateur.
- 13. 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é selon l’une des revendications 1 à 10 de de détection de problèmes de testabilité d’un module informatique.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1562987A FR3045860B1 (fr) | 2015-12-21 | 2015-12-21 | Procede de detection de problemes de testabilite d'un module informatique |
| PCT/EP2016/082134 WO2017108924A1 (fr) | 2015-12-21 | 2016-12-21 | Procédé de détection de problèmes de testabilité d'un module informatique |
| US16/063,991 US10394688B2 (en) | 2015-12-21 | 2016-12-21 | Method for detecting computer module testability problems |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1562987A FR3045860B1 (fr) | 2015-12-21 | 2015-12-21 | Procede de detection de problemes de testabilite d'un module informatique |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3045860A1 true FR3045860A1 (fr) | 2017-06-23 |
| FR3045860B1 FR3045860B1 (fr) | 2017-12-22 |
Family
ID=56511610
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1562987A Active FR3045860B1 (fr) | 2015-12-21 | 2015-12-21 | Procede de detection de problemes de testabilite d'un module informatique |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US10394688B2 (fr) |
| FR (1) | FR3045860B1 (fr) |
| WO (1) | WO2017108924A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109902021B (zh) * | 2019-03-13 | 2021-03-02 | 北京国舜科技股份有限公司 | 一种信息系统安全测试质量评价方法及系统 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5457638A (en) * | 1993-02-23 | 1995-10-10 | Nec Research Institue, Inc. | Timing analysis of VLSI circuits |
| US5513118A (en) * | 1993-08-25 | 1996-04-30 | Nec Usa, Inc. | High level synthesis for partial scan testing |
| JP2865136B2 (ja) * | 1996-11-11 | 1999-03-08 | 日本電気株式会社 | テスト考慮論理合成システム |
| DE19803032A1 (de) * | 1998-01-27 | 1999-07-29 | Daimler Chrysler Ag | Verfahren zur computergestützten Optimierung von Prüfspezifikationen und Minimierung von Prüfsoftware |
| US6363520B1 (en) * | 1998-06-16 | 2002-03-26 | Logicvision, Inc. | Method for testability analysis and test point insertion at the RT-level of a hardware development language (HDL) specification |
| US7185049B1 (en) * | 1999-02-01 | 2007-02-27 | At&T Corp. | Multimedia integration description scheme, method and system for MPEG-7 |
| US7072818B1 (en) * | 1999-11-30 | 2006-07-04 | Synplicity, Inc. | Method and system for debugging an electronic system |
| US7272823B2 (en) * | 2002-08-22 | 2007-09-18 | Sun Microsystems, Inc. | Method and apparatus for software metrics immediate feedback mechanism |
| US7055129B2 (en) * | 2002-08-22 | 2006-05-30 | Sun Microsystems, Inc. | Method and apparatus for metrics approval mechanism |
| US20050097515A1 (en) * | 2003-10-31 | 2005-05-05 | Honeywell International, Inc. | Data empowered laborsaving test architecture |
| JP2010128583A (ja) * | 2008-11-25 | 2010-06-10 | Toshiba Corp | テスト容易化設計装置ならびにその方法およびプログラム |
| CA2734199C (fr) * | 2010-03-18 | 2017-01-03 | Accenture Global Services Limited | Peptides antigeniques derives de la telomerase |
| US8949216B2 (en) * | 2012-12-07 | 2015-02-03 | International Business Machines Corporation | Determining characteristic parameters for web pages |
| US8935641B2 (en) * | 2013-03-13 | 2015-01-13 | Taiwan Semiconductor Manufacturing Company, Ltd. | Semiconductor circuit design method, memory compiler and computer program product |
| US9348571B2 (en) * | 2014-08-25 | 2016-05-24 | General Electric Company | Method, device, and program storage device for autonomous software life cycle management |
| FR3026511B1 (fr) | 2014-09-30 | 2018-02-16 | Safran Electronics & Defense | Procede de test d'un composant logiciel |
-
2015
- 2015-12-21 FR FR1562987A patent/FR3045860B1/fr active Active
-
2016
- 2016-12-21 WO PCT/EP2016/082134 patent/WO2017108924A1/fr active Application Filing
- 2016-12-21 US US16/063,991 patent/US10394688B2/en active Active
Non-Patent Citations (4)
| Title |
|---|
| CHANTAL ROBACH: "Analyse de testabilité de systèmes flot de données", 14 November 2000 (2000-11-14), pages 1 - 83, XP055313871, Retrieved from the Internet <URL:http://www.acotris.c-s.fr/CRReunion/1-SysLogCritiques/14Nov/13-robach.pdf> [retrieved on 20161025] * |
| DU BOUSQUET L ET AL: "Analysis of Testability Metrics for Lustre/Scade Programs", ADVANCES IN SYSTEM TESTING AND VALIDATION LIFECYCLE (VALID), 2010 SECOND INTERNATIONAL CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 22 August 2010 (2010-08-22), pages 26 - 31, XP031786583, ISBN: 978-1-4244-7784-5 * |
| FASSELY DOUMBIA: "Contribution à l'analyse de testabilité des systèmes réactifs temps-réels : Aide à la validation et à la vérification des systèmes", 1 January 2010 (2010-01-01), XP055313766, Retrieved from the Internet <URL:https://tel.archives-ouvertes.fr/tel-00481072/document> [retrieved on 20161025] * |
| THANH BINH NGUYEN ET AL: "Transition-based testability analysis for reactive systems", COMPUTER SCIENCE AND AUTOMATION ENGINEERING (CSAE), 2011 IEEE INTERNATIONAL CONFERENCE ON, IEEE, 10 June 2011 (2011-06-10), pages 551 - 557, XP031893997, ISBN: 978-1-4244-8727-1, DOI: 10.1109/CSAE.2011.5952532 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20190004928A1 (en) | 2019-01-03 |
| US10394688B2 (en) | 2019-08-27 |
| WO2017108924A1 (fr) | 2017-06-29 |
| FR3045860B1 (fr) | 2017-12-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Valiev et al. | Ecosystem-level determinants of sustained activity in open-source projects: A case study of the PyPI ecosystem | |
| John et al. | Towards mlops: A framework and maturity model | |
| CA2937017C (fr) | Application integree de conception | |
| EP2286339B1 (fr) | Procédé d'élaboration automatique de cas de test pour la vérification d'au moins une partie d'un logiciel | |
| FR3044126A1 (fr) | Systeme et procede pour creer automatiquement des cas de tests a base d'exigences liees a un logiciel critique | |
| CN104036105A (zh) | 用于确定应用正确性的方法和系统 | |
| US20130283296A1 (en) | Method and system for generating a service definition based on service activity events | |
| US11347864B2 (en) | Ace: assurance, composed and explained | |
| CN113227978B (zh) | 计算机处理管线中的自动异常检测 | |
| US20160093117A1 (en) | Generating Estimates of Failure Risk for a Vehicular Component | |
| EP2913757A1 (fr) | Méthode, système et logiciel informatique produit pour l'automatisation des tests | |
| WO2020043999A1 (fr) | Outil et procédé de conception et de validation d'un système flots de données par un modèle formel | |
| WO2017108924A1 (fr) | Procédé de détection de problèmes de testabilité d'un module informatique | |
| US9646273B2 (en) | Systems engineering solution analysis | |
| Ali et al. | Cheating death: A statistical survival analysis of publicly available python projects | |
| Loper | The modeling and simulation life cycle process | |
| EP3195113B1 (fr) | Procédé de vérification de traçabilité de premières instructions en un langage de programmation procédurale générées à partir de secondes instructions en un langage de modélisation | |
| US7536427B2 (en) | Comparing process sizes | |
| Baumann et al. | Simulation driven development—Validation of requirements in the early design stages of complex systems—The example of the German toll system | |
| Vecchio et al. | SysML Reference Model for Assessing a Competitor's System | |
| Sirin | Ingénierie des systèmes basés sur les modèles (MBSE) appliquée au processus de conception de simulation complexe: vers une ontologie de la modélisation et la simulation pour favoriser l'échange des connaissances en entreprise étendue | |
| FR3026511A1 (fr) | Procede de test d'un composant logiciel | |
| Bures | OPTIMIZATION OF THE TEST STRATEGY AND EFFICIENT OPERATIONAL DECISIONS DURING THE TESTING OF COMPLEX SOFTWARE SYSTEMS: AN APPROACH BASED ON SIMULATION OF TESTING PROCESS. | |
| Goodenough et al. | Software assurance for systems of systems | |
| Arora et al. | Identification of critical risk phase in commercial-off-the-shelf software (CBSD) using FMEA approach |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20170623 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| CD | Change of name or company name |
Owner name: SAFRAN ELECTRONICS & DEFENSE, FR Effective date: 20180504 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |
|
| PLFP | Fee payment |
Year of fee payment: 9 |