FR 2907933 A1 20080502 FR 0758549 A 20071024 1 DESCRIPTION L'invention concerne un procédé pour la création d'une description d'exigences pour un système incorporé, notamment pour la création d'une spécification de test. Un système incorporé est habituellement une unité logicielle/matérielle (software/hardware) qui est reliée à un système environnant et/ou un système global par l'intermédiaire de capteurs et/ou d'activateurs et/ou d'interfaces. Un système incorporé peut ainsi par exemple assurer des tâches de surveillance, de commande ou de régulation. Un appareil de commande destiné à la commande de différentes tâches dans un véhicule automobile peut par exemple être configuré sous la forme d'un système incorporé. Au sens de la présente invention ont entend donc par système incorporé dans un mode de réalisation préféré un appareil de commande destiné à des véhicules On entend dans le présent document par système incorporé non seulement la configuration concrète côté matériel dudit système incorporé, mais également les étapes préliminaires de développement d'un système incorporé réalisé côté matériel, donc par exemple également un modèle informatique pour la simulation dudit système incorporé. Pour obtenir un niveau de qualité élevé, on prévoit habituellement de tester de façon approfondie les systèmes incorporés, tels que par exemple les appareils de commande, avant l'introduction en grande série, et de vérifier ainsi qu'ils répondent aux exigences fixées. Il faut donc pour ces tests, en particulier pour le développement de ces tests, connaître les exigences qui doivent être imposées à un système incorporé Les exigences sont généralement prescrites par les clients d'un fabricant de tels systèmes incorporés, et existent normalement sous la forme d'une exigence exprimée en langage naturel, donc par exemple sous la forme d'un texte mis par écrit par la personne qui fixe les exigences. Le problème qui se pose tient au fait que le langage naturel, quelle que soit la langue, n'est généralement pas univoque, et que les exigences décrites risquent d'être mal comprises. 2907933 2 Par ailleurs ces exigences, qui peuvent par exemple donner une assertion sur une propriété ou une prestation d'un système incorporé, doivent être vérifiées, ce pour quoi il est souvent prévu que des programmes de vérification adéquats soient écrits, soit pour vérifier les systèmes incorporés après leur réalisation matérielle, soit pour déjà tester le modèle logiciel à 5 la base du système incorporé. Les programmeurs écrivent alors des routines informatiques qui ne sont plus directement compréhensibles, en particulier pour un observateur non averti, de sorte qu'il n'est pas possible à l'aide des routines informatiques concernées de tirer directement une conclusion 10 sur ce qui est concrètement testé par la routine informatique et sur les assertions qui en résultent. L'invention a en conséquence pour objectif de proposer un procédé pour la création d'une description des exigences pour un système incorporé, qui d'une part fasse connaître sans 15 équivoque à tout utilisateur quelle exigence est concernée concrètement, et qui d'autre part soit appropriée pour générer automatiquement à partir de l'exigence décrite un test univoque avec lequel le système incorporé peut être vérifié. Cet objectif est atteint par le fait qu'on enregistre dans un système de traitement de données 20 un vocabulaire constitué de modules de texte en langage naturel sélectionnables, qui peuvent être combinés les uns avec les autres en une description des exigences lisible par machine pour former au moins une phrase en langage naturel, notamment en anglais. L'enregistrement d'un vocabulaire limité constitué de modules de texte en langage naturel 25 sélectionnables offre la possibilité de former à partir des ces modules de texte limités une phrase en langage naturel que tout personne sachant lire et/ou parler la langue naturelle concernée comprendra sans équivoque La restriction du vocabulaire et la mise à disposition de seulement certains modules de texte 30 permettent d'éviter toute ambiguïté lors de la formulation en langage naturel, et que les exigences pourront ainsi être établies de façon univoque et compréhensible. Un aspect essentiel de l'invention sur ce point réside dans le fait que les modules de texte sélectionnables qui sont prescrits par le vocabulaire restreint enregistré dans le système de traitement des données ne peuvent pas être combinés les uns avec les autres dans n'importe 35 quel ordre, tandis qu'un autre aspect essentiel de l'invention prévoit que chaque module de texte sélectionnable dans le vocabulaire restreint mentionné ci-dessus ne soit associé qu'à un 2907933 3 ensemble déterminé, ou pouvant être déterminé, d'autres modules de texte pouvant y être combinés, sachant qu'il est prévu selon le procédé que le système de traitement de données présente automatiquement sur une unité d'affichage, afin de permettre la sélection, pour un module de texte sélectionné les autres modules de texte pouvant y être combinés. 5 Le système de traitement de données crée donc automatiquement après chaque sélection d'un module de texte une liste par défaut des autres modules de texte qui peuvent être combinés au module de texte précédemment sélectionné. On peut dans ce cas faire encore une distinction entre les modules de texte que l'on peut au choix ajouter ou non, et les 10 modules de texte parmi lesquels au moins un doit obligatoirement être sélectionné pour qu'on puisse créer une description de l'exigence sémantiquement et syntaxiquement correcte. Il est ainsi possible de prévoir conformément à l'invention de restreindre par l'intermédiaire du système de traitement de données la possibilité normale de libre choix de l'utilisateur, et en 15 particulier de ne présenter, après une sélection d'un module de texte, notamment par l'utilisateur, qu'une sélection restreinte, déterministe de modules de texte pour utilisation ultérieure. La présentation et la sélection des modules de texte peuvent alors être réalisées en utilisant une possibilité au choix. Les modules de texte peuvent par exemple être présentés sous la forme d'options de menu sélectionnables en particulier au moyen d'une 20 souris et en particulier par un utilisateur. Conformément à un perfectionnement avantageux de l'invention, il est possible de prévoir que les modules de texte soient affectés à des classes d'un méta-modèle d'exigence. Ces classes peuvent être en particulier les classes UML, c'est-à-dire les classes du unified modelling 25 language , qui est souvent utilisé pour la modélisation par exemple de systèmes d'exploitation. Il s'agit là d'un langage normalisé, qui peut par exemple être compris directement et indépendamment de la plateforme par divers ordinateurs, ou bien il est possible de prévoir, pour maintenir la lisibilité par machine, qu'une lecture soit faite dans le système de traitement de données par l'intermédiaire d'une routine informatique spéciale. 30 Il est ainsi possible conformément à l'invention d'obtenir que, parallèlement à la création d'une phrase en langage naturel à partir des modules de texte prescrits, on crée une description de l'exigence qui obéit à des aspects formels qui sont définis par le méta-modèle d'exigence, de sorte que le système de traitement des données crée parallèlement une instance du méta- 35 modèle d'exigence qui représente une description de l'exigence compréhensible pour un système de traitement des données. On crée donc ainsi avec le procédé selon l'invention 5 2907933 4 d'une part la description de l'exigence sous la forme d'une phrase en langage naturel qui est univoque et compréhensible pour tout utilisateur, et d'autre part de préférence parallèlement une instance du méta-modèle d'exigence de base, par exemple dans la description sous forme de classes UML, qui est concrètement compréhensible et exécutable pour l'ordinateur Il est ainsi possible conformément à l'invention de prévoir que pour chaque module de texte sélectionné une instance du méta-modèle d'exigence soit complétée par une instance de la classe du méta-modèle d'exigence liée au module de texte. 10 On entend ici par instance de la classe liée au module de texte un élément concret de la classe concernée. Il peut par ailleurs être prévu selon l'invention que chaque module de texte soit de préférence affecté à une classe et que pour chaque classe soit enregistrée une assertion sur au moins 15 une relation et la direction de la relation par rapport à au moins une autre classe, afin de former à l'aide des relations unidirectionnelles une séquence de classes qui définit un agencement grammaticalement correct des modules de texte affectés aux classes. Cet aspect préféré permet ainsi d'assurer que les modules de texte enregistrés dans le 20 vocabulaire restreint ne peuvent être librement combinés les uns avec les autres, mais qu'il n'existe entre les modules de texte qu'un ordre déterminé de combinaison possible des modules de texte du fait de l'affectation à des classes et des relations ou des associations valides entre elles. 25 Un utilisateur d'un système de traitement de données sur lequel fonctionne un procédé selon l'invention peut ainsi être privé de la possibilité d'effectuer n'importe quelle combinaison de modules de texte, de sorte que sur la base des seuls modules de texte pouvant être sélectionnés est créée une description de l'exigence prescrite de manière déterministe, dans laquelle une variabilité dans la formulation n'est produite que par l'étendue de chaque classe 30 considérée, et donc par le nombre ou la taille de l'ensemble de modules de texte combinables affichés par le système de traitement de données. Une autre solution possible consiste à prévoir d'informer l'utilisateur lorsque aucune description de l'exigence prescrite de manière déterministe n'a été produite après une sélection et de lui offrir la possibilité d'ajouter a posteriori un module de texte aux modules de texte enregistrés. 35 2907933 5 La liaison et la présentation d'un module de texte sélectionné avec un ensemble d'autres modules de texte combinables peut alors s'effectuer de préférence de telle manière que le système de traitement de données détermine tout d'abord pour un module de texte sélectionné la classe du méta-modèle d'exigence qui est affectée au module de texte 5 sélectionné. Il est ensuite possible de déterminer au moins une classe suivante, selon les relations unidirectionnelles entre les différentes classes possibles enregistrées dans le méta-modèle d'exigence, sachant que les éléments ou les instances concrètes de la au moins une classe suivante déterminée sont ensuite regroupés en un ensemble dont les éléments sont représentés par chacun des modules de texte affectés et sont ensuite affichés comme 10 sélectionnables sur l'unité d'affichage du système de traitement de données. L'affichage sous la forme d'un module de texte sélectionnable peut alors s'effectuer par exemple sous la forme d'une option de menu qui peut être sélectionnée par exemple en cliquant avec une souris. Mais un affichage et une sélection peuvent également selon l'invention s'effectuer de toute autre manière. 15 Il est en principe possible de prévoir une distinction entre différents ensembles de modules de texte. Il peut par exemple être prévu qu'existent des ensembles de modules de texte obligatoires, dans lesquels un module de texte doit toujours être sélectionné pour former une exigence syntaxiquement correcte, et il peut par ailleurs exister des ensembles qui 20 comprennent des modules de texte possibles, dans lesquels il n'est pas obligatoire de sélectionner un module de texte, mais dans lesquels une sélection peut être faite si besoin est. Ainsi, il est conforme à l'invention que soient affichés des ensembles de modules de texte obligatoires et des ensembles de modules de texte possibles, les ensembles de modules de textes possibles, en particulier ceux qui concernent des conditions temporelles, pouvant être 25 sautés en ne sélectionnant pas de module de texte. Un ensemble de modules de texte possible de ce type peut par exemple être un ensemble de modules de texte qui concernent des indications temporelles ou tout autre aspect temporel, par exemple des conditions temporelles. Il peut par exemple être prévu dans une exigence 30 qu'une condition donnée ne doit se présenter qu'à un instant donné ou à l'issue d'un temps donné ou selon un autre aspect temporel. Une telle indication temporelle n'est donc pas absolument indispensable pour une description des exigences, mais peut de préférence être utilisée. 35 II est ainsi possible avec le procédé selon l'invention de prévoir que ces ensembles de modules de texte facultatifs puissent être sautés lors d'une sélection. Ce qui peut par exemple 2907933 6 se faire en ce qu'un ensemble de modules de texte facultatifs de ce type est tout d'abord affiché, mais que l'utilisateur informe le système informatique, par exemple en cliquant sur une option de menu appropriée, qu'il ne souhaite pas effectuer de sélection parmi ces modules de texte. Le système informatique effacera alors l'affichage de cet ensemble donné, 5 et soit affichera un autre ensemble de modules de texte possibles, soit passera à l'affichage d'un ensemble de modules de textes obligatoires parmi lesquels l'utilisateur devra alors sélectionner au moins un module de texte. Dans un mode de réalisation privilégié de l'invention, il peut également être prévu que des 10 modules de texte déjà sélectionnés, qui sont entrés dans une description de l'exigence établie, puissent être remplacés par des modules de texte de substitution, ce pour quoi il peut être prévu qu'après la sélection d'un modules de texte à remplacer, le système de traitement de données affiche automatiquement un ensemble de modules de texte de substitution possibles sélectionnables. 15 Suite à la sélection d'un tel module de texte de substitution dans l'ensemble affiché, le module de texte à remplacer peut alors être remplacé automatiquement par le système de traitement de données. La détermination des modules de texte de substitution possibles peut dans ce cas se faire par le fait que le système de traitement des données détermine tout d'abord à 20 quelle classe le module de texte sélectionné à remplacer appartient et qu'il forme ensuite un ensemble de modules de texte qui appartiennent tous à cette classe, puis qu'il affiche cet ensemble. L'ensemble correspondra globalement pour l'essentiel au contenu de la classe déterminée, moins le module de texte sélectionné à remplacer. 25 Le procédé selon l'invention fait apparaître qu'il est possible d'une part d'établir une description des exigences en langage naturel clairement lisible et compréhensible pour l'utilisateur, et d'autre part de produire parallèlement par association avec un méta-modèle d'exigence de base une instance concrète du méta-modèle d'exigence compréhensible pour l'ordinateur. 30 Il est ainsi possible selon un autre aspect préféré de l'invention qu'après la création d'une description de l'exigence en langage naturel, le système de traitement de données effectue une transformation par laquelle la description de l'exigence est convertie en une spécification de test en langage naturel indépendante de la plateforme. Cette spécification de test peut 35 également être obtenue par une instance d'un méta-modèle de test qui est formée par la transformation. La transformation à effectuer est donc basée sur des règles de mappage 2907933 7 selon lesquelles l'instance du méta-modèle d'exigence est convertie en l'instance du méta-modèle de test. Il peut alors y avoir en partie entre les deux méta-modèles des concordances concernant les classes et les instances concrètes qu'elles contiennent, ainsi que des divergences qui sont mappées les unes dans les autres par la transformation. 5 Il est donc prévu dans un mode de réalisation privilégié que pour effectuer la transformation, l'instance du méta-modèle d'exigence formée parallèlement à l'exigence en langage naturel soit convertie par la transformation du modèle en une instance du méta-modèle de test, ce pour quoi, comme mentionné ci-dessus, au moins une partie des éléments de l'instance du 10 méta-modèle d'exigence est transformée en éléments d'une instance du méta-modèle de test. Il peut alors selon l'invention être prévu qu'une instance du méta-modèle de test ainsi obtenue soit à nouveau présentée par le système de traitement de données sur l'unité d'affichage sous la forme d'une spécification de test en langage naturel, clairement lisible et compréhensible pour un utilisateur, ce pour quoi il peut être prévu selon l'invention qu'aux éléments de 15 l'instance du méta-modèle de test soient aussi affectés, comme également prévu pour le méta-modèle d'exigence, des modules de texte en langage naturel. Ces modules de texte affectés peuvent ensuite être présentés sur l'unité d'affichage au moyen du système de traitement de données dans un ordre qui est donné par la syntaxe à la base du méta-modèle de test, de sorte qu'est formée également pour cet affichage une phrase en langage naturel. 20 Dans le cadre d'une transformation, il peut être prévu dans un mode de réalisation que les éléments de l'instance du méta-modèle d'exigence qui décrivent une condition soient transformés en éléments de l'instance du méta-modèle de test qui entraînent une affectation de valeurs aux entrées d'un système incorporé. Il peut par exemple être prévu que la porte 25 d'un véhicule doit être ouverte si se présente la condition selon laquelle on a appuyé sur une touche de la commande à distance. Cette condition, qui est exprimée dans la description de l'exigence, est changée lors d'une transformation en une affectation de valeur, et ce de telle manière qu'au bouton de la commande à distance ou à l'entrée prévue pour lui sur le système incorporé est affectée une valeur qui représente l'état pressé de ce bouton. Il peut ensuite 30 être par ailleurs prévu dans le cadre d'une transformation que les éléments de l'instance du méta-modèle d'exigence qui décrivent une réaction à une condition soient transformés en éléments de l'instance du méta-modèle de test qui vérifient les valeurs des sorties. En référence au même exemple, il est dit dans l'exigence que selon la condition ci-dessus la porte du véhicule doit être ouverte lorsqu'on a appuyé sur le bouton. La réaction à la condition 35 est donc l'ouverture de la porte, ce qui veut dire que dans l'instance du méta-modèle de test une sortie du système incorporé, donc par exemple de l'appareil de commande du véhicule, 2907933 8 qui est affectée à la porte, est vérifiée quant à sa valeur pour qu'on puisse vérifier à l'aide de la valeur lue si une valeur qui représente une porte ouverte est enregistrée. Pour la création d'une description des exigences avec le procédé selon l'invention, il peut 5 également être prévu d'utiliser des modules de texte qui prennent en compte des aspects temporels. On peut ainsi décrire des conditions telles que par exemple après un temps déterminé où à un moment déterminé, ainsi que les réactions correspondantes. On peut également prévoir de formuler à l'intérieur d'une exigence des aspects temporels imprécis, par exemple le fait qu'une réaction ne doit se produire qu'à l'issue d'un temps minimum 10 donné. Une telle indication temporelle imprécise dans la description d'une exigence est transformée selon l'invention en éléments de l'instance du méta- modèle de test qui comprennent un degré de liberté concrétisable dans le temps. Ceci veut dire que l'instance correspondante du méta-modèle de test concernant l'aspect 15 temporel mentionné dans la description de l'exigence n'est pas encore concrétisée, de sorte qu'un utilisateur qui souhaite effectuer le test doit tout d'abord procéder à une concrétisation du degré de liberté. L'avantage réside donc en particulier en ce que différents utilisateurs quoi souhaitent effectuer le test le cas échéant selon des aspects temporels différents peuvent effectuer individuellement la concrétisation du degré de liberté prévu. 20 Selon un autre aspect de l'invention, il peut également être prévu qu'un programme de test dépendant de la plateforme soit généré à partir de l'instance du méta-modèle de test indépendante de la plateforme. Mais ceci implique qu'on procède tout d'abord à une concrétisation si des degrés de liberté temporels non encore concrétisés dans le temps sont 25 prévus dans l'instance du méta-modèle de test. Le programme de test dépendant de la plateforme ainsi formé peut être exécuté sur un ordinateur de test prévu à cet effet, pour tester soit l'appareil de commande simulé sur ledit ordinateur, soit l'appareil de commande concret raccordé audit ordinateur. On peut alors prévoir de simuler également un environnement naturel pour l'appareil de commande pendant le test, de sorte que l'appareil 30 de commande peut être testé dans des conditions certes réelles, mais pas dans son environnement réel, ce qui est généralement à éviter pendant les phases de test. L'invention concerne également un produit de programme informatique qui est enregistré sur un support de données et qui met en oeuvre un procédé selon l'invention lorsqu'il est exécuté 35 sur un système de traitement des données. 2907933 9 Les dessins joints présentent des modes de réalisation et des informations relatives à l'invention. 5 10 15 20 25 30 35 Figure 1 : Figure 2 Figure 3 Figure 4 : Figure 5 Figure 6 Figure 7 : Figure 8 Figure 9 Figure 10 : Figure 11 : Figure 12 : Figure 13 : Figure 14 : Figure 15 : Figure 16 : Figure 17 : Figure 18 : Figure 19 : Figure 20 : Figure 21 : Figure 22 : Figure 23 : Figure 24 : Figure 25 : Figure 26 : Figure 27 : Figure 28 : Figure 29 : Figure 30 : Figure 31 : Figure 32 : Concept global Génération d'un test sur la base d'une exigence Système incorporé (selon [LR05]) Modèle cascade (inspiré de [Ba198]) Modèle V (selon [Ba198]) Partition (inspiré de [Ba198]) Exigence : témoin lumineux feux de brouillard arrière Exigence : éclairage intérieur Fonctionnalité d'un système : à partir d'une pré-condition se produit une réaction attendue Méthodes d'assurance de la qualité Composants d'un test Structure des composants nécessaires pour tester un système incorporé Model-in-the-loop et Software-in-the-loop Hardware-in-the-loop Processus de test Etape 2 : Coeur de l'exigence (selon [Rup04]) Etape 4 : (selon [Rup04]) Etape 5 : (selon [Rup04]) Relation entre objet d'interface, variable de l'objet de test, valeur et état Diagramme des classes UML du méta-modèle d'exigences Instance du méta-modèle Synonymes Exigence avec un opérateur Exigence sans opérateur Exigence avec plusieurs opérateurs Extrait du méta-modèle avec modélisation des opérateurs Extrait du méta-modèle avec conditions temporelles Exigence avec conditions temporelles Réaction attendue une fois toutes les pré-conditions remplies Réaction attendue parallèlement aux pré-conditions Dépendances temporelles L'élément Soonest dans la réaction attendue 2907933 10 Figure 33 : Différents types d'interface de l'objet de test aux différents niveaux de développement d'un logiciel Figure 34 : Accessibilité des interfaces Figure 35 : De l'exigence indépendante de la plateforme au test spécifique à la plateforme 5 Figure 36 : Mappage d'un objet d'interface indépendant de la plateforme sur plusieurs variables spécifiques à la plateforme Figure 37 : Méta-modèle de spécification de test dans le contexte du concept global Figure 38 : Extrait du méta-modèle de spécification de test Figure 39 : Séquence de test avec deux parties de séquence de test modélisées 10 partiellement parallèlement Figure 40 : Mappage de la durée sur différentes constructions verbales Figure 41 : Transformation d'un élément Implies Figure 42 : Transformation d'un élément Iff Figure 43 : Transformation d'un élément InterfaceElement 15 Figure 44 : Conversion d'une expression inversée globalement en expressions inversées séparément Figure 45 : Transformation d'un opérateur binaire Figure 46 : Exigence comportant des degrés de liberté dans la description temporelle Figure 47 : Chevauchement d'intervalles de temps 20 Figure 48 : Implémentation de test dans le contexte du concept Figure 49 : Mappage des instances de la spécification de test sur les étapes de test d'un test exécutable Figure 50 : De la spécification de test à l'implémentation de test Figure 51 : Mappage de l'objet d'interface et de l'état de la spécification de test sur les 25 variables et valeurs de la plateforme de test Figure 52 : Exigence Figure 53 : Interface utilisateur graphique pour la production de constructions de phrases Figure 54 : Extrait d'un document XML contenant des assertions sur la forme d'une phrase Figure 55 : Création d'une exigence 30 Figure 56 : Option de menu äskip pour sauter la spécification des conditions temporelles Figure 57 : Remplacement d'une construction textuelle Figure 58 : Extension d'une partie de phrase supplémentaire reliée par un opérateur Figure 59 : Ajout d'un opérateur Figure 60 : L'opérateur NOT a été ajouté 35 Figure 61 : L'algorithme, représenté sous la forme d'un pseudo-code Figure 62 : Successeurs de v 2907933 11 Figure 63 : Figure 64 : Figure 65 : Figure 66 : 5 Figure 67 : Figure 68 : Figure 69 : Figure 70 : Figure 71 : 10 Figure 72 : Figure 73 : Figure 74 : Figure 75 : Compositum Méta-modèle de description des exigences Capture d'écran : Génération d'une spécification de test De la spécification de test à une implémentation de test dans un outil de test De la spécification de test à une implémentation de test dans AutomationDesk Séquence de test dans AutomationDesk Séquence de test dans AutomationDesk Séquence de test dans AutomationDesk Séquence de test dans AutomationDesk Scénario témoin lumineux allumé Scénario témoin lumineux éteint Scénario airbag Scénario éclairage intérieur éléments de base aspects temporels opérateur dépendance relative 15 La figure 1 présente une vue générale du procédé selon l'invention dans ses modes de réalisation obligatoires et facultatifs. On peut voir sur la figure une vue par l'utilisateur, qui est par exemple produite par le fait que des modules de texte sont mis à la disposition d'un utilisateur sur une unité d'affichage au 20 moyen d'un système de traitement de données. Un utilisateur peut sélectionner les modules de texte, qui sont proposés en nombre restreint, et les regrouper pour former une exigence textuelle en langage naturel, par exemple en anglais. À gauche de la vue pour l'utilisateur, on peut voir que l'exigence créée textuellement est formalisée en un méta-modèle d'exigence formel de base. Il apparaît donc clairement que parallèlement à la création textuelle en 25 langage naturel de l'exigence, le système de traitement de données crée une instance formalisée d'un méta-modèle d'exigence, par exemple d'un modèle UML. Par la transformation du modèle illustrée par ailleurs, l'instance du méta-modèle d'exigence peut être convertie en une instance du méta-modèle de test qui décrit la spécification de test 30 sous la forme d'une instance formelle lisible pour l'ordinateur. Cette spécification de test formelle, donc l'instance du méta-modèle de test, est représentée de façon textuelle en langage naturel dans une présentation de la spécification de test qui est à son tour lisible en langage naturel et donc entièrement et clairement compréhensible pour l'utilisateur sur l'affichage du système de traitement des données. 35 2907933 12 Sur la base de l'instance du méta-modèle de test formellement créée, il est par ailleurs possible d'effectuer une génération, dépendante de la plateforme, d'un programme de test qui peutêtre exécuté sur le système de traitement des données qui est également prévu pour la création de l'exigence, ou sur un autre système de traitement des données. Dans ce cas, on 5 peut en outre prévoir que des assertions supplémentaires concernant les variables, les valeurs, les plateformes ou autres puissent être ajoutées dans le programme de test dépendant de la plateforme, par exemple en y reliant le contenu d'une bibliothèque. Par ailleurs, il est également possible de prévoir selon l'invention que soient ajoutés par l'utilisateur des modules de texte auxquels peuvent à leur tour être affectées des instances 10 dans le méta-modèle d'exigence. Un utilisateur peut ainsi également procéder à une extension du méta-modèle d'exigence de base. D'autres modes de réalisation concrets de l'invention sont décrits ci-après plus en détail à l'aide de plusieurs exemples, précédés de l'exposé de quelques informations de base. 15 Sur ce point il convient par ailleurs de préciser que pour ce qui concerne tous les modes de réalisation exposés ci-dessus ou ci-après, les caractéristiques techniques mentionnées en relation avec un mode de réalisation ne sont pas destinées à n'être utilisées que pour ce mode de réalisation spécifique, mais également pour chacun des autres modes de réalisation. 20 Toutes les caractéristiques techniques de l'ensemble de la description de la présente invention doivent donc être considérées comme entrant dans le cadre de l'invention, et peuvent être utilisées librement combinées les unes aux autres ou isolément. L'utilisation de systèmes incorporés est de plus en plus répandue. On les trouve actuellement 25 par exemple dans les véhicules, dans les distributeurs de billets ou dans les machines à laver. Les automobiles sont équipées de plus de 50 appareils de commande reliés, qui assurent par exemple les tâches de commande des vitres ou de freinage ABS. Sans un processus de développement systématique, un tel réseau de systèmes complexes ne peut être produit à un niveau de qualité acceptable dans des délais raisonnables. Une assurance de la qualité 30 systématique est un élément constitutif présent dans tout processus de développement de systèmes de ce type. Dans la pratique, les tests font partie des mesures de qualité les plus répandues. L'augmentation constante de la part de logiciel dans les systèmes incorporés s'accompagne 35 d'une augmentation de l'effort consacré aux tests [BNO3]. Étant donné que les coûts de développement augmentent avec l'augmentation de cet effort, on cherche le plus possible à 2907933 13 automatiser les tests pour réduire cet effort. Si l'exécution automatisée des tests fait déjà partie des techniques standard, l'automatisation du développement des tests représente encore un vaste domaine de recherche. 5 Les méthodes actuelles reposent sur des descriptions des exigences formalisées, par exemple sur des automates d'état [CFT01 ]. Mais les tests produits à partir de descriptions comportementales formellement spécifiées ne couvrent jamais que la vérification que le logiciel produit est correct par rapport à la spécification formelle. Il n'est possible de savoir si un système a été effectivement développé pour comporter les exigences souhaitées par le 10 client qu'en comparant le système aux exigences initialement définies par le client. La figure 2 en présente un exemple. Les tests qui sont appliqués à l'appareil de commande doivent être générés à partir de ces exigences. La présente invention présente une méthode systématique pour la génération automatique de 15 tests qui est basée sur des exigences en langage naturel. Mais le langage naturel n'est pas univoque, et les exigences ainsi décrites ne le sont donc pas non plus. Ce qui fait apparaître la nécessité d'affecter tout d'abord une signification univoque à la description textuelle des exigences. 20 Dans le cadre de la présente invention, on établit un méta-modèle d'exigence qui définit une syntaxe pour une spécification et un vocabulaire pour la description de l'exigence. Le vocabulaire est assorti d'une sémantique. La création d'une exigence sur la base du modèle produit une exigence formelle. Elle forme la base de la génération d'un test qui vérifie si le système répond à l'exigence établie. 25 D'une exigence sont dérivées des étapes de test formelles, à partir desquelles il est possible de produire une implémentation de test. Les étapes du test sont présentées à l'utilisateur sous la forme d'un langage naturel, de sorte que le déroulement du test est compréhensible par l'utilisateur, et l'utilisateur peut classer les résultats d'un test généré exécutable. La présente 30 invention englobe la conception d'un méta-modèle pour la description des étapes de test, ainsi qu'une transformation du modèle qui dérive une instance du méta-modèle pour des étapes du test à partir d'une instance du méta-modèle d'exigence. Vient ensuite la génération d'une implémentation de test, qui teste une fonctionnalité d'un système incorporé définie dans une exigence. Un prototype montre comment les concepts présentés peuvent trouver une 35 application dans la pratique. Le prototype permet à la fois une création confortable d'une exigence en langage naturelle, et une génération automatique du déroulement des étapes 2907933 14 d'un test. À partir ce ces étapes définies du test, on peut produire un test exécutable. Ci- après sont tout d'abord exposées les bases qui servent à la compréhension et à l'agencement de la présente invention. En font partie la description du processus de 5 développement de systèmes incorporés, la description des exigences, et le test des logiciels. Sont ensuite discutés les concepts existants relatifs aux questions annexes. La partie suivante de la description de l'invention concerne le concept de formalisation d'une exigence en langage naturel, ainsi que la conception d'une génération automatique de tests à partir de ces exigences. Elle montre par ailleurs comment a lieu un mappage sur un test concret. Vient 10 ensuite la description de la transformation de ce concept en prototype. Les possibilités d'utilisation de la génération automatique d'un test sont enfin présentées à l'aide d'exemples d'applications et d'une évaluation du prototype. La description de l'invention se termine par un récapitulatif et une vue d'ensemble. 15 La présentation des bases commence par la description du processus de développement des systèmes incorporés et en révèle les caractéristiques. Vient ensuite une observation précise de la création des exigences ainsi que des tests, car ces deux phases du développement sont d'une importance déterminante pour le thème de la génération automatique d'un test à partir d'exigences en langage naturel. 20 Cette section définit les systèmes incorporés et en décrit le processus de développement. Vient ensuite une délimitation entre le développement des systèmes incorporés et le simple développement de logiciels. 25 Un système incorporé est une unité logicielle/matérielle (software/hardware) qui est reliée à un système global par l'intermédiaire de capteurs et d'activateurs, et assure ainsi des tâches de surveillance, de commande ou de régulation [BvdK98]. Les capteurs et les activateurs constituent ensemble les interfaces entre le système incorporé et l'environnement. Les capteurs convertissent des actions mécatroniques en signaux informatiques. Les activateurs 30 convertissent les signaux informatiques en actions mécatroniques [Gmb99]. Les activateurs sont également appelés actuateurs, de l'anglais actuator. Ces systèmes ne sont généralement pas visibles par l'utilisateur humain, étant donné qu'ils fonctionnent intégrés dans le système global. L'utilisateur interagit donc sans le savoir avec 35 des systèmes incorporés qui équipent par exemple les véhicules, les distributeurs de billets ou les machines à laver. Dans le document [LR05] figure la définition suivante d'un système 2907933 incorporé : Les systèmes incorporés se différencient des autres applications informatiques en premier lieu en ce qu'ils agissent directement sur un environnement physique. 5 L'ordinateur est utilisé en tant que machine électronique qui gère les processus physiques environnants. L'observation et la commande des processus physiques de l'environnement sont assurées par des capteurs et des activateurs qui constituent l'environnement de communication (Environment) entre les processus physiques et le système informatique . 10 La figure 3 présente un système incorporé qui observe des processus physiques au moyen de capteurs, et les commande au moyen d'activateurs. Les capteurs et les activateurs peuvent également être physiquement partie intégrante du système incorporé. On peut citer comme exemple de système incorporé un appareil de 15 commande qui représente, en particulier dans la technique automobile, la transposition physique d'un système incorporé [BvBK98]. Un appareil de commande est généralement constitué d'un processeur, d'une mémoire de travail et d'autres composants électroniques. Il assure les tâches de commande des processus techniques dans un système global. La commande est définie comme suit dans le document [Gmb99] selon 20 la norme DIN 19226 : La commande est dans un système le processus par lequel une ou plusieurs grandeurs, appelées grandeurs d'entrée, influent sur d'autres grandeurs, appelées grandeurs de sortie, selon les lois propres audit système . 25 Les systèmes incorporés peuvent être classés dans la catégorie des systèmes réactifs [LR05]. Un système réactif interagit en permanence avec son environnement. Il convertit des évènements d'entrée, dont on ne peut la plupart du temps pas savoir quant ils se produiront, en évènements de sortie. Ceci se produit souvent dans le respect de prescriptions 30 temporelles [BvBK98]. Un appareil de commande de porte d'un véhicule constitue un exemple classique de système réactif. En fonction de grandeurs d'entrée déterminées, telles que par exemple un signal produit par l'actionnement de la commande à distance, il se produit une réaction de l'appareil de commande de porte, par exemple par le fait qu'il verrouille ou déverrouille la serrure. 35 15 Dans la plupart des cas, la réalisation correcte des tâches de surveillance, commande et 2907933 16 régulation qu'assume un système incorporé ne dépend pas uniquement de la réalisation correcte fonctionnelle, mais également du temps imparti à l'accomplissement de la tâche. La fonctionnalité d'un airbag ne peut pas être évaluée comme correcte s'il réagit certes à un accident, mais si le temps de réaction s'élève à 10 minutes. Les systèmes incorporés sont en 5 conséquence généralement des systèmes en temps réel. Un système en temps réel exécute des fonctions en tenant compte de conditions temporelles, de sorte que la fin de l'exécution d'une fonction est prévisible [LR05]. Les systèmes incorporés sont d'une manière générale des systèmes numériques, qui 10 détectent des signaux continus (analogiques) et les convertissent un signal discret (numérique). À proprement parler, les systèmes numériques fonctionnent toujours en mode discret parce qu'ils détectent des signaux analogiques dans le monde réel. La détection des signaux analogiques est effectuée par des logiciels. Étant donné qu'il s'écoule obligatoirement entre deux cycles logiciels du temps consacré aux calculs, l'exécution ne peut pas être 15 continue, mais est discrète dans le temps. La discrétisation est donc déterminée par la fréquence d'horloge ou par la fréquence de détection du signal analogique, qui n'est que d'une grandeur finie. Exemple: 20 Un verrouillage centralisé est une fonction qui est réalisée par plusieurs appareils de commande. À ce point nous décrivons le comportement d'une fonction de verrouillage centralisé, qui sera utilisée dans toute la description de l'invention à titre d'exemple de scénario d'application. 25 Un verrouillage centralisé fait aujourd'hui partie de l'équipement de série de nombreux véhicules. Il offre au conducteur et aux passagers un meilleur confort, mais également une plus grande sécurité. Outre le verrouillage et le déverrouillage simultané de toutes les portes, d'autres fonctionnalités comme la fermeture de toutes les vitres lors du verrouillage ou le déverrouillage de toutes les portes en cas d'accident, peuvent faire partie des tâches 30 d'un verrouillage centralisé. Un verrouillage centralisé doit bien sûr être testé, car ses fonctionnalités présentent certains aspects critiques pour la sécurité. Si le déverrouillage d'une porte ne se produit pas en cas d'accident, cette défaillance risque d'entraîner des dommages corporels. Le test d'une fonction du verrouillage centralisé consiste à tester le comportement des appareils de commande qui réalisent conjointement cette fonction. 35 2907933 17 La réalisation d'une fonctionnalité de verrouillage centralisé nécessite habituellement un appareil de commande pour chaque porte, une commande à distance, et une serrure par porte. La communication entre les appareils de commande se fait par l'intermédiaire d'un système de bus. Un appareil de commande de porte surveille des capteurs, par exemple pour 5 définir le déverrouillage de la porte par le bouton de porte, et active différents activateurs. Pour le verrouillage centralisé, tous les boutons de porte sont mis en position basse par les activateurs . Cette section expose le mode opératoire du processus de développement de logiciels en 10 général, tel qu'il est présenté dans le document [Ba198], puis décrit ensuite les particularités concernant les systèmes incorporés. Le processus de développement d'un logiciel est sensiblement différent de celui d'autres produits. Un logiciel est immatériel, et la progression de son développement est très difficile à 15 estimer. L'explication réside en ce que les nouvelles connaissances acquises pendant le processus de développement ont d'une part des répercussions sur la suite du développement, mais risquent d'autre part d'influer également sur les résultats déjà obtenus. Ce qui entraîne le cas échéant des extensions ou des modifications d'aspects déjà finalisés, de sorte que certains produits partiels ne sont jamais finis que sous réserve [Ba198]. Du fait de 20 ces propriétés mentionnées du processus de développement d'un logiciel, il est très difficile de faire une estimation du temps, et donc un calcul des coûts, en conséquence de quoi de très nombreux projets avortent, et causent ainsi des pertes. À ce stade précis commence la gestion des logiciels, qui se sert de différentes méthodes pour 25 concevoir le déroulement du développement pour qu'il puisse le mieux possible être planifié et estimé. Les modèles de description du déroulement du processus de développement apportent une contribution essentielle à la structuration de la procédure. Le terme de modèle procédural apparaît également souvent dans la littérature. L'utilisation de modèles de processus influe sur la facilité de planification du développement et permet des estimations. 30 Le succès du développement d'un logiciel dépend essentiellement de l'élimination précoce des défauts. Plus une modification nécessaire doit intervenir tard, plus le travail de mise au point coûte cher, du fait qu'il s'étend sur plusieurs stades du développement Sur la figure 4 sont représentées les principales phases du développement d'un modèle de 35 processus. Les attentes et les souhaits des clients concernant le système à développer sont tout d'abord définis sous forme d'exigences. De là sont dérivées les exigences du logiciel. 2907933 18 Pour pendre en compte les autres systèmes existants et l'environnement, on effectue une analyse des conditions cadre, étant donné qu'elles peuvent influer sur le nouveau système. Vient ensuite la création du projet de logiciel, qui est transformé dans la phase d'implémentation. Le logiciel développé est soumis à de nombreux tests avant d'être mis en 5 exploitation. De nombreux modèles de processus divisent encore la phase du projet en projet préliminaire et projet détaillé. Dans la première phase, on établit dans les grandes lignes le concept du système global, tandis que dans la suivante, on s'intéresse aux fonctionnalités des différents composants. 10 Le modèle présenté sur la figure 4 est appelé modèle en cascade. Ce fut le premier modèle procédural mûrement réfléchi, qui a servi de base à de nombreux modèles développés par la suite. Dans un modèle en cascade, la phase suivante ne commence en principe qu'une fois la phase précédente terminée, les phases se construisant les unes sur les autres [Ba198]. Au début de chaque phase sont définis des objectifs qui servent à orienter les activités de la 15 phase pendant la mise en oeuvre. Une documentation est produite à l'issue de chaque activité. Elle est utilisée pour vérifier si tous les objectifs définis avant la phase ont été atteints. Si tel n'est pas le cas, on crée un document de modification, à la suite de quoi a lieu un retour au début de la phase précédente. Ce retour d'information permet plusieurs itérations depuis l'établissement des objectifs jusqu'à la documentation des différentes phases en passant par 20 la réalisation. Des vérifications intensives sont de ce fait effectuées à chaque stade, de sorte que les défauts peuvent être découverts le plus tôt possible. Le modèle en V est une extension du modèle en cascade. Il intègre l'assurance de la qualité, chaque phase étant l'objet d'un test. Comme on le voit sur la figure 5, les différents modules 25 implémentés sont vérifiés par un test de module. On effectue ensuite un test d'intégration, qui est caractérisé par un test de comportement de plusieurs modules combinés. La vérification de l'ensemble du système s'effectue dans le cadre du test de système, suivi du test de réception, qui contrôle les transpositions des exigences du client [BaI98]. 30 Initialement, le modèle en V a été développé pour les systèmes incorporés [Ba198], ce pour quoi le logiciel est toujours considéré comme partie intégrante d'un système informatique. L'activité de développement d'un tel système comprend, outre le développement du logiciel, également le développement du matériel, de sorte que des parties électroniques peuvent exister. Le plus gros défi consiste alors dans la concordance des processus de 35 développement des différents composants. Du fait que le logiciel ne peut plus être considéré isolément, son processus de développement en tant que système incorporé est différent d'un 2907933 19 simple développement de logiciels. L'intégration du logiciel dans un système matériel implique une compréhension précise du matériel. Par ailleurs, il se produit une forte intégration du logiciel avec l'environnement physique. En outre, il est nécessaire de faire soigneusement concorder les processus les uns avec les autres dans toutes les phases. Les activités de 5 spécification, de modélisation et de vérification des relations dynamiques sont extrêmement importantes. Des défauts identifiés tardivement, par exemple défauts de spécification ou de concordance, risquent de donner lieu à des modifications matérielles coûteuses [LR05]. Le modèle en V prévoit pendant le processus de développement de systèmes incorporés une 10 partition du développement global en plusieurs paquets de travail. La figure 6 illustre une partition de ce type. Après la définition des exigences au niveau du système global, on effectue une subdivision de l'ensemble de l'activité de développement en segments. Ces derniers sont à leur tour subdivisés en unités matérielles et unités logicielles. Les unités logicielles sont constituées exclusivement de plusieurs modules logiciels. La partition décrite 15 est effectuée principalement pendant la phase de projet, suivie du développement des différents modules qui sont à nouveau regroupés pendant le test d'intégration [Ba198]. Les activités contenues dans le modèle en V sont effectuées les unes après les autres dans le temps, dans l'ordre dans lequel elles sont agencées dans le modèle. Ceci permet d'assurer 20 que toutes les opérations de test n'ont lieu qu'après l'implémentation. Mais les défauts ne se produisent souvent pas que pendant l'implémentation, mais beaucoup plus tôt. Dans la phase de projet, des exigences peuvent donner lieu à des erreurs d'interprétation, de sorte que le projet de système est déjà défectueux, et qu'il n'est pas possible de produire un système correct du point de vue du client. Les défauts provoqués dans les premières phases, qui ne 25 sont découverts et éliminés que plus tard, en entraînent d'autres qui se répercutent durant l'ensemble du développement. Ceci contribue à une potentialisation des défauts. Selon le document [Ba198], plus de 50 % de tous les défauts qui interviennent à l'intérieur de l'ensemble du processus de développement se produisent pendant la phase de projet et d'exigences. Ils ne sont pour la plupart découverts que par les tests de réception dans la 30 phase d'exploitation. Les projets logiciels devenus de plus en plus complexes au fil du temps nécessitaient pour assister les développeurs des techniques qui complètent les modèles de processus comme le modèle en V. La cause de 15 % à 40 % de tous les défauts logiciels dans l'électronique 35 automobile résidait dans des spécifications incomplètes ou imprécises. Entre 40 % et 50 0/0 des problèmes se produisaient pendant la phase d'implémentation, et la moitié de ces défauts 2907933 20 avaient pour cause des modifications successives [ONSO6]. Le développement de logiciels basé sur des modèles a évolué en une méthode standard, visant à donner au projet de systèmes complexes une structure transparente, et à permettre d'effectuer les tests dans les premières phases. Par ailleurs, l'utilisation de modèles permet d'éliminer une grande partie 5 des problèmes qui seraient provoqués par des spécifications ambiguës ou incomplètes. Les documents Model-Driven Engineering (MDE) [Ken02] et Model-Driven Architecture (MDA) [MDA02] décrivent les concepts du développement de logiciels basé sur des modèles. L'approche MDE propose entre autres le développement à différents niveaux d'abstraction, 10 ainsi que l'organisation et l'automatisation des activités de test. Dans ce cas, l'architecture et le comportement des systèmes à créer sont projetés sous la forme de modèle, par exemple en utilisant les notations standard du langage UML [Obj05]. Un modèle est une abstraction d'un objet du monde réel [Ba198]. 15 Ces modèles sont à la fois lisibles par machine et compréhensibles pour l'homme. La lisibilité par machine permet un affinement des modèles assisté par des outils, de sorte que le processus de développement peut se dérouler de manière automatisée itérativement de l'abstrait vers des modèles de plus en plus concrets. Ce mode opératoire structure le processus de développement et le rend transparent, de sorte que la complexité s'en trouve 20 réduite. Des techniques formelles sont utilisées pour la vérification du fonctionnement correct des modèles. Il s'agit de tester si un modèle concret correspond aux spécifications du modèle qui se situe à un niveau d'abstraction plus élevé. Il est par ailleurs possible d'utiliser des modèles pour tester les fonctionnalités avant que le système ne soit entièrement développé. Ceci permet de découvrir des défauts dans les premières phases du processus de 25 développement. Dans la MDA existe une méthodique visant à dériver une implémentation à partir d'un modèle spécifié. Si des modifications sont apportées au modèle, la génération d'un nouveau code programme évite des incohérences entre le code et le modèle. Ce concept évite les défauts 30 qui risquent de se produire pendant la programmation manuelle. À l'heure actuelle, le développement basé sur des modèles s'est imposé dans la pratique dans de nombreux secteurs. Dans l'industrie automobile à titre d'exemple pour le domaine du développement de systèmes incorporés, on utilise pendant la phase de projet des modèles 35 mathématiques et des formes de description de haut niveau, qui aboutissent à une spécification sous la forme d'un modèle exécutable. Les modèles de description des 2907933 21 algorithmes de commande et de régulation sont généralement conçus sous la forme d'ordinogrammes. Dans un environnement approprié de modélisation et de simulation, comme par exemple MATLAB /Simulink , ces spécifications conçues sous la forme d'un modèle peuvent être simulées, de sorte que le comportement du logiciel peut être observé et 5 évalué dès la phase du projet. Cela permet d'effectuer les tests dès la phase du projet, de sorte que les défauts peuvent être découverts et éliminés dès ce stade. Les modèles peuvent être utilisés à tous les niveaux du projet de logiciel [ONSO6]. Dans cette section est présenté le processus de développement d'un logiciel en utilisant les 10 modèles de processus en cascade et le modèle de processus en V. Vient ensuite une description du développement de logiciels basé sur des modèles, qui complète l'utilisation des modèles de processus. Quel que soit le modèle de processus utilisé, il existe toujours dans le développement une phase dans laquelle les exigences sont définies, ainsi qu'une phase de test. Les méthodes des descriptions des exigences, ainsi que les techniques de test, sont décrites plus en détail 15 ultérieurement. Les modèles de processus, tels que par exemple le modèle en cascade et le modèle en V déjà présentés, commencent par la phase de définition des exigences. Pour que les exigences puissent être définies au début de processus de développement, une communication doit 20 exister entre le client et le fournisseur. Le client décrit les idées et les souhaits qu'il fixe au produit à développer. Ces derniers aboutissent aux exigences. Le rôle du fournisseur comprend l'analyse des exigences du client, pour s'approcher le plus possible de l'objectif qui consiste à fabriquer le produit souhaité à la plus grande satisfaction possible du client. Même si dans de nombreuses branches industrielles, le client ne participe pas à la création des 25 exigences, comme dans l'industrie automobile, le scénario client/fournisseur se retrouve toutefois dans la plupart des processus de production. Si les pièces nécessaires à la production sont achetées auprès d'un sous-traitant, le sous-traitant représente le fournisseur et le constructeur devient pour sa part le client. Le constructeur doit communiquer ses exigences au sous-traitant. 30 La notion d'exigence est définie comme suit dans le document [IEE90] de l'Institut des ingénieurs électriciens et électroniciens (IEEE) (Institute of Electrical and Electonics Engineers) : 35 1. Nature ou aptitude nécessaire à un utilisateur pour résoudre un problème ou atteindre un objectif. 5 2907933 22 2. Nature ou aptitude qu'un système ou une partie d'un système doit remplir ou posséder pour répondre à un contrat, une norme, une spécification, ou autre document donné formel. 3. Représentation documentée d'une condition ou d'une aptitude selon 1 ou 2. Le SOPHIST GROUP donne dans le document [Rup04] une définition simplifiée et compréhensible dans la pratique de la notion d'exigence : Une d'exigence est une information relative à une propriété ou une prestation d'un 10 produit, d'un processus, ou de la personne impliquée dans le processus . La difficulté consiste à comprendre les descriptions du client de la manière dont il se les représente. Plus le vocabulaire professionnel et le niveau de connaissance des interlocuteurs sont différents, plus ce processus est susceptible de donner lieu à des erreurs. Mais les 15 différences de mentalité, de même que l'empreinte sociale et l'expérience,influent également sur la compréhension. Ce problème trouve ses causes dans le processus de projection qui a lieu lors de la formulation des exigences en langage naturel. Ces problèmes ne se posent pas aussi gravement dans une relation constructeur/sous- 20 traitant. Étant donné que dans ce cas, les deux parties sont la plupart du temps des spécialistes, elles peuvent communiquer au même niveau. Mais dans les entreprises collaborent souvent des personnes provenant de domaines de spécialisation différents. Ces structures interdisciplinaires ont pour avantage que des compétences existent dans chaque domaine de spécialisation, et que les aspects les plus divers peuvent ainsi être pris en 25 compte dans le développement. Il est par exemple fréquent que des ingénieurs et des informaticiens collaborent au développement de systèmes incorporés, étant donné que les connaissances des deux sont nécessaires. Mais la communication entre des spécialistes de domaines de spécialisation différents peut entraîner les problèmes décrits ci-dessus, de sorte que les difficultés de description des exigences ne sont pas aplanies par la seule participation 30 de spécialistes. Ci-après sont exposés les problèmes de description des exigences tels qu'ils sont décrits dans le document [Rup04]. Chaque individu a une perception personnelle de la réalité. Les aspects personnels importants sont en avant-plan, de sorte que la perception ne contient 35 qu'une partie de la réalité. Le terme transformation de la perception décrit ce processus inconscient. D'autres pertes d'informations se produisent pendant la formulation verbale. 2907933 23 Même si la perception personnelle de deux individus était identique, la représentation des connaissances varie d'une personne à une autre. Cette projection est appelée transformation de la perception. 5 L'ensemble du processus exposé fait apparaître une déformation de la réalité, et donc une représentation fausse de la fonctionnalité souhaitée du système, qui s'exprime dans des exigences incomplètes ou équivoques. [Rup04]. Le défi réside dans une description complète et univoque des exigences. Les informations 10 perdues lors de la formulation verbale doivent être reconstituées. Ce qui nécessite l'annulation de la transformation. La perception personnelle d'un individu réduit la réalité à différents aspects spécifiques. Interroger plusieurs personnes peut enrichir le contenu de l'information, car chacune perçoit 15 d'autres détails, et les déclarations des différentes personnes se complètent. Pour la transformation de la représentation, il n'existe pas d'autre possibilité de récupération des points de vue perdus, car les sensations humaines ne se laissent pas influencer sans problème. Les transformations de la représentation peuvent très bien être résolues en découvrant les informations manquantes. À conditions toutefois que l'analyste ait une 20 connaissance précise des modes de transformation qui sont à l'origine du problème. Si les informations perdues peuvent être identifiées par des effets verbaux, une interrogation ciblée sur ces informations comble les lacunes de l'exigence [Rup04]. L'amélioration itérative d'exigences de bas niveau par une interrogation ciblée des clients 25 constitue une méthode qui prend beaucoup de temps. Un mode opératoire efficace peut être obtenu en créant directement les exigences à un haut niveau de qualité. Les erreurs de formulation classiques peuvent être évitées en considérant la structure d'une phrase et en construisant pas à pas à une exigence optimale à l'aide de règles syntaxiques [Rup04]. 30 Dans une exigence concernant un système incorporé sont définies les fonctionnalités que le système doit présenter. Comme déjà décrit, les systèmes incorporés agissent avec leur environnement physique au moyen d'interfaces sous la forme de capteurs et d'activateurs. On utilisera ci-après pour ces interfaces les termes d'entrée et de sortie. Chaque entrée d'un système incorporé observe un élément donné ou une propriété de l'environnement physique. 35 La surface de commande d'une commande à distance, le bouton de porte et la vitesse instantanée sont des exemples d'éléments et de propriétés d'un véhicule. Une surface de 2907933 24 commande d'une commande à distance peut présenter un état pressé ou non pressé, un bouton de porte peut être en position haute ou basse, et la vitesse a toujours une valeur. Selon l'état d'un élément physique, une valeur correspondante est affectée à une entrée du système incorporé et est traitée par ce système. La commande des éléments physiques se 5 fait par l'affectation d'une valeur à une sortie du système incorporé, en conséquence de quoi l'élément physique est mis dans un état prédéterminé. Généralement, un utilisateur attend du système incorporé une réaction aux entrées qu'il actionne. Les figures 7 et 8 montrent des exigences sous la forme sous laquelle on les trouve dans la 10 pratique. Pour qu'une fonctionnalité de ce type soit exprimée dans une exigence, les informations ci-après doivent y être décrites. Quelles valeurs de sortie sont attendues à quelles sorties, pour quelles valeurs d'entrée à quelles entrées ? En conséquence, une affectation de valeurs aux 15 entrées est tout d'abord nécessaire en tant que pré-condition, et l'affectation de valeurs à des sorties données doit être décrite sous la forme d'une réaction attendue. Les exigences concernant les logiciels sont selon le document [HuOO] le plus souvent exprimées par des informations sous la forme suivante : Si une pré-condition se présente, alors 20 une réaction attendue doit se produire . Ceci est également vrai pour les spécifications des systèmes incorporés. Les exigences montrées dans cette section et venant de la pratique peuvent toutes deux être exprimées sous cette forme. Si un système reçoit à une entrée une valeur en tant que pré-condition, une valeur donnée doit être présente à une sortie en tant que réaction à cette pré-condition. Le système doit donc traiter la pré-condition de telle manière que la réaction attendue se produise en 25 tant que résultat. La figure 9 présente l'ensemble du processus, et une fonction de verrouillage centralisé à titre d'exemple. Si on appuie sur le bouton `déverrouillage' de la commande à distance d'un verrouillage centralisé, ce geste représente une entrée assortie d'une valeur. Les appareils de 30 commande des portes doivent alors déverrouiller les portes du véhicule, ce qui représente la fonction du système. Les portes déverrouillées du véhicule constituent les sorties, `déverrouillage' étant la valeur des sorties. Du fait de l'utilisation de plus en plus répandue des systèmes incorporés, et de la complexité 35 croissante de leurs logiciels en raison de la mise en réseau des différents composants logiciels, l'assurance de la qualité devient de plus en plus importante. Les exigences de qualité 2907933 25 doivent être définies et leur respect doit être assuré pour que soit garantie une qualité satisfaisante du logiciel. Une propriété de qualité d'un logiciel est la réalisation correcte du logiciel par rapport aux propriétés préalablement spécifiées. La définition des exigences au début du processus de développement des logiciels est suivie de la création d'une spécification 5 qui définit formellement les propriétés du logiciel à produire. Le contrôle du logiciel quant à ces propriétés formelles est appelé vérification. Si des défauts se sont produits pendant la création de la spécification à partir des exigences, la vérification ne garantit que le comportement correct du logiciel par rapport à la spécification. Mais l'aptitude du système à accomplir les tâches souhaitées par le client n'est pas encore testée avec cette méthode. Le contrôle de 10 l'efficacité du logiciel par rapport aux exigences est appelé validation [ThaOO]. Les méthodes d'assurance de la qualité sont classées de différentes manières dans la littérature, comme par exemple dans les documents [Ba198] et [Lig02]. La figure 10 donne un aperçu des méthodes présentées ci-après. Pour qualifier le terme tests , on peut utiliser la 15 subdivision de base usuelle en procédés visant à découvrir les défauts et procédés qui prouvent l'absence de défauts. Les tests sont une activité de recherche des défauts. La démonstration de leur absence ne fait pas partie des tests [Dij70]. Les méthodes de recherche des défauts sont classées en méthodes statiques et méthodes 20 dynamiques. Le critère à la base de cette subdivision est l'exécution du logiciel pour en découvrir les défauts. Les méthodes statiques observent le logiciel sans l'exécuter. Les activités d'inspection, de revue et de walkthrough [Ba198] peuvent être affectées à cette catégorie, et sont basées sur une vérification manuelle du logiciel par une équipe. Les méthodes dynamiques utilisent l'exécution du programme avec des données d'entrée 25 sélectionnées. Une autre catégorisation se fait sur la base du niveau d'observation [Pei]. Les tests black-box n'observent que les interfaces de l'objet du test. Une fois que le logiciel a fonctionné avec les données d'entrée sélectionnées, on évalue les données de sortie. L'exactitude des données 30 de sortie effectives est vérifiée en les comparant aux données de sortie attendues préalablement définies. Les tests white-box utilisent tous les composants de l'objet de test dont l'ensemble de la structure est dans ce cas mise à jour. Le flux de contrôle peut alors être suivi, et sa logique peut être comprise [ThaOO]. Cette méthode permet de trouver les défauts qui n'affectent pas les interfaces. 35 Les méthodes visant à découvrir les défauts peuvent par ailleurs être divisées en tests 2907933 26 fonctionnels et tests structurels. Les propriétés fonctionnelles d'un objet de test sont les fonctionnalités définies dans les exigences, dont l'exactitude est vérifiée sur la base de la spécification. Il s'agit souvent dans ce cas d'un test black-box, du fait qu'on ne s'intéresse pas à l'intérieur de l'objet de test, mais à son comportement apparent. Avec ce genre de 5 méthodes de test, la structure d'ensemble du programme de l'objet du test n'est souvent pas intégralement atteinte, du fait que certains éléments de programme ne sont exécutés qu'en cas de données d'entrée spéciales. Un test structurel vise à couvrir l'intégralité de la structure de l'objet de test. Tous les éléments de programme de l'objet de test doivent être exécutés car les éléments pouvant être atteints ne sont jamais superflus. Pour cette vérification, le code 10 programme doit être visible, de sorte que cette méthode est toujours un test white-box [Lig02]. Le défi consiste à sélectionner les données d'entrée de telle manière que tous les éléments de l'objet de test sont exécutés. Les éléments superflus sont alors également appelés code mort, et peuvent être supprimés. Mais du fait que le déroulement du test ne porte jamais que sur des échantillons, cette méthode de test n'apporte aucune preuve de l'inaccessibilité du 15 code. Une vérification complète par toutes les combinaisons possibles des données d'entrée est trop coûteuse dans la pratique. Parmi les méthodes visant à prouver l'absence de défauts figurent la preuve de théorèmes [Lov78, CLL97] et le model checking [CGPOO]. Le model checking vise à déterminer si un 20 modèle répond à la spécification formelle prescrite pour une exigence. On effectue à l'aide d'un algorithme une vérification automatique des propriétés demandées dans tous les états possibles du système. Pour la validation d'un système incorporé, on vérifie si le système présente toutes les 25 fonctionnalités qui ont été définies dans les exigences du client. Le regard se porte alors sur l'ensemble du système dans son environnement. Il s'agit d'observer comment le système se comporte en situation d'interactions données avec l'utilisateur. On s'intéresse alors uniquement à l'aptitude du système à remplir ses tâches, et non au comportement interne du système. Cette recherche est donc focalisée sur le test black-box. À l'heure actuelle, les tests 30 sont encore effectués en grande partie manuellement. La méthode de classification arborescente décrite ci-après constitue une méthode de création manuelle de cas de test en effectuant un test black-box. Il peut exister pour un objet de test un très grand nombre de valeurs et de combinaisons 35 d'entrée, qui constituent un arbre des entrées. L'objet de test ne peut pas être testé avec toutes les entrées possibles à un coût raisonnable. En conséquence, l'arbre des entrées est 2907933 27 décomposé selon des aspects déterminés, et ces partitions sont à leur tour subdivisées en classes d'équivalence. Les classes doivent être sélectionnées de telle manière que l'objet du test se comporte soit correctement soit sans défaillance pour toutes les valeurs d'entrée d'une classe [GG93]. Les classes d'équivalence peuvent encore être subdivisées selon d'autres 5 points de vue pour effectuer une sous-classification. On obtient ainsi un arbre de classification. Des séquences de test peuvent être créées sur la base de l'arbre des entrées [Lam06]. Pour ce faire, on combine de manière ciblée des classes dans chacune desquelles on sélectionne une valeur pour le test. 10 Après avoir qualifié le terme de tests nous présentons ci-dessous les composants d'un test qui sont nécessaires pour pouvoir exécuter un test black-box. L'objet à tester peut être par exemple un modèle, un code programme ou un prototype du système réel, et est appelé objet du test ou article à tester [Ba198]. Pour tester son comportement, on a besoin de données d'entrée avec lesquelles l'objet du test est exécuté. Les données d'entrée sont également 15 appelées stimuli. Un système incorporé ne se comporte pas comme un simple programme d'application qui reçoit une valeur à chaque entrée, qui est exécuté avec ces valeurs d'entrée, qui fournit une sortie à l'issue de l'exécution, et qui se termine. Différentes valeurs d'entrée sont souvent 20 affectées aux entrées selon une séquence temporelle. L'exécution de l'objet de test avec ces entrées fournit des sorties qui représentent le comportement de l'objet de test. Mais ces sorties ne donnent pas à elles seules une indication quant à la présence ou à l'absence de défaut. Les sorties attendues sont appelées données de référence, et doivent être définies avant l'exécution du test. L'ensemble des données d'entrée d'un test et les données de 25 référence qui y correspondent constituent un cas de test. Pour produire un test qui fournit un résultat concernant la bonne marche d'une fonctionnalité d'un système incorporé, il est nécessaire de fixer un objectif de test. Il faut alors définir quelle propriété de l'objet de test doit être vérifiée. On utilise comme base des documents qui 30 contiennent les propriétés voulues de l'article de test, par exemple les spécifications ou les exigences du client. En utilisant l'objectif défini, on sélectionne les données d'entrée qui seront affectées à l'objet de test selon une séquence temporelle. La détermination des données de référence est également basée sur l'objectif de test. La figure 11 montre le déroulement d'un test ainsi que ses différents composants. 35 Du fait qu'un système incorporé est développé pour être utilisé à l'intérieur d'un système 2907933 28 global avec lequel il interagit par l'intermédiaire d'interfaces, le système incorporé doit être testé dans l'environnement dans lequel il est destiné à être utilisé. Le test d'un système incorporé dans son environnement réel est souvent très coûteux, et peut être critique pour la sécurité. Pour vérifier par exemple la fonctionnalité d'un appareil de commande dans un 5 véhicule, il faut effectuer quelques tests sur route. De nombreux appareils de commande assument des fonctions sans lesquelles la sécurité d'utilisation du véhicule n'est pas assurée, de sorte que les tests sur route avec un appareil de commande non encore vérifié représentent un danger. 10 Par ailleurs, il se peut qu'un système incorporé soit développé avant que la fabrication du système global dans lequel il sera par la suite incorporé soit entièrement terminée. Les composants d'un système sont souvent développés parallèlement, pour limiter le temps de développement. Dans ce cas, un système incorporé ne peut pas être testé dans son environnement réel. 15 Comme déjà exposé ci-dessus, les systèmes incorporés doivent toutefois être testés dans les premières phases du développement. Plus les défauts intervenus dans les premières phases sont découverts tardivement, plus les modifications nécessaires à l'élimination des défauts se révèlent coûteuses, du fait q'elles s'étendent à plusieurs niveaux de développement. On a 20 donc besoin de méthodes qui permettent de reproduire l'environnement réel d'un système incorporé. Comme déjà décrit, le développement basé sur les modèles actuellement utilisé offre la possibilité de tester les systèmes par simulation aux premiers stades de développement. L'utilisation des possibilités de simulation aux différents niveaux de développement permet une vérification des résultats visés dans un accompagnement du 25 développement. Un modèle, un code programme et un prototype d'un système incorporé peuvent ainsi être testés en tant qu'objets de test dans un environnement entièrement simulé. L'environnement peut par exemple être reproduit en utilisant les modèles logiciels MATLAB /Si mu lin k . 30 La figure 12 montre l'objet de test qui est raccordé à une plateforme de test par l'intermédiaire d'interfaces. L'environnement simulé est réalisé sur la plateforme de test. Le test est exécuté avec un outil de test qui accède à la plateforme. Étant donné qu'un test est tout d'abord produit indépendamment de la plateforme de test utilisée, on effectue un mappage des désignations utilisées dans le test sur des variables et valeurs spécifique à la plateforme. Les 35 variables constituent les interfaces de l'objet de test. 2907933 29 Dans le cadre du développement basé sur des modèles, on développe dans la phase de projet, avec l'assistance d'outils logiciels, un modèle du système incorporé. Ce modèle peut être simulé. Du fait que le modèle du système incorporé ne peut être testé que dans le contexte du système global, un environnement de test est nécessaire. À cette fin, 5 l'environnement du système incorporé proprement dit est également reproduit sous la forme d'un modèle, qui sera ci-après appelé modèle d'environnement. Le modèle du système incorporé peut tout d'abord être testé indépendamment de son environnement, en l'exécutant avec des entrées et en analysant ensuite les sorties qui en résultent. À l'étape suivante, on effectue le test de l'interaction entre le modèle du système incorporé et le modèle 10 d'environnement. Le modèle d'environnement fournit alors les entrées pour le modèle et en reçoit les sorties, auxquelles il réagit. De là résultent à leur tour d'autres entrées. La plateforme de test doit offrir des possibilités pour modifier des paramètres du modèle et pour lire et caractériser les sorties de l'objet de test. Ces sorties sont exécutées par un test. Le test du modèle d'un système incorporé par simulation est appelé Model-in-the-loop (MIL). La 15 figure 13 présente ce scénario. Une fois le test Model-in-the-loop achevé avec succès, le code programme du système incorporé est généré automatiquement à partir du modèle ou développé manuellement. Ce code programme peut être testé de la même manière que le modèle. La plateforme de test et 20 le modèle d'environnement peuvent être repris. Simplement, l'objet de test est alors le code programme au lieu du modèle. Ce processus de test est appelé Software-in-the-loop (SIL) [BNO3]. Le code programme peut tout d'abord être compilé pour l'ordinateur de simulation sur lequel il est exécuté. On peut ensuite utiliser pour le test un émulateur du processeur cible pour lequel le code programme est compilé à cette étape. Le processus a pour but de vérifier 25 le comportement du code sur le processeur cible. Dans la suite du développement du système incorporé, on crée un prototype du système incorporé, sur lequel on charge le code programme déjà testé. Pour tester l'exécution correcte du logiciel incorporé sur le matériel réel, le prototype est testé en utilisant la simulation 30 Hardware-in-the-loop (HIL). Le prototype peut par exemple être un appareil de commande pour un véhicule équipé d'un logiciel fixe. Pour qu'il soit possible de tester ensemble le prototype et le modèle d'environnement, la plateforme de test doit disposer d'interfaces réelles auxquelles le prototype de l'appareil de commande peut être raccordé comme dans un système global réel. À ce stade il est possible d'effectuer une simulation en temps réel. À 35 cette fin, le modèle d'environnement est exécuté sur un simulateur temps réel au lieu d'un PC. La figure 14 présente la simulation Hardware-in-the-loop. 2907933 30 La technologie Hardware-in-the-loop s'est imposée pour les tests de prototypes d'appareils de commande au cours du développement. Une simulation HIL permet de reproduire jusqu'à 90 0/0 de tous les défauts intervenus en essai sur route [ONSO6]. 5 Dans le cadre d'un test black-box, on entend souvent par test la seule exécution de l'objet de test avec certaines données d'entrée. Mais les tests comprennent souvent plus que la simple exécution du test. Un test doit tout d'abord être développé. Ceci couvre la définition de l'objectif et la création des cas de test. Les données d'entrée et de référence doivent alors 10 être sélectionnées avec suffisamment de précision pour que l'exécution du test permette d'atteindre l'objectif de test avec ce cas de test. Pour créer un test exécutable, on commence souvent par définir les différentes étapes du test et par les décrire dans une spécification de test. La spécification de test constitue la base de l'implémentation de tests exécutables. 15 L'exécution du test est suivie de l'évaluation des résultats. À ce stade a lieu une comparaison entre les données de sortie et les données de référence, qui renseigne sur les défauts possibles. Les résultats obtenus avec les différents cas de test doivent être consignés dans une documentation. Ce processus constitue une tâche très importante, pour qu'un test puisse être exploité dans le long terme. La figure 15 montre le déroulement d'un processus de test. 20 On trouve dans la littérature de légères différences dans la répartition des différentes phases du processus. La norme BS 7925-2 [Istol] relative aux tests de composants logiciels divise un test en étapes de planification du test, spécification du test, exécution du test, évaluation du test et synthèse du test. 25 De plus en plus de possibilités d'automatisation sont développées pour faciliter, accélérer et rendre plus sûr le processus de test. À l'heure actuelle, l'exécution des tests se fait déjà de manière automatisée. Dans de nombreuses entreprises, les tests tournent automatiquement pendant le week-end ou pendant la nuit, pour les rendre plus rentables. Quelques recherches portent sur l'automatisation de l'évaluation [CFSWO6] et de la documentation. Les cas de test 30 peuvent également déjà être générés automatiquement [CTFO1, HuOO], ce qui représente une partie du développement de tests. Par ailleurs, il existe de nombreuses méthodes permettant de tester les fonctionnalités d'un système par rapport à des spécifications précédemment créées, par exemple le model checking [CGPOO]. 35 Nous avons définit ci-dessus les systèmes incorporés et décrit leur processus de développement. Une observation précise de la définition des exigences et de la phase de test 2907933 31 a été faite. Comme exposé, une exigence spécifie une pré-condition et une réaction attendue que le système doit produire à partir de la pré-condition. On retrouve les mêmes éléments dans un test. Comme décrit, le système à tester reçoit des données d'entrée. En réponse à ces données sont attendues des données de sortie déterminées qui sont appelées données 5 de référence. Une automatisation de la génération des tests est des plus souhaitables en raison de l'augmentation des coûts de développement et donc également du coût des tests. Il existe déjà de nombreuses méthodes avec lesquelles les fonctionnalités d'un système peuvent être 10 testées par rapport à des spécifications de comportement créées précédemment. Mais même si toutes les fonctions spécifiées d'un logiciel se comportent correctement, ceci ne prouve pas que le logiciel présente la fonctionnalité demandée. Pour que cette fonctionnalité correcte soit atteinte, toutes les exigences décrites précédemment pour le logiciel doivent être remplies. Il faut donc tester si le logiciel se comporte correctement par rapport aux exigences. Les 15 exigences sont tout d'abord, et la plupart du temps exclusivement, formulées sous la forme d'un texte, de sorte que ce texte constitue la base de la validation. Le défi consistant à générer automatiquement des tests à partir d'exigences exprimées textuellement doit être relevé par la présente invention. 20 Ci-après sont présentées et évaluées les approches existantes pour les questions connexes. Ci-après sont présentés les approches existantes qui ont différents aspects en commun avec la génération automatique de tests à partir d'exigences textuelles. 25 Le SOPHIST GROUP s'intéresse à l'analyse des exigences en langage naturel et aux méthodes orientées objet. Il met ses connaissances à la disposition des entreprises pour qu'elles puissent exécuter les processus de développement de leurs systèmes et/ou logiciels sans défaillance et le plus efficacement possible. Dans ce cadre, le SOPHIST GROUP assiste ses clients par des prestations de conseil, de formation et de développement d'outils. Deux 30 concepts du SOPHIST GROUP sont décrits ci-dessous. Comme déjà exposé, les exigences doivent être vérifiées quant à leur intégralité, et le cas échéant complétées par les informations de clients qui sont interrogés de manière ciblée. Le SOPHIST GROUP définit un ensemble de règles permettant une création itérative des 35 exigences. Elles permettent d'éviter les lacunes dans les informations. La recherche de suppositions implicites est une de ces règles [Rup04]. Mais du fait que l'amélioration itérative 5 2907933 32 ne constitue pas une méthode efficace de création des exigences, le SOPHIST GROUP a développé dans le document [Rup04] un concept à l'aide duquel il est possible de produire une description des exigences de haut niveau en 6 étapes. Ce concept est basé sur un patron d'exigence qui est défini comme suit selon le document [Rup04] : Un patron d'exigence est un schéma structurel qui définit la structure syntaxique d'une exigence individuelle . L'exemple ci-après illustre l'utilisation de ce patron. 10 Exemple: Un verrouillage centralisé doit présenter pour fonctionnalité que toutes les portes d'un véhicule peuvent être déverrouillées par l'utilisateur du véhicule. Des personnes différentes pourraient décrire cet état de fait différemment : Le verrouillage centralisé doit pouvoir déverrouiller toutes les portes du véhicule , ou Le véhicule a pour tâche de 15 déverrouiller toutes les portes . Ces informations pourraient susciter les questions suivantes : Le verrouillage centralisé effectue-t-il le déverrouillage spontanément ? Quand exécute-t-il cette tâche ? Ce qui montre que ces formulations sont incomplètes . La fonctionnalité souhaitée doit être formulée à l'aide d'unpatron d'exigence. On part alors toujours d'un système auquel doit s'appliquer l'exigence. Dans le cas présent, le verrouillage 20 centralisé représente le système. Etape 1 : L'information centrale d'une exigence réside dans la fonctionnalité qui définit le comportement du système. Cette dernière doit être tout d'abord identifiée, puis exprimée sous la forme d'un verbe. Le verbe déterminant de l'exemple est déverrouiller , qui sera ci-après 25 appelé mot processus. Etape 2 : À ce stade a lieu une sélection parmi les trois variantes. Soit le système exécute spontanément le processus défini au début, soit il met la fonctionnalité à la disposition de l'utilisateur. La dernière possibilité étant que le système exécute le processus en fonction d'un 30 tiers, de sorte qu'il n'assume lui-même qu'un rôle passif et attend un résultat extérieur. Ces trois options peuvent être résumées dans les termes suivants : • Activité spontanée du système • Interaction avec l'utilisateur • Exigence d'interface 35 5 2907933 33 Le coeur de l'exigence est à ce stade constitué du verrouillage centralisé dans le rôle du système, du mot processus déverrouillage et de l'utilisateur du véhicule qui déclenche le déverrouillage. Dans le présent exemple, il s'agit d'une interaction avec l'utilisateur, comme le montre la figure 16. Etape 3 : Pour exprimer l'obligation légale on utilise les trois mots doit , devrait et va . Le terme choisi définit si l'exigence est légalement obligatoire, fortement conseillée ou à venir. Dans le présent exemple, il convient de choisir le terme doit , pour exprimer l'obligation légale. 10 Etape 4 : Cette étape consiste à insérer les objets manquants et les compléments. On peut se poser la question de savoir ce que le verrouillage centralisé doit déverrouiller. La réponse est toutes les portes du véhicule, et constitue dans le présent exemple l'objet de l'exigence. On voit sur la figure 17 une représentation graphique de l'objet de l'exigence. Par rapport à la figure 16, la structure du patron en langue allemande a légèrement changé. Du fait que l'objet 15 et le complément de l'objet doivent (en allemand) être insérés avant le mot processus, le mot processus a été retiré du module central et placé à la fin du patron en tant qu'élément séparé. Ce qui donne en haut un élément vide. Ceci veut dire qu'après le système et le terme indiquant l'obligation légale peut se trouver un objet, suivi ensuite du mot processus. 20 Etape 5 : Les fonctionnalités d'un système sont souvent soumises à des conditions temporelles ou logistiques. L'ajout d'une condition aux limites a dans la langue allemande pour conséquence que la structure de la phrase doit être remaniée. L'exemple de la figure 18 montre un patron d'exigence complet dans lequel la condition lorsque le véhicule est verrouillé a été ajoutée. Il en résulte une phrase constituée différemment. 25 Etape 6 : L'exigence ainsi établie est soumise à une vérification. On utilise à cette fin les règles de l'approche analytique décrite ci-dessus, qui font encore apparaître des informations présentant des lacunes. 30 Les étapes qui aboutissent à un patron rempli donnent une structure de phrase dépourvue de sémantique. Chaque terme utilisé nécessite donc qu'une signification lui soit attribuée, ce qui crée la sémantique de l'exigence [Rup04]. La définition de la signification d'un terme doit se faire en expliquant le terme sous la forme d'un ensemble de phrases en langage naturel. Le but de ce type de définition sémantique est que différents rédacteurs choisissent les mêmes 35 termes pour le même état de fait, et que ces termes soient compris de la même façon par toutes les personnes concernées. 2907933 34 Cette sémantique est compréhensible pour l'homme, mais ne peut pas être traitée automatiquement, du fait que l'explication des termes n'est pas formelle et n'est donc pas lisible par machine. Il s'ensuit que la génération automatique d'un test à partir d'une exigence 5 créée de cette manière n'est pas possible. Dans le cadre du développement de la méthode RE-KIT l'Institut Fraunhofer des technologies logicielles expérimentales (Fraunhofer Institut Experimentelles Software Engineering IESE) présente dans le document [KBP01 ] une autre approche. L'attention se porte principalement 10 sur les exigences formulées de manière ambiguë. Dans le processus de développement d'un logiciel, les exigences textuelles sont mappées sur un modèle formel, pour que les développeurs puissent acquérir une compréhension univoque du produit à fabriquer et dériver de ce modèle les fonctions à développer. 15 S'il est ainsi possible de découvrir les incohérences et les lacunes, la pluralité des possibilités d'interprétation des exigences informelles entraîne des malentendus lors du processus de formalisation. La technique présentée dans le document [KBP01 ] se focalise sur la vérification des exigences informelles avant que ces dernières ne débouchent sur des spécifications formelles défectueuses. Des check-lists ainsi qu'une lecture basée sur des scénarios sont 20 utilisées pour éliminer les ambiguïtés existantes. Ces modes opératoires sont déjà connus et adoptés dans l'industrie, où ils conviennent particulièrement bien dans la pratique. Cette approche a pour objectif de découvrir les ambiguïtés et les lacunes dans les exigences informelles avant leur utilisation pour créer des exigences formelles. Il n'y a pas de 25 formalisation des expressions en langage naturel qui pourraient être utilisées pour la génération de tests. L'outil PROPEL présenté dans le document [SCFA03] propose un concept. Il s'agit de spécifier des propriétés de manière formelle à partir des exigences en langage naturel, étant 30 donné que, contrairement aux notions textuelles, les expressions formalisées laissent une moindre marge d'interprétation et réduisent donc considérablement les malentendus et les incohérences. Ceci se fait en ce qu'on offre aux développeurs la possibilité d'une formulation précise, moyennant en quoi ils bénéficient en même temps d'une représentation simple et compréhensible de l'exigence. 35 L'outil PROPEL propose des modèles de propriétés d'ordre général sous la forme de patrons, 2907933 35 qui doivent être remplis par l'utilisateur. Le nombre des évènements apparaissant dans une exigence, et la détermination du fait qu'un évènement doit se produire ou ne doit pas se produire sont des exemples de modèles de propriétés. On dispose de trois notations à l'aide desquelles sont représentées les exigences et les questions qui les concernent : le patron de 5 l'arbre des décisions, le langage naturel et un automate d'état fini. Le patron de l'arbre des décisions permet de choisir un modèle de propriétés qui définit la structure de base de l'exigence. Comme deuxième notation, l'utilisation dispose d'un ensemble partiel de langage naturel. Parallèlement, l'exigence est présentée sous la forme d'un automate d'état fini. Les deux dernières représentations offrent à l'utilisateur des fonctions identiques de spécification 10 de l'exigence. Elles peuvent être transformées l'une en l'autre. Avec l'automate fini, l'exigence est formulée de manière formelle et précise, l'approche en langage naturel offrant à l'utilisateur une compréhension facile. Le concept de l'outil PROPEL s'adresse aux développeurs en tant que groupe cible pour la 15 formulation d'exigences, qui sont familiarisés avec les automates d'état finis. La méthode qui consiste à formuler les exigences sous forme de langage naturel n'a pas été pensée pour constituer seule cet outil. La représentation de l'exigence en langage naturel offre certes à l'utilisateur un point de vue qu'il peut comprendre, mais une interprétation sémantique précise ne peut venir que de l'automate fini. La considération exclusive du langage naturel peut 20 conduire à des malentendus. L'utilisation d'une notation formelle univoque, comme dans l'approche d'une notation sous la forme d'automates finis, offre la possibilité de produire des exigences analysables par l'ordinateur. Mais peu de gens dominent les notations formelles dans le domaine de la création d'exigences, de sorte que la description formelle des exigences ne constitue pas une solution souhaitable. 25 L'outil PROPEL assiste la formulation d'exigences précises formelles, mais ne propose de concept permettant de dériver des tests de ces exigences. En conséquence, l'outil PROPEL ne suffit pas pour générer des tests automatiquement à partir d'exigences formulées en langage naturel. 30 Par ailleurs, il n'offre pas la possibilité de spécifier les conditions temporelles dans les exigences. Étant donné que la correction du comportement d'un système incorporé ne dépend pas uniquement de la correction logique, mais que le temps dans lequel une fonction est exécutée joue un rôle essentiel, les aspects temporels doivent pouvoir être formulés dans 35 les exigences fixées à un système incorporé. Les automates finis, tels qu'ils sont utilisés par l'outil PROPEL, n'assistent en rien le traitement des conditions temporelles. Il faudrait pour ce 2907933 36 faire utiliser une forme d'automate fini étendue aux conditions temporelles. Le document [FMROO] expose une méthode avec laquelle sont produites des expressions formelles et précises en langage naturel. La notation utilisée est orientée vers un anglais 5 structuré, de sorte qu'elle est compréhensible pour l'utilisateur. Pour la construction d'une phrase, on dispose pour sélection de listes d'états donnés, ainsi que d'un ensemble de fragments en langage naturel. La structure de base d'une phrase spécifiée, dont les éléments et la syntaxe sont définis dans une grammaire, est très simple. Par la traduction d'une telle phrase en une expression formelle de la logique temporelle CCTL, on lui affecte une 10 sémantique. Définir une syntaxe par une grammaire a toutefois pour inconvénient que des extensions par l'ajout de nouveaux fragments de langue aboutissent à une modification des plusieurs éléments grammaticaux. De ce fait, le mappage sur la logique temporelle doit être actualisé 15 pour toutes les parties modifiées. Ce qui rend l'extension complexe. L'approche décrite dans le document [FMROO] se focalise sur la formalisation d'expressions en langage naturel, pour les utiliser pour décrire formellement des propriétés, pour pouvoir les utiliser pour le model checking. L'approche ne propose aucun concept permettant la 20 génération de tests sur la base des expressions formalisées. Il convient par ailleurs d'évoquer le Requirements Interchange Format (RIF) [WHHO5], un format d'échange pour les exigences, indépendant de l'outil. De plus en plus d'entreprises gèrent les exigences avec l'assistance de différents programmes développés à cette fin dans 25 le cadre de la gestion des exigences (requirements management). La gestion des exigences comprend des mesures qui assistent l'analyse des exigences et l'utilisation ultérieure des exigences. La gestion des exigences est également utilisée dans le domaine automobile. Mais la 30 collaboration largement basée sur la division du travail entre les constructeurs et les sous- traitants a fait apparaître que la gestion des exigences ne doit pas s'arrêter aux frontières de l'entreprise. L'échange des exigences entre constructeurs et sous-traitants nécessite un format commun pour les exigences. En conséquence, les constructeurs automobiles et leurs sous-traitants ont défini en commun le Requirements Interchange Format, pour combler les 35 failles de la gestion des exigences entre les différentes entreprises. La spécification du RIF prévoit que toute entreprise puisse continuer à utiliser le programme de gestion des 2907933 37 exigences précédemment utilisé et bien maîtrisé, et que les exigences ainsi créées soient converties au format d'échange commun RIF. À cette fin, un programme de gestion des exigences doit être étendu pour présenter une fonctionnalité import et export. 5 Une observation minutieuse du RIF a fait apparaître qu'une utilisation exclusive de ce format pour la gestion des exigences n'a pas de sens, du fait que le contenu des exigences y est représenté en types de données simples (int, string...), énumérations et types de données complexes, les types de données complexe étant spécifiques à l'application. Il s'ensuit que chaque application nécessite un format dans lequel les types de données complexes sont définis pour que ces 10 données puissent également être traitées. Le format RIF n'effectue aucune formalisation de la syntaxe de la langue, mais convertit des documents entiers à un autre format. Il n'existe donc aucune possibilité d'affecter une sémantique à chaque élément linguistique, de sorte que le format RIF ne peut pas être utilisé pour la formalisation d'exigences en langage naturel à partir desquelles des tests doivent être générés. Le format RIF a été développé avec pour objectif d'offrir une 15 possibilité d'échange des exigences qui existent dans des formats différents. Ce format n'est pas conçu pour la formalisation d'exigences en langage naturel pour la génération automatique de tests. Parallèlement au défi que représente la description univoque des exigences, la production de 20 tous les cas de test pertinents dans le cadre de la génération automatique de tests constitue une tâche importante. Différents concepts visant à générer automatiquement les cas de texte figurent par exemple dans les documents [CFT01 ] et [HuOO]. Le document [HuOO] décrit une méthode de représentation des exigences en un logiciel par 25 une logique multivaluée. Une logique multivaluée permet qu'une variable puisse ne pas adopter que les valeurs true ou false ( vrai ou faux ) mais n'importe quel nombre de valeurs. Supposons par exemple que X1 est l'éclairage intérieur d'un véhicule, qui peut présenter trois états 0, 1 et 2 : l'éclairage intérieur peut être éteint (0), atténué (1) ou pleinement allumé (2). S'il s'agit de décrire une exigence selon laquelle l'éclairage intérieur 30 doit être atténué, ceci peut être exprimé par la formule suivante : Y = X1(1). À partir de telles expressions multivaluées qui émanent des exigences, il est possible de générer des cas de tests pour des circuits numériques multivalués en utilisant les algorithmes de génération de tests existants. 35 Le document [CTF01] présente la méthode du test statistique fonctionnel qui utilise la théorie des probabilités pour la génération automatique de cas de test. On utilise dans ce cas 2907933 38 des diagrammes d'état UML pour représenter le comportement dynamique du système à tester. De ces diagrammes d'état sont dérivés des cas de test. Comme critère de test s'applique la couverture de chaque transition d'état. Ce concept n'utilise pas de langage naturel comme base. 5 Ces deux approches concernent la génération de cas de test, ce qui suppose toutefois qu'un test existe déjà. Les cas de test sont composés de données d'entrée sélectionnées et des données de sortie qui sont attendues après l'exécution d'un système avec les données d'entrée sélectionnées. Il s'agit donc uniquement des paramètres avec lesquels le test est 10 effectué. L'implémentation du test, qui effectue les différentes étapes du test, comprend par exemple l'affectation de valeurs aux variables de l'objet de test ou la lecture de valeurs. Un test exécutable doit exister pour qu'un test puisse être effectué avec différents cas de test. Les approches présentées à ce stade n'offrent aucun concept permettant la génération automatique de tests. 15 L'Institut Fraunhofer pour l'architecture des ordinateurs et les techniques de logiciels (Fraunhofer Institut Rechnerarchitektur und Softwaretechnik - FIRST) décrit dans les documents [FriO4, FS05, FP05] un mode opératoire permettant de dériver des cas de test de cas d'application. L'approche présentée est basée sur une méthode interactive d'élaboration 20 de descriptions de cas d'application, à partir desquelles des cas de test peuvent être générés automatiquement. Les exigences textuelles peuvent être chargées dans une interface utilisateur, liées, étendues en éléments du flux de contrôle et reliées à des informations émanant du projet [FP05]. Les exigences sont ainsi formalisées de manière interactive. 25 Dans cette approche, les descriptions textuelles des exigences ne suffisent pas pour générer des tests automatiquement à partir d'elles. Il faut reprendre manuellement ou créer les informations du projet. Par ailleurs, il manque un concept permettant le traitement des conditions temporelles, qui est nécessaire pour la formulation des exigences fixées à un système incorporé. Cette approche n'offre, pas plus que les approches précédentes, aucune 30 possibilité pour générer des tests exécutables. Il ne s'agit que de la production de cas de test. Dans cette section ont été présentées des approches qui s'intéressent à la formalisation des expressions en langage naturel et à la description d'exigences textuelles qui sont destinées à être traitées automatiquement. On a également observé des concepts permettant la 35 génération automatique de cas de test à partir d'informations qui existent sous différentes formes. Aucune de ces approches ne prévoit une génération automatique de tests sur la base 2907933 d'une exigence en langage naturel. Les approches existantes ne fonctionnent pas entièrement avec le langage naturel comme base pour la production d'exigences sous une forme compréhensible, ou bien les exigences 5 créées ne sont pas lisibles par machine et ne peuvent donc pas être traitées pour la génération automatique de tests. Dans quelques approches, il manque un concept permettant le traitement des conditions temporelles. Pour automatiser la génération de tests sur la base des exigences et ainsi réduire le coût du processus de test, la présente invention décrit un nouveau concept qui contient une formalisation des exigences en langage naturel et présente 10 une méthode de génération des étapes de test à partir de ces exigences, pour produire à partir d'elles des tests exécutables. Dans la première étape, les exigences sont toujours décrites sous la forme d'un texte informel. Pour dériver automatiquement des tests à partir d'une telle exigence textuelle, il est 15 nécessaire de pouvoir l'interpréter clairement et par machine. Ceci nécessite des informations sur la signification de chacun des différents termes présents dans un document d'exigence. Mais produire un système qui puisse comprendre tous les termes et toutes les combinaisons de termes du langage naturel n'est pas réalisable dans la pratique. Une prise en compte de tous les mots existants dépasse toutes les possibilités, car le nombre de termes est beaucoup 20 trop élevé, et le langage naturel autorise la création de nouveaux mots. Par ailleurs, le langage naturel porte en lui le risque de malentendus ou d'ambiguïtés, de sorte qu'un mappage univoque ne peut pas être réalisé. Il est en conséquence nécessaire de définir une syntaxe univoque et une sémantique univoque qui peuvent être traitées par ordinateur. 25 La présente contribution part d'un ensemble partiel préalablement défini d'expressions du langage naturel, dans lequel à chaque expression est affectée une sémantique, ce qui rend possible un traitement automatisé. Pour la formulation de l'exigence, il existe un vocabulaire et une structure de phrase. La personne créant les exigences doit ainsi pouvoir exprimer toutes les exigences qu'elle souhaite. 30 La figure 1 donne un aperçu du concept global. La présente invention décrit un méta-modèle qui définit une syntaxe univoque pour une exigence. Ce méta-modèle permet de créer des exigences formelles que l'utilisateur reçoit présentées sous la forme du langage naturel. Pour la création de l'exigence, l'utilisateur reçoit un vocabulaire qui contient des fragments de texte 35 de base tels que si...donc , et , ou ... D'autres fragments de texte qui représentent les 39 2907933 instances de certains éléments du méta-modèle d'exigence peuvent être définis par l'utilisateur. Avant qu'un test soit généré à partir d'une exigence formelle, l'utilisateur reçoit une description 5 textuelle du déroulement du test. Cette étape montre à l'utilisateur ce qui va être vérifié par le test généré à partir de son exigence. Cette description du déroulement du test est appelée spécification de test. Un autre méta-modèle en décrit la syntaxe. Par une transformation de modèle, on effectue une conversion de l'exigence formelle en une spécification de test formelle qui est présentée à l'utilisateur sous forme textuelle et donc compréhensible. La transformation 10 de modèle consiste à appliquer des règles de mappage. Elles contiennent des informations sémantiques qui définissent quels fragments de texte d'une exigence doivent être mappés sur des fragments de texte donnés de la spécification de test. La génération d'un programme de test exécutable à partir de la spécification de test formelle nécessite des informations concernant la plateforme de test et ses variables et valeurs spécifiques. 15 Pour que l'utilisateur puisse décrire son exigence en des termes compréhensibles intuitivement, et également comprendre les étapes de test de la spécification de test, les interfaces de l'objet de test ne sont pas décrites en utilisant leurs noms de variables, mais par des objets d'interface définis par l'utilisateur. Les valeurs qui sont affectées aux interfaces de 20 l'objet de test peuvent être décrites par l'utilisateur par des états qu'il définit lui-même. La figure 19 montre la relation entre objet d'interface, valeur et état. L'utilisateur peut par exemple définir l'objet d'interface le bouton `déverrouillage' de la commande à distance et l'utiliser dans son exigence. Cet objet d'interface définit la variable button_remote_unlock de l'objet de test. Pour décrire que le bouton `déverrouillage` de la commande à distance 25 doit être pressé, l'utilisateur peut définir l'état pressé et l'affecter à l'objet d'interface. L'état pressé décrit la valeur 1 . Le mappage des objets d'interface sur des variables et des états sur des valeurs permet ainsi de décrire par une expression en langage naturel l'affectation d'une valeur à une variable. Le texte le bouton `déverrouillage' de la commande à distance est pressé représente par exemple l'affectation à la variable de 30 button_remote_unlock = 1 . D'une part les objets d'interface et les états définis en langage naturel sont compréhensibles pour l'utilisateur, et d'autre part les variables et les valeurs peuvent éventuellement ne pas être connues de l'utilisateur au moment de la création de l'exigence. 35 Ci-après est décrit plus en détail le méta-modèle d'exigence. Puis vient une présentation du méta-modèle de spécification de test. Ensuite est présenté le concept de transformation de 2907933 41 modèle, puis une description du mode opératoire du mappage de la spécification de test sur un programme de test exécutable. Les modèles sont utilisés en informatique pour réduire les états de fait complexes aux 5 éléments essentiels qui sont pertinents pour le but concerné. On dispose ainsi d'une vision abstraite d'informations complètes, ce qui permet de détecter facilement les aspects pertinents. Un méta-modèle définit quels éléments peuvent être présents dans un modèle et quels éléments doivent être présents, ainsi que les relations qui existent entre les éléments. Pour décrire une phrase, on peut par exemple définir dans le méta-modèle que le sujet et le 10 prédicat doivent être présents dans chaque phrase, les objets pouvant exister. Un modèle qui est constitué d'instances des éléments du méta-modèle représente une instance du méta-modèle. Le méta-modèle décrit dans le cadre de la présente invention définit la syntaxe d'un ensemble 15 partiel de langage naturel. Il décrit le vocabulaire qui peut être utilisé pour la description des exigences. Par le choix et la combinaison de termes issus de ce vocabulaire, on crée un modèle d'une exigence. Ce modèle représente une instance du méta-modèle. L'utilisation d'un vocabulaire pour la création d'une phrase consiste à sélectionner des mots et 20 à les assembler en une phrase. Certains mots ne sont utilisés que combinés à d'autres. En conséquence, plusieurs mots sont regroupés en expressions figées, qui sont modélisées en tant qu'objets atomiques. Les mots qui peuvent être utilisés isolément forment chacun un objet atomique. Dans la présente invention, ces objets seront également appelés constructions textuelles ou modules de texte. 25 Le méta-modèle d'exigence, et donc le vocabulaire, sont directement adaptés aux informations nécessaires pour générer le test. Pour empêcher l'utilisateur de définir des exigences incohérentes ou incomplètes, le méta-modèle prescrit une structure fixe de l'exigence. 30 Le méta-modèle d'exigence a été modélisé en utilisant un diagramme des classes UML. Cette notation est décrite dans le document [Obj05]. Les modules de texte sont représentés par des classes. Les associations entre les classes définissent les correspondances des modules de texte les uns par rapport aux autres, pour garantir la création d'une phrase syntaxiquement 35 correcte. Les classes abstraites ne représentent pas des modules de texte mais définissent des types de modules de texte déterminés. De ces derniers, les modules de texte héritent les 2907933 42 propriétés et les associations. L'utilisation de classes abstraites sert à structurer le méta-modèle. Les modules de texte peuvent être groupés sur la base d'associations et de propriétés communes et modélisés sous forme de classes qui héritent toutes de la même classe abstraite. Les opérateurs binaires tels que ET et OU constituent par exemple un 5 groupe de mots. Ils peuvent apparaître à la même place dans une exigence, et présentent les associations à la même classe. Ci-après sont décrits les différents éléments du méta-modèle qui définissent ensemble la syntaxe de la description d'une exigence. La figure 20 montre un extrait du méta-modèle et 10 les principaux éléments. On a déjà dit que les exigences sont le plus souvent exprimées sous la forme : Si une pré-condition se présente, alors une réaction attendue doit se produire . Les expressions telles que si...alors déterminent la structure globale d'une exigence. Pour pouvoir spécifier une telle expression de 15 base il existe l'élément abstrait BaseExpression qu'on peut voir sur la figure 20. Il représente la construction de l'exigence. L'élément Iff qui remplace l'expression textuelle précisément si... alors fournit une instanciation concrète de la BaseExpression . L'élément Implies représente une autre instanciation, par laquelle est produite une construction Si...alors . Les deux éléments ont des significations différentes pour un texte. Si...alors signifie que si la pré- 20 condition se présente, alors la réaction attendue doit se produire, faute de quoi le test échoue. L'utilisation de l'expression Précisément si...alors donne deux cas à tester : si la pré-condition se présente, alors la réaction attendue doit se produire et si la pré-condition ne se présente pas, alors la réaction attendue ne doit pas se produire. Si une des deux règles n'est pas respectée, le test échoue. 25 Une BaseExpression comprend deux éléments du type BaseExpressionElement, dont le premier représente la pré-condition et le deuxième la réaction attendue. Un BaseExpressionElement est dans le cas le plus simple un InterfaceElement . Il constitue l'objet d'interface qui représente les entrées et les sorties du système à tester. À un objet 30 d'interface doit être affecté un état, pour que des valeurs puissent êtreaffectées aux variables du système. La figure 19 présente la relation entre l'objet d'interface, la variable, la valeur et l'état. Le bouton `déverrouillage' de la commande à distance décrit par exemple un objet d'interface, dont l'état peut être pressé ou non pressé. 35 L'élément ValueElement modélise cet état. Au moment de la description de l'exigence, il se peut que la valeur exacte qui doit décrire l'état ne soit pas vraiment fixée, mais qu'il faille 2907933 43 limiter la valeur à une certaine plage. On dispose pour ce faire de l'élément abstrait ValueCondition . Il présente quatre différents éléments en tant qu'instanciations concrètes. D'une part, ce peut être un élément AtMostforValue , avec lequel est définie une limite supérieure pour la valeur. On peut par ailleurs utiliser un élément AtLeastforValue qui 5 spécifie une limite inférieure. L'élément Within permet de définir un intervalle et l'élément ExactlyValue détermine avec précision une valeur concrète. La figure 21 présente une instance concrète du méta-modèle et une exigence qui a été produite en utilisant les éléments présentés. Les lignes représentent les associations des 10 éléments. Les flèches en pointillés relient chacune un élément de l'instance du méta-modèle au texte, à titre d'exemple, comme il apparaît du point de vue d'un utilisateur. Pour représenter à partir d'une instance du méta-modèle une vue lisible pour l'utilisateur, un mappage sur les expressions en langage naturel est nécessaire. Ce mappage sera montré ultérieurement. 15 Les éléments définis jusqu'alors permettent de formuler les exigences en mode passif. La fonctionnalité d'un système dépend de l'entrée, mais non de la personne qui déclenche l'entrée. En conséquence, on n'a pas besoin d'une construction textuelle décrivant une personne ou un système qui peut être à l'origine de l'entrée. 20 Comme on le voit dans l'exemple sur la figure 21, l'objet d'interface et l'état sont toujours associés l'un à l'autre par le mot est . Un client pourrait exprimer l'assertion alors le véhicule est déverrouillé également sous la forme alors, le véhicule doit être déverrouillé , ou souhaiter utiliser les termes peut , devrait ou va être à la place de doit être . Mais 25 seules doivent être vérifiées par des tests les fonctionnalités qui doivent fournir les résultats déterminés. Il n'y a pas de sens à consacrer son énergie au développement de tests avec lesquels sont vérifiées des fonctions qui peuvent aboutir à un résultat, mais pour lesquelles il n'y a pas de problème si le résultat ne correspond pas à celui attendu. 30 Si les constructions textuelles telles que Si...alors , au plus , au moins ... appartiennent au vocabulaire général, les constructions textuelles permettant la description des objets d'interface (InterfaceElement) et des états (ValueElement) dépendent du système. En conséquence, l'utilisateur doit pouvoir définir lui-même les constructions textuelles pour les objets d'interface et les états, ce pour quoi le vocabulaire est étendu. 35 Pour pouvoir offrir à l'utilisateur différentes possibilités d'expression, il doit être possible 2907933 44 d'affecter des synonymes à l'InterfaceElement. Dans une exigence, les expressions déverrouiller toutes les portes et déverrouiller le véhicule peuvent par exemple décrire le même état de fait. À chaque InterfaceElement peut être affecté un nombre indifférent de synonymes, qui sont modélisés en tant qu'attributs de l'élément InterfaceElement. Des 5 synonymes peuvent également être définis pour les états, présents sous la forme d'éléments ValueElement. La figure 22 en montre un exemple. De nombreuses exigences ne peuvent pas être décrites avec les éléments présentés ci-dessus. Il se peut que des valeurs déterminées soient affectées à plusieurs entrées, et que 10 plusieurs sorties y réagissent. Un opérateur AND est donc nécessaire. Par ailleurs, la pré-condition et la réaction attendue peuvent également être constituées d'instructions liées avec un opérateur OR. La négation d'une affirmation ne peut pas non plus être décrite avec l'extrait de méta-modèle présenté jusqu'alors. Ce qui montre la nécessité d'avoir des opérateurs dans le méta-modèle. La figure 23 présente une exigence comportant une simple opération AND 15 dans la pré-condition. Ce qui veut dire que deux éléments InterfaceElement sont affectés à l'opérateur AND. On a donc besoin dans le méta-modèle d'un opérateur qui se trouve entre une BaseExpression et un InterfaceElement. Mais il doit par ailleurs être possible de formuler une exigence sans 20 l'opérateur. Ainsi une BaseExpression peut être suivie d'un opérateur, mais aussi directement d'un InterfaceElement, comme le montre la figure 24. Pour pouvoir lier plus de deux éléments et combiner les opérateurs AND et OR dans une exigence, il doit être possible d'emboîter les opérateurs (figure 25). En résumé, on peut citer 25 trois critères pour l'extension du méta-modèle par des opérateurs : 1. Un opérateur doit être inséré dans l'exigence avant l'InterfaceElement, étant donné que les éléments de type InterfaceElement doivent être affectés à l'opérateur en tant qu'enfants. 30 2. Par ailleurs, la formulation des exigences sans opérateur doit être possible. 3. Il doit être possible de lier plusieurs aspects par un emboîtement des opérateurs. Ceci amène à une modélisation des opérateurs à l'aide du modèle de projet compositum [GHJVO4]. La figure 26 montre un extrait étendu du méta-modèle d'exigence. On y trouve 35 l'élément abstrait BinaryOperator , qui hérite de l'élément BaseExpressionElement. En conséquence il peut être un enfant d'une BaseExpression. Les instanciations concrètes telles 35 2907933 que les éléments AND, OR ou XOR héritent à leur tour de cet élément. Le BinaryOperator a aux moins deux enfants qui doivent être liés par lui. Ces enfants sont de type BaseExpressionElement, de sorte que des éléments concrets de type InterfaceElement ou d'autres opérateurs sont possibles en tant qu'enfants. Un BinaryOperator a donc en tant 5 qu'enfants deux éléments de type BaseExpressionElement, lui-même étant un BaseExpressionElement. Le Unary-Operator est modélisé de manière similaire. Il n'a qu'un enfant et est par exemple utilisé dans le NOT-Operator pour la négation d'une affirmation. La modélisation des opérateurs permet de produire des instances telles que celles des figures 10 23, 24 et 25. On obtient une structure arborescente, en conséquence de quoi un emboîtement des opérateurs rend les opérations univoques. Dans le langage naturel, l'utilisation de plusieurs opérateurs dans une phrase peut induire des ambiguïtés. L'exigence Le contact est mis et l'éclairage intérieur du véhicule est allumé ou l'éclairage intérieur est éteint pourrait contenir deux affirmations, que font apparaître des mises entre parenthèses 15 différentes dans la phrase : (Le contact est mis et l'éclairage du véhicule est allumé) ou l'éclairage intérieur est éteint. ou Le contact est mis et (l'éclairage intérieur du véhicule est allumé ou l'éclairage intérieur est éteint.) . Une telle structure est définie par la structure arborescente. Pour présenter à l'utilisateur sous une forme univoque une exigence comportant des opérateurs, il est possible d'utiliser des moyens tels que la mise entre 20 parenthèses ou le marquage de parties de phrase. L'utilisation de plusieurs opérateurs ne crée ainsi pas d'ambiguïté. Les informations que peut contenir une exigence grâce aux éléments définis ci-dessus ne suffisent toutefois pas pour le développement du logiciel d'un système incorporé. L'affectation 25 des entrées et des sorties peut être formulée mais les questions de savoir quand et combien de temps une valeur doit être appliquée à une de ces interfaces restent sans réponse. Il existe souvent des détails qui sont attendus, mais qui ne sont pas communiqués. Des exigences spécifiées de manière incomplète aboutissent à des systèmes dont les fonctionnalités ne correspondent pas aux attentes. 30 Exemple: Si le bouton `déverrouillage' est pressé alors le véhicule est déverrouillé. Quand le bouton est-il actionné ? Combien de temps doit-il être pressé pour que le véhicule soit enfin déverrouillé ? Combien de temps le déverrouillage dure-t-il ? Ce problème amène à la nécessité d'ajouter au méta-modèle des éléments permettant de 2907933 46 spécifier des conditions temporelles. Pour modéliser l'instant de l'affection d'une interface existe l'élément PointOfTime qui est affecté à l'InterfaceElement. Car tout InterfaceElement présente une association à une ValueCondition qui est liée à un ValueElement . C'est pourquoi une variable d'une interface est représentée par une affectation de valeur déterminée. Cet état 5 d'affectation peut nécessiter la détermination d'un instant et d'une durée si on décrit des exigences pour lesquelles les conditions temporelles sont pertinentes. En conséquence, I'InterfaceElement présente par ailleurs une association à un élément LengthOfTime pour la description de la durée. 10 Les éléments PointOfTime et LengthOfTime sont modélisés en tant qu'éléments optionnels, car il peut exister des exigences dans lesquelles une définition des conditions temporelles n'a pas de sens. Par ailleurs, il existe quelques scénarios dans lesquels les indications temporelles ne sont pas spécifiées avec précision, mais ne doivent être indiquées que par une limite supérieure ou inférieure. 15 Exemple : Si le bouton `déverrouillage' de la commande à distance est pressé après 0 seconde pendant au moins 4 secondes alors le véhicule est déverrouillé après au plus 6 secondes pendant au moins 240 secondes . 20 Ceci montre que sont nécessaire différents éléments d'instant et de durée, qui sont montrés dans le méta-modèle de la figure 27. Pour décrire l'instant on a modélisé quatre éléments, qui héritent du PointOfTime : • ExactlyTime 25 • NotLaterThan • Soonest • BetweenTime L'élément ExactlyTime sert à traiter le cas dans lequel une indication temporelle précise est 30 activée. Pour la description d'une limite supérieure existe l'élément NoLaterThan à l'aide duquel la valeur spécifiée est affectée à une variable d'une interface avant l'instant défini. L'élément Soonest définit que la valeur ne sera pas affectée à la variable avant l'instant. L'élément BetweenTime est utilisé pour définir en même temps une limite inférieure et une limite supérieure. Tous ces éléments présentent des associations à l'élément Time qui 2907933 47 contient la valeur de temps concrète sur laquelle sont basées les conditions temporelles. La figure 28 présente la relation des éléments au texte de l'exigence. De la même manière, il existe quatre éléments permettant la description d'indications de 5 durée, qui héritent de l'élément LengthOfTime : • ExactlyDuration • AtMost • AtLeast • BetweenDuration 10 L'élément ExactlyDuration sert pour la définition d'une durée d'une longueur précise. AtMost et AtLeast permettent de déterminer la limite supérieure et la limite inférieure des indications temporelles. L'élément BetweenDuration sert à la définition d'un intervalle dans lequel la durée doit se trouver. Ces éléments présentés possèdent des éléments Duration qui contiennent les indications de durée. 15 La définition formelle de la sémantique de tous les éléments permettant la description des conditions temporelles se fait sous la forme d'un mappage sur la logique temporelle RTCTL. À ce stade il convient d'observer les aspects qui découlent de l'utilisation des indications temporelles : 20 1. Instant de référence de la réaction attendue 2. Dépendances temporelles entre les conditions 3. L'élément Soonest dans la réaction attendue Toutes les indications temporelles dans la pré-condition se réfèrent à un point zéro commun 25 pour que des processus parallèles puissent également être décrits. Des séquences de conditions peuvent être spécifiées à l'aide de la prise en compte de différentes indications d'instant et de durée. Si une pré-condition est remplie, on peut s'attendre à ce que la réaction suive. On pourrait donc prendre comme point zéro pour une indication temporelle définie dans la réaction attendue le premier instant où toutes les pré-conditions sont remplies. Une pré- 30 condition est remplie et/ou close si l'objet d'interface a été informé de l'état et si l'état persiste pendant la durée spécifiée. Sur la figure 29, la réaction attendue se produit une unité de temps après la clôture de toutes les pré-conditions. Ce déroulement peut être spécifié dans une exigence, en ce que la réaction présente l'indication d'instant après exactement une unité de temps, et l'instant de référence pour cette réaction attendue n'est pas le point zéro 35 d'observation de l'exigence, mais la clôture de toutes les pré-conditions. 2907933 48 Mais cette hypothèse ne couvre pas le cas dans lequel un trajet de signal en tant qu'entrée demande un autre trajet de signal en tant que sortie, sans que les deux signaux se succèdent dans le temps. Ce cas est illustré sur la figure 30. Pour traiter ce cas, on peut ajouter comme 5 extension dans le méta-modèle un autre élément qui définit que les indications temporelles dans la partie exigence de la réaction attendue se réfèrent au même point zéro que celui de la pré-condition. Pour une vue d'ensemble, la définition des points de référence pour les indications 10 temporelles se résume comme suit : • Dans la pré-condition, tous les instants se réfèrent au point zéro de l'exigence globale. • Pour la réaction attendue, il est entendu que le premier instant où toutes les pré- conditions sont remplies représente le point de référence pour tous les instants. • Comme extension du méta-modèle peut être ajouté un élément qui offre la possibilité de 15 rapporter également l'instant de la réaction attendue au point zéro de l'exigence globale. Mais cette définition des points de référence ne permet pas d'exprimer le fait que les conditions présentes à l'intérieur de la pré-condition sont dépendantes les unes des autres. Les éléments NotLaterThan, Soonest, AtLeast,... ne spécifient aucune indication temporelle 20 précise, de sorte que la fin d'une condition ne peut pas être déterminée préalablement. Si une condition B doit entrer en vigueur après clôture de la condition A, ceci ne peut être réalisé par une simple indication temporelle concernant la condition B, du fait que la fin de la condition A ne peut pas être déterminée avec précision par des indication temporelles non précisément définies. Il n'est pas non plus possible de décrire les dépendances possibles entre les 25 conditions de la réaction attendue. Il faut pour ce faire un nouvel élément, qui est présenté ci-dessous. Exemple : Si le véhicule est verrouillé alors le véhicule est déverrouillé pour au moins 240 secondes 30 3 secondes après que le bouton `déverrouillage' de la commande à distance a été pressé . Dans cet exemple, le déverrouillage est en termes de temps dépendant de la condition selon laquelle le bouton de la commande à distance est actionné. Pour la construction d'une telle 35 exigence, il faut ajouter dans le méta-modèle un nouvel élément qui est appelé RelativeTime . Il est une instanciation concrète de l'élément PointOfTime, étant donné qu'on 2907933 49 définit ainsi un instant auquel la condition doit se présenter. La figure 31 montre l'exigence sous forme de texte en combinaison avec l'instance de méta-modèle qui y correspond. L'élément RelativeTime a pour enfant, outre l'élément Time, un BaseExpressionElement avec lequel existe une dépendance. La modélisation d'une dépendance relative permet d'exprimer 5 des affectations successives dans le temps des états des objets d'interface à l'intérieur de la pré-condition et de la réaction attendue. Ce qui aboutit à un comportement réactif. Un comportement réactif décrit une processus dans lequel on attend un évènement donné, à la suite duquel a lieu une activité. Dans cet exemple on attend que le bouton `déverrouillage' de la commande à distance soit pressé. 3 secondes après, le véhicule est déverrouillé. 10 On peut dire en résumé que : • L'élément RelativeTime permet de décrire un comportement réactif : il n'est pas nécessaire de connaître un instant absolu pour définir les dépendances, du fait qu'on peut attendre la survenance d'un évènement. 15 • Des évènements peuvent être décrits successivement à l'intérieur de la pré-condition et de la réaction attendue, même si on ne connaît pas d'indications temporelles absolues. Le troisième point de vue à prendre en compte réside dans l'existence d'un élément Soonest 20 dans la réaction attendue. Exemple Après qu'un véhicule a été ouvert, mais n'a été ni démarré ni reverrouillé après 4 minutes, le verrouillage centralisé doit automatiquement verrouiller les portes, pour qu'aucune 25 personne étrangère ne puisse accéder au véhicule. Mais le véhicule ne doit pas être reverrouillé immédiatement, car les personnes ont besoin du temps pour monter et descendre. Le verrouillage automatique doit se produire au plus tôt après 4 minutes. Pour tester cette fonctionnalité, il faut vérifier si le véhicule reste déverrouillé entre 0 et 4 minutes. Il faut également tester si le véhicule se verrouille n'importe quand après 4 30 minutes . Dans ce cas se pose la question de savoir combien de temps il faut attendre la survenance de cet état. Le test ne peut pas durer indéfiniment. La figure 32 montre l'état de verrouillage du véhicule dans la période de 0 à 7 minutes. Quand le test doit-il être interrompu ? Au bout de 35 5, 6 10, 60 minutes ? Si le test est interrompu au bout de 5 minutes, il n'aura pas été possible de décider si le test a échoué ou si le verrouillage du véhicule se serait encore produit si le 2907933 test avait été poursuivi. Pour fixer au test un cadre temporel, un Timeout doit être défini par l'utilisateur lors de la création de l'exigence. Dans cette section et dans les précédentes ont été définis les éléments du méta-modèle 5 d'exigences. En font partie entre autres la description des objets d'interface, des états, des opérateurs et des conditions temporelles. Les objets d'interface et les états sont des éléments qui sont spécifiques à l'objet de test. Tout objet de test a des variables spéciales pour les interfaces, qui peuvent adopter des valeurs déterminées. Étant donné que ces variables et ces valeurs dépendent de la plateforme de test utilisée, mais qu'un test doit tout d'abord être 10 décrit d'une manière générale, les exigences sont décrites indépendamment de la plateforme de test. L'indépendance par rapport à la plateforme de test est le sujet qui suit. Pour qu'un test de logiciel soit configuré efficacement, la reproductibilité du test est on ne peut plus souhaitable. Les tests se font de manière optimale à différents niveaux du 15 développement d'un logiciel, et non pas uniquement à l'achèvement du développement. Comme déjà décrit, il existe actuellement des modèles exécutables dans la phase de projet. Il s'agit par exemple d'ordinogrammes ou d'automates d'état qui peuvent être exécutés dans un environnement de simulation (par exemple MATLAB /Simulink ). Des tests peuvent ainsi déjà être effectués sur un modèle. Il faut par ailleurs tester le code programme ainsi développé, 20 puis un prototype qui, dans le cas d'un système incorporé, agit dans un environnement matériel. Pour tester un objet de test, on a besoin d'une plateforme de test sur laquelle l'objet du test est exécuté. On peut voir sur la figure 12 un objet de test qui est raccordé à une plateforme. On a déjà montré que le modèle, le code programme et le prototype d'un système incorporé sont exécutés sur différentes plateformes. Le modèle fonctionne par exemple dans 25 un environnement de simulation, tandis que le prototype fini se situe dans un environnement matériel. Chaque plateforme présente des variables spécifiques avec lesquelles peuvent être adressées les entrées et les sorties, ainsi que des plages de valeurs spécifiques pour ces interfaces. 30 Pour qu'un test puisse être appliqué à tout niveau de développement indépendamment de la plateforme qu'il doit utiliser, il doit être décrit indépendamment de la plateforme. Une description du test indépendante de la plateforme doit utiliser pour les interfaces des désignations qui doivent être mappées sur des variables qui sont compréhensibles pour les plateforme de test réelles. La figure 33 présente les objets de test qui sont produits dans le 35 cadre du développement d'un appareil de commande. Chacun de ces objets de test, qu'il s'agisse du modèle, du code programme ou du prototype d'un système incorporé, présente 2907933 51 des entrées pour l'affectation de valeurs. Si le bouton de la commande à distance du véhicule est pressé pour le déverrouillage du véhicule, une entrée reçoit cette information. Les entrées mappés représentent la même information dans des modes différents. Dans un modèle, une entrée peut être modélisée par un signal. Si un code programme est produit à partir de ce 5 modèle, l'entrée peut être représentée par un appel de fonction avec des paramètres. Une réalisation de cette entrée dans l'appareil de commande peut se faire par l'application d'une tension à des broches. Les différentes représentations des interfaces dans les objets de test sont encapsulées par la plateforme de test. Mais il existe différentes implémentations de plateformes de test qui réalisent les interfaces vers l'outil de test de différentes manières. 10 L'information qui est représentée par une entrée dans un outil de test peut être modélisée par plusieurs entrées dans un autre outil de test. Il faut en conséquence, pour permettre une reproductibilité, une description de cette entrée indépendante de la plateforme de test dans une exigence, et un mappage sur les désignations réelles des entrées. Des langages de description de tests indépendants de la plateforme sont de nos jours souvent utilisés dans le 15 cadre d'échange de tests entre différents départements et différentes entreprises qui travaillent en commun sur un projet. À titre d'exemple on peut citer les TestML [GCF+06], TTCN-3 [GraOO], ATML (Automatic Test Markup Language) et UML Testing Profile. Mais dans la pratique, des difficultés apparaissent lors de la réalisation du concept de 20 description de test indépendante de la plateforme. Pour garantir la reproductibilité d'un test tout au long des différentes phases du développement, il faut veiller à n'utiliser dans le test que les interfaces qui sont accessibles dans tous les objets de test (modèle, code, prototype). Si on développe un test dans lequel doivent être testées trois fonctions différentes qui peuvent être testées indépendamment les unes des autres, il peut arriver qu'une seule des fonctions 25 soit accessible de l'extérieur dans le prototype. La figure 34 montre les trois fonctions dans le logiciel d'un système incorporé. La fonction A peut être appelée de l'extérieur, tandis que les fonctions B et C sont toutes deux activées par la fonction située en amont, et ne sont pas accessibles par l'intermédiaire d'interfaces. Un test de fonctions successives de cette nature ne présente pas la propriété de la reproductibilité. L'accessibilité des interfaces du logiciel à 30 produire doit donc être pensée en avant-plan, pour que ces aspects puissent entrer dans la production du test. Pour décrire à l'aide du méta-modèle des exigences qui peuvent être utilisées pour la génération d'un test indépendant de la plateforme, les éléments du méta-modèle doivent déjà 35 être indépendants de la plateforme. Il en découle pour avantage qu'il est possible de produire des tests pour toutes les plateformes. Dans le modèle d'exigence, les objets d'interface 2907933 52 représentent les variables des interfaces dans l'objet de test. Chaque objet d'interface est donc univoque, pour qu'il soit possible d'effectuer un mappage d'un objet d'interface sur la variable correspondante de l'objet de test. Les informations spécifiques à la plateforme telles que les sorties et les plages de valeurs doivent être disponibles pour ce processus de 5 mappage. La figure 35 présente une description d'exigence indépendante de la plateforme qui est convertie en une spécification de test indépendante de la plateforme. Comme déjà exposé, une spécification de test décrit les différentes étapes du test, et ne sera pas à nouveau 10 présentée en détail. À partir de la spécification de test est générée une implémentation concrète pour chaque objet de test. Dans cette étape on effectue le mappage des objets d'interface indépendants de la plateforme et de leurs états sur les variables de l'objet de test spécifiques à la plateforme et leurs valeurs pour lesquelles les informations relatives à la plateforme doivent être disponibles. Un objet d'interface peut alors être mappé sur plusieurs 15 variables spécifiques si l'objet d'interface décrit dans l'exigence doit dans la réalité être réalisé par plusieurs entrées ou sorties. Dans de nombreux exemples de la présente invention, on a utilisé la phrase le véhicule est déverrouillé pour exprimer que toutes les portes du véhicule sont déverrouillées. S'il existe sur la plateforme une variable pour chaque porte, l'objet d'interface le véhicule doit être mappé sur les variables de toutes les portes, comme le montre 20 le figure 36. Les variables spécifiques à la plateforme peuvent adopter des valeurs déterminées qui définissent implicitement une plage de valeurs. Le méta-modèle utilise un ensemble partiel du langage naturel avec lequel l'utilisateur peut formuler ses exigences. En restreignant l'outil verbal, on obtient toujours des exigences qui ne 25 peuvent pas être exprimées. En conséquence, ce méta-modèle a été conçu pour pouvoir être étendu. Les recherches pour trouver pour le méta-modèle un ensemble d'éléments qui permet d'exprimer pratiquement tous les états de fait sortent du cadre de la présente invention, et seront l'objet d'autres travaux. Les éléments disponibles du méta-modèle ont été sélectionnés sur la base d'exemples d'exigences qui peuvent être construites à l'aide des concepts 30 présentés et des exemples provenant de la pratique. La possibilité d'extension constitue une propriété importante pour que le méta-modèle puisse être étendu dans des activités ultérieures. La modélisation du méta-modèle au moyen du langage UML permet d'ajouter à moindre effort 35 de nouveaux éléments sous la forme de classes supplémentaires. De nouveaux éléments peuvent également être définis sous la forme de spécialisations de classes existantes, et 2907933 53 héritent ainsi de leurs propriétés. Un nouvel opérateur binaire serait une implémentation supplémentaire du BinaryOperator abstrait. Suite à une extension d'un méta-modèle UML, les éléments ne sont étendus que d'une association qui est en relation directe avec le nouvel élément. Aucun des autres éléments n'est affecté par l'extension. Ce qui montre que 5 l'extension du méta-modèle est très simple. L'utilisateur doit pouvoir formuler ses exigences en alignant des mots à partir de la gauche, de telle manière que le processus et l'agencement des mots correspondent à une construction de phrase normale. Une lisibilité intuitive est donc une propriété très importante d'une 10 exigence, pour rendre la formulation la plus simple possible pour l'utilisateur. À ce stade suit un mappage deséléments du méta-modèle sur les fragments de phrase, qui est défini de manière inductive. La notation Iff(precondition, expectedReaction) signifie alors que les instances de l'élément Iff du méta-modèle sont mappées avec les instances des éléments qui ont été obtenus par les associations precondition et expectedReaction sur le fragment de 15 phrase restant. Les éléments qui ont été obtenus par les associations sont à nouveau mappés sur des fragments de phrase, de sorte qu'apparaît au bout du compte une phrase complète en langage naturel. • BaseExpression -Iff(precondition, expectedReaction) - 20 "If and only if , then ." Implies(precondition, expectedReaction) - "If , then ." • BinaryOperator - XOR(childOne, childTwo) "either or " 25 - OR(childOne, childTwo) - " or " - AND(childOne, childTwo) -" and " • UnaryOperator -NOT(baseExpressionElement) "not " • PointOfTime 30 - ExactlyTime(time) ù> "after exact time units" - Soonest(time) ù> "after not less than time units - NotLaterThan(time) ù> "after no more than time units" - BetweenTime(lowerTime, upperTime) ù> "after between and time units" 35 • LengthOfTime 2907933 54 - ExactlyDuration(duration) ù> "for exact time units" - AtLeast(duration) ù> "for at least time units" - AtMost(duration) ù> "for at most time units" -BetweenDuration(lowerDuration, upperDuration) ù> "for between 5 and time units" • ValueCondition - ExactlyValue(interfaceElement, valueElement) " is " - AtMostforValue(interfaceElement, valueElement) - " is 10 at most " -AtLeastforValue(interfaceElement, valueElement) " is at least " -WithinValue(interfaceElement, lowerValue, upperValue) - " is between and 15 " • InterfaceElement - " " L'unité de temps abstraite time units est remplacée par l'unité de temps que l'utilisateur a choisie. 20 La formulation d'exigences en langage naturel ne garantit pas une compréhension univoque des assertions du fait que beaucoup de mots individuels ont plusieurs significations. La combinaison de termes ambigus amplifie l'ambiguïté qui rend la compréhension très difficile. Pour pouvoir obtenir des assertions précises et définir des sémantiques, les mathématiques 25 et l'informatique utilisent des logiques. Il `agit en fait de langages formels. Les logiques habituelles comprennent la logique des assertions et la logique des prédicats, qui permettent de formuler des assertions statiques. Mais les systèmes incorporés contiennent des fonctionnalités pour lesquels le temps est un aspect critique, par exemple le déverrouillage du véhicule en cas d'accident. Les aspects temporels ne peuvent pas être exprimés dans ces 30 logiques. Pour décrire des assertions comportant une référence temporelle, il existe des logiques temporelles qui sont par exemple utilisées dans les méthodes permettant de démontrer l'absence de défaut telles que le model checking. Les plus fréquemment utilisées sont la Computation Tree Logic (CTL) [CES86] et la Linear Time Logic (Pnu77]. Elles peuvent exprimer des aspects temporels, mais uniquement au plan qualitatif. Les indications 35 quantitatives, telles que le nombre d'unités de temps avant la survenance d'un évènement, n'y 2907933 trouvent pas leur place. Des conditions de ce type doivent pourtant être définies pour les systèmes incorporés. Le nombre d'unités de temps au bout duquel un airbag doit réagir suite à un accident en constitue un exemple. D'autres logiques temporelles ont été développées pour qu'on puisse disposer d'assertions temporelles quantitatives. La Real time Computation 5 Tree Logic (RTCTL) du document [EMSS91] en fait partie. Elle émane de la logique CTL, qui a été étendue à des constructions quantitatives. La logique RTCTL est définie par les phrases suivantes en utilisant un alphabet d'assertions atomiques E 1. Toute assertion atomique P E E est une formule RTCTL. 10 2. Si p et q sont des formules RTCTL, p A q et ù, p sont également des formules RTCTL. 3. Si p et q sont des formules RTCTL, A(p U q), E(p U q) et EX p sont également des formules RTCTL. 4. Si p et q sont des formules RTCTL, et si ke N , A(p U≤' q) et E(p U≤' q) sont également des formules RTCTL. 15 La sémantique des deux premières phrases découle de la logique des assertions. Les définitions de A(p U q), E(p U q) et EX p émanent de la logique CTL et disent ce qui suit : comme il a été décrit, les systèmes incorporés fonctionnent selon un comportement temporel discret. En conséquence, ils se trouvent à tout moment dans un état discret déterminé. Ce qui 20 permet de modéliser les systèmes incorporés sous la forme d'automates d'état, la durée d'exécution d'une transition correspondant à une unité de temps. Du fait qu'il peut pour chaque état y avoir plusieurs états successifs en fonction des valeurs d'entrée, il existe un arbre qui représente toutes les conséquences des transitions d'état. Les états intervenant successivement sont définis sur l'arbre par un chemin. La formule p U q signifie que la 25 formule RTCTL p s'applique jusqu'à la survenance de q. A et E sont les quantificateurs universels et existentiels généralement connus, qui définissent que la formule qui les suit doit s'appliquer pour tous les chemins et/ou pour au moins un chemin de l'arbre. Selon la définition de la logique CTL, EX p veut dire que p s'applique dans au moins un des états suivants. 30 La quatrième phrase est définie dans la logique RTCTL. Elle étend les formules A(p U q) et E(p U q) aux composants temporels `k à A(p U≤' q) et E(p U≤' q). Ces formules indiquent que q remplace p dans un délai de k transitions d'état. Donc, q s'applique au plus tard après k transitions et p s'applique avant pour tout état. Cette expression permet d'arriver à des assertions concernant un comportement qui survient après k transitions. Mais il y a également 35 dans le méta-modèle d'exigences des conditions temporelles avec lesquelles doivent pas 2907933 56 exemple être représentées des transitions après au plus tôt k ou des transitions entre a et b . Pour pouvoir exprimer toutes les conditions temporelles du méta-modèle d'exigences, il faut une extension de la définition aux opérateurs A(p U-k q) et E(p U-k :q) avec -E { , j, ainsi que A(p U[a,b' q) et E(p U[a,b' q) avec a,b E N, a b, qui émanent de 5 [EMSS91]. La restriction k E N dit que la compréhension du temps dans la logique RTCTL est discrète. Il convient de citer en tant qu'autre logique temporelle quantitative la logique TCTL [ACD93] avec laquelle il est possible d'arriver à des assertions à l'aide d'automates de temps. Les 10 automates de temps représentent une extension à l'heure des automates finis, de sorte que les aspects temporels peuvent être pris en compte. Contrairement a la logique RTCTL, la logique TCTL a une compréhension continue du temps. Ce qui confère à la logique temporelle un haut niveau de flexibilité. Mais l'utilisation d'une compréhension continue du temps fait que l'exécutabilité n'est plus décidable [ACD93], de sorte qu'en conséquence, les 15 exigences contradictoires ne peuvent pas être identifiées. L'identification des contradictions dans les exigences formulées est pourtant une aide précieuse pour l'utilisateur. Une perspective de la présente invention peut être l'analyse des exigences pour lesquelles l'objectif d'exécutabilité doit être décidable. 20 Les systèmes incorporés présentent comme déjà décrit un cycle temporel fixe, dans lequel ils doivent être exécutés. C'est pourquoi l'utilisation d'une logique temporelle ayant une compréhension discrète du temps ne constitue pas une restriction. Pour les raisons citées, le choix de la logique temporelle se portera sur la logique RTCTL sur laquelle les constructions des exigences seront mappées. Dans la logique RTCTL, l'exécutabilité est décidable, comme 25 démontré dans le document [EMSS91] Le mappage sur les expressions RTCTL se fait de manière inductive. La notation Iff(precondition, expectedReaction) signifie alors que les instances de l'élément Iff du méta-modèle reçoivent avec les instances des éléments qui ont été obtenus par les associations 30 precondion et expectedReaction la sémantique suivante. Les éléments qui ont été obtenus par les associations présentent à leur tour une définition sémantique. Par les associations precondition et expectedReaction, on obtient par exemple les éléments de type BaseExpressionElement. Les instanciations concrètes de cet élément sont AND, OR, XOR, NOT, et InterfaceElement, dont la sémantique est définie. De l'ensemble des définitions 35 découlent ensuite les formules RTCTL. 2907933 57 • BaseExpression - Iff(precondition, expectedReaction) precondition expectedReaction - Implies(precondition, expectedReaction) ù> precondition expectedReaction • BinaryOperator 5 - XOR(childOne, childTwo) ù> (childOne n childTwo) v (ù1 childOne n childTwo) -OR(childOne, childTwo) - childOne v childTwo - AND(childOne, childTwo) -childOne n childTwo • UnaryOperator 10 - NOT(baseExpressionElement) ~ù baseExpressionElement Les mappages en PointOfTime et LengthOfTime d'un élément InterfaceElement ne peuvent pas être effectués indépendamment les uns des autres, du fait qu'une référence temporelle commune est nécessaire. Les mappages se font en conséquence pour un InterfaceElement 15 dans son contexte (InterfaceElement(pointOfTime, lengthOfTime, valueCondition)). Si t E N et V est une ValueCondition associée dans la logique RTCTL, qui est représentée comme suit: • Value Condition 20 - AtMostforValue(interfaceElement, valueElement) ù> interfaceElement valueElement - AtLeastforValue(interfaceElement, valueElement) ù> interfaceElement valueElement - ExactlyValue(interfaceElement, valueElement) ù> interfaceElement = valueElement 25 -WithinValue(interfaceElement, lowerValue, upperValue) ù> lowerValue interfaceElement upperValue V s'applique au moment ExactlyTime(time) pour la durée ExactlyDuration(duration) ù> A(true U=time V ) A -iE(true U[time,time+duration]-,V) A -iE(true U>time+durationv) 30 Cette expression définit que la ValueCondition associée V intervient toujours après time unités de temps. Il ne doit pas y avoir entre time et time + duration d'instant où la ValueCondition n'est pas remplie. Par ailleurs, la ValueCondition ne doit plus s'appliquer après time + duration., • V s'applique au moment ExactlyTime(time) pour la durée AtLeast(duration) ù> 35 A(true (Ytime v ) A -iE(true U[time,time+duration]iv) 5 2907933 58 Cette formule se différencie de la précédente en ce que la dernière restriction disparaît. Il s'agit en l'occurrence de l'élément AtLeast qui exprime que la ValueCondition doit être remplie pendant au moins duration unités de temps, de sorte qu'il n'y a pas de limite supérieure. Les définitions de la sémantique de toutes les autres combinaisons de PointOfTime et LengthOfTime figurent en annexe A. Avant qu'il ne reçoive un programme de test qui a été généré à partir de l'exigence qu'il a 10 créée, il est important que l'utilisateur soit informé des étapes de test qui ont lieu. Dans le cas contraire, il pourrait arriver que l'utilisateur spécifie une exigence, et exécute le programme de test généré sans savoir ce qui est précisément testé. Dans ce cas, il serait difficile de comprendre les résultats du test. 15 L'exigence Si le bouton `déverrouillage' de la commande à distance est pressé alors le véhicule est déverrouillé après 2 secondes entraînerait les étapes de test suivantes : • Mettre le bouton `déverrouillage' de la commande à distance sur pressé • Attendre 2 secondes. • Vérifier si le véhicule est déverrouillé. 20 Ci-après est présenté le méta-modèle de spécification de test qui contient les éléments permettant la description des étapes de test. Une instance de ce méta-modèle représente un déroulement concret du test, et est automatiquement dérivée d'une instance du méta-modèle d'exigences, de sorte que d'une exigence concrète découle une spécification de test. Pour 25 l'intégration du méta-modèle de spécification de test dans le contexte général du concept de génération de tests basée sur les exigences, la figure 37 reprend la vue d'ensemble de la figure 35. Les méta-modèles pour l'exigence et la spécification de test ont été complétés. La figure 38 montre un extrait du méta-modèle de spécification de test. L'élément Test 30 constitue l'élément de base du méta-modèle de spécification de test. Un test est composé d'un ou de plusieurs cas de test qui sont modélisés par l'élément TestCase . Plusieurs cas de test peuvent par exemple être la conséquence de l'élément Iff du méta-modèle d'exigences. Comme déjà décrit, l'utilisation de cet élément signifie que l'expression verbale Précisément si...alors est utilisée dans l'exigence. Pour qu'une telle exigence soit satisfaite, 35 il faut arriver aux assertions suivantes : si la pré-condition se présente, alors la réaction attendue doit se produire et si la pré-condition ne se présente pas, alors la réaction attendue 2907933 59 ne doit pas se produire. Les deux assertions doivent être testées, et constituent dans la spécification de test deux cas de test qui font partie du test. Un cas de test contient les éléments StimulusData et ReferenceData qui représentent la pré-condition et la réaction attendue. On peut en conséquence également parler en relation avec la spécification de test 5 d'une partie stimulus et d'une partie référence au lieu d'une pré-condition et d'une réaction attendue. Toute partie stimulus est composée de plusieurs étapes de test qui doivent être exécutées, de même que plusieurs étapes de test sont vérifiées dans la partie référence. Une étape de test 10 individuelle est représentée par l'élément TestStep . StimulusData et ReferenceData présentent tous deux une association à un élément TestStep qui constitue la première étape de test dans la partie stimulus et la partie référence. Tout élément TestStep peut avoir comme successeur un nouvel élément TestStep, de sorte qu'il en découle une succession d'étapes de test. Ceci est réalisable par une association de l'élément TestStep à lui-même, comme on 15 le voit sur la figure 38. Un élément TestStep abstrait est concrétisé par les éléments ParStep et SeqStep . ParStep offre la possibilité d'exécuter deux étapes de test parallèlement, en ce sens qu'il présente deux éléments TestStep. Il est également possible de modéliser parallèlement des 20 séquences de test compètes. Cette situation se produit dès qu'un élément TestStep d'un élément ParStep a pour successeur un autre élément TestStep. On peut ainsi produire des séquences de test comme représenté sur la figure 39. L'élément SeqStep représente une étape de test individuelle. Il présente une association à un 25 InterfaceElement précis, dont la sémantique se différencie de celle de l'InterfaceElement du méta-modèle d'exigences. Avec ('InterfaceElement de la spécification de test, on modélise le fait qu'une entrée oui une sortie précise est adressée dans une étape de test. Dans chaque étape de test a lieu une affectation d'une valeur à une entrée ou une sortie. Comme dans le méta-modèle d'exigences, ('InterfaceElement présente les éléments ValueElement, 30 PointOfTime et LengthOfTime. L'InterfaceElement du méta-modèle d'exigences spécifiait également une affectation entre une entrée ou une sortie et une valeur. Dans la pré-condition, une telle affectation signifiait Si entrée = = valeur, alors et était donc une sorte d'interrogation pour savoir si cette affectation s'appliquait. Dans la partie stimulus de la spécification de test, une affectation définit l'indication selon laquelle Entrée = Valeur doit 35 être établi pour vérifier ensuite la réaction du système. Il s'agit là d'une consigne. Les conditions temporelles dans le méta-modèle de spécification de test sont équivalentes aux 2907933 conditions temporelles dans le méta-modèle d'exigence. La sémantique de la spécification de test est définie par son mappage sur l'implémentation du test, étant donné que les implémentations de test présentent elles-mêmes une sémantique. 5 La sémantique des séquences de test des tests exécutables de l'outil d'automatisation des tests AutomationDesk est par exemple définie implicitement par l'implémentation de cet outil d'automatisation des tests. Les étapes de test doivent être présentées à l'utilisateur sous la forme du langage naturel. 10 Bien que quelques éléments du méta-modèle de la spécification de test soient identiques à des éléments du méta-modèle d'exigence, les fragments de phrase sur lesquels les éléments sont mappés sont différents, du fait que la sémantique de ces éléments est différente. Cette section concerne le mappage des éléments du méta-modèle de spécification de test sur des fragments de phrase. 15 Dans la partie stimulus, des valeurs sont affectées aux entrées et aux sorties, et dans la partie référence, on vérifie si les entrées et les sorties présentent bien certaines valeurs. Étant donné que ces deux processus sont différents, l'élément InterfaceElement est mappé de deux manières différentes sur le langage naturel, selon qu'il fait partie d'un élément StimulusData 20 ou d'un élément ReferenceData. La notation InterfaceElement(exactlyValue, valueElement) signifie qu'un InterfaceElement est mappé avec la ValueCondition exactlyValue qui lui est affectée et le ValueElement valueElement correspondant sur le segment de phrase suivant. L'expression désigne le nom de l'élément InterfaceElement qui a été spécifié par l'utilisateur. 25 • StimulusData: InterfaceElement - InterfaceElement(exactlyValue, valueElement) - "Set to " - InterfaceElement(atMostforValue, valueElement) - 30 "Set to at most " - InterfaceElement(atLeastforValue, valueElement) - "Set to at least " - InterfaceElement(withinValue, lowerValue, upperValue) - "Set to between and 35 " 2907933 61 • ReferenceData:InterfaceElement - InterfaceElement(exactlyValue, valueElement) ù> "Check if is " - InterfaceElement(atMostforValue, valueElement) ù> "Check if 5 is at most " - InterfaceElement(atLeastforValue, valueElement) - "Check if is as least " - InterfaceElement(withinValue, lowerValue, upperValue) ù> "Check if is between 10 and " La condition temporelle PointOfTime est mappée sur des fragments de phrase comme suit : • PointOfTime - ExactlyTime(time) "Wait exact time units" - Soonest(time) - "Wait not less than time units" 15 - NotLaterThan(time) "Wait no more than time units" - BetweenTime(lowerTime, upperTime) - "Wait between and time units" La condition temporelle LengthOfTime reçoit dans la spécification de test des significations 20 différentes dans la partie stimulus et dans la partie référence. L'indication de la durée dans la partie stimulus veut dire que l'affectation d'un état à un objet d'interface pour le temps défini par la durée doit être établie. Dans la partie référence, il s'agit de vérifier si l'affectation de l'état décrit à l'objet d'interface s'applique dans la partie référence à la durée spécifiée. Ces deux relations dans lesquelles la durée joue un rôle représentent deux procédures différentes 25 dans la spécification de test. Il est en conséquence approprié de présenter à l'utilisateur les deux procédures en langage naturel. La figure 40 montre une exigence comportant la durée pendant au moins 2 secondes dans la pré-condition et la durée pendant au moins 3 secondes dans la réaction attendue. Les deux indications de durée présentent dans l'exigence la même représentation verbale. Dans la spécification de test, ces indications de 30 durée sont représentées par des fragments de phrase différents. La durée est représentée dans la partie stimulus par la phrase attendre 2 secondes , et dans la partie référence par l'expression pendant 3 secondes du fait que la consigne de contrôle qui en découle doit être exécutée pendant 3 secondes. 2907933 62 Dans la partie stimulus, il s'agit de montrer à l'utilisateur qu'après l'affectation de l'état à l'objet d'interface, il faut attendre pendant la durée spécifiée. On obtient ainsi que cette affectation s'applique pendant la durée spécifiée. • StimulusData: LengthOfTime 5 - ExactlyDuration(duration) - "Wait for exact time units" - AtLeast(duration) - "Wait for at least time units" - AtMost(duration) - "Wait for at most time units" -BetweenDuration(lowerDuration, upperDuration) - "Wait for between and time units" 10 Dans la partie référence, la durée spécifiée pour le temps détermine combien de temps la vérification de l'affectation définie d'un état à l'objet d'interface doit durer. En conséquence, la durée occupe dans ce cas une position différente dans la phrase. La durée est placée avant l'affectation de l'état et l'objet d'interface 15 • ReferenceData: LengthOfTime - ExactlyDuration(duration) -+ "For exact time units" - AtLeast(duration) - "For at least time units" - AtMost(duration) - "For at most time units" -BetweenDuration(lowerDuration, upperDuration) - 20 "For between and time units" Pour effectuer ces affectations des éléments InterfaceElement et ValueElement aux étapes de test avec les conditions temporelles correspondantes, et pour structurer les étapes de test en un déroulement de test d'un test complet, s'appliquent les mappages suivants : 25 • Test(testCasel , testCaseN) - TestCase: " ... TestCase: " • TestCase(stimulusData, referenceData) - " " • StimulusData(testStep) - " " • ReferenceData(testStep) " " • TestStep 30 -SeqStep(interfaceElement) " "' -ParStep(nextStepOne, nextStepTwo) "parallel: first parallel step: second parallel step: 2907933 63 On a déjà décrit les éléments qu'offre le méta-modèle d'exigence pour la formulation d'une exigence. Le méta-modèle de spécification de test contient les éléments permettant de décrire les différentes étapes de test à l'intérieur du déroulement du test. Une exigence concrète sous la forme d'une instance du méta-modèle d'exigence doit alors être transformée en une 5 spécification de test concrète sur la base du méta-modèle de spécification de test. À cette fin il faut définir sous forme de règles pour un élément du méta-modèle d'exigence comment il sera mappé sur un ou plusieurs éléments du méta-modèle de spécification de test. Les règles de transformation décrivent ainsi quelles étapes de test sont entraînées par un élément d'une exigence concrète, et déterminent ainsi la signification des éléments de l'exigence pour le 10 déroulement du test. Étant donné qu'est effectuée une transformation d'une instance du méta-modèle d'exigences dans laquelle ne peut apparaître aucune instance des classes abstraites, aucune règle de mappage n'est nécessaire pour les éléments abstraits Comme on le voit sur la figure 41, l'élément Implies est mappé sur la structure d'éléments 15 suivante de la spécification de test. Un élément Test présente une association à un élément TestCase précis. L'élément TestCase présente un élément StimulusData et un élément ReferenceData. L'élément Iff est mappé sur presque la même structure. Mais étant donné que, comme déjà 20 décrit, deux cas de test son dérivés de cet élément, l'élément Test présente deux éléments TestCase présentant chacun un élément StimulusData et un élément ReferenceData. Un des cas de test devient un test négatif en ce qu'une consigne de négation est donnée par un attribut d'un des éléments InterfaceElement. La figure 42 montre cette étape de transformation. 25 Un InterfaceElement d'une exigence est mappé sur un élément SeqStep et sur un InterfaceElement de la spécification de test qui lui est relié. Cet InterfaceElement présente exactement les mêmes éléments que l'InterfaceElement d'une exigence. En fait partie par exemple une ValueCondition. La figure 43 montre un mappage d'un élément 30 InterfaceElement. Les règles de transformation des opérateurs sont décrites ci-dessous. L'opérateur NOT peut inverser l'état qui est affecté à un objet d'interface. Par ailleurs, cet opérateur peut également inverser des expressions complètes qui sont reliées par un opérateur binaire. Du fait que dans une spécification de test, toutes les affectations d'un état à 35 un objet d'interface forment une étape de test séparée, la négation d'une expression complète doit être éliminée dans une exigence avant la transformation, pour créer des conditions 2907933 64 inversées individuelles qui sont transformées en étapes de test négatives individuelles. À cette fin, on détermine pour chaque élément en utilisant les opérateurs NOT si l'état doit ou non être inversé pour cet InterfaceElement. La figure 44 présente la conversion d'une expression inversée globalement en expressions inversées séparément. On applique alors les 5 lois de la logique des expressions [SchOO], telles que par exemple les lois de De Morgan, qui définissent comme suit la négation de la conjonction et de la disjonction. • pas (a et b) = (pas a) ou (pas b) • pas (a ou b) = (pas a) et (pas b) 10 Dans l'exemple de la figure 44, et devient ou suite à la conversion de l'expression inversée globalement en expressions inversées individuellement. La présence d'opérateurs binaires dans une exigence entraîne dans une spécification de test la production d'un élément ParStep qui mémorise dans un attribut le type de l'opérateur 15 binaire. De ce fait, les expressions liées par un opérateur binaire deviennent dans la spécification de test des étapes de test ou des séquences de test à exécuter parallèlement. La figure 45 montre la transformation de l'instance d'un élément AND du méta-modèle d'exigence. Il en résulte une instance d'un élément ParStep du méta-modèle de spécification de test qui enregistre sous forme d'attributle type de l'opérateur. Même si les opérateurs 20 binaires sont mappés sur des éléments ParStep, le type de l'opérateur ne doit pas être oublié, car chaque opérateur présente une autre sémantique et entraîne donc des processus différents dans le test exécutable. L'opérateur XOR (SOIT SOIT) peut être exprimé selon les lois de la logique des expressions par les opérateurs AND, OR et NOT, de sorte que l'élément XOR lui-même n'est pas 25 transformé. Le méta-modèle d'exigence offre grâce à des éléments tels que AtMost et AtLeast une description très précise des aspects temporels. L'élément AtMost ne définit par exemple qu'une limite supérieure d'une durée, de sorte que cette spécification ne donne pas 30 connaissance de la durée concrète. Ce qui laisse la liberté d'effectuer les tests avec plusieurs valeurs. Mais une telle spécification du temps ne suffit pas pour exécuter une test concret. Pour effectuer un test, il faut fixer exactement quand une entrée ou une sortie doit recevoir une valeur, car ces affectations de la partie stimulus sont établies dans des conditions temporelles concrètes pour la vérification de la réaction de l'objet de test. Il doit donc exister 35 quelque part à l'intérieur de l'ensemble du déroulement, entre la création de l'exigence et l'exécution concrète du test, une indication précise des conditions temporelles. Ce qui amène 2907933 la question de savoir quand les indications temporelles doivent être concrétisées. Les informations manquantes pour effectuer un test sont appelées degrés de liberté. Une possibilité pour concrétiser les conditions temporelles consiste à proposer à l'utilisateur 5 une spécification de test comportant une fonctionnalité avec laquelle il peut compléter les conditions temporelles de la spécification de test pour en faire des indications temporelles spécifiées avec précision, et éliminer ainsi les degrés de liberté. Mais pendant le déroulement allant de l'exigence au test, la flexibilité est rapidement perdue 10 par cette approche. La personne exécutant le test peut ne pas être celle qui crée l'exigence et qui reçoit la spécification de test. En conséquence, les informations flexibles peuvent être perdues, de sorte que ne peut être effectué qu'un unique test. Un exemple est exposé ci-après. 15 La figure 46 présente une exigence. Les étapes de test qui en sont dérivées ne peuvent être exécutées que si les degrés de liberté sont éliminés. Il faut définir si le bouton `déverrouillage ` de la commande à distance doit être pressé 2 ou 3 secondes, ou peut-être beaucoup plus longtemps, pour que la pré-condition puisse être ajustée pendant le test. Les étapes de test de la figure 46 montrent par les expressions 2 + combien de secondes et 3 - combien de 20 secondes les degrés de liberté, qui doivent être spécifiés de manière plus précise. Les tests sont souvent effectués avec différentes valeurs. Si une condition temporelle est fixée trop tôt à une valeur concrète, le test ne pourra être fait qu'avec la valeur fixée. Par ailleurs, il se peut que les indications temporelles ne soient pas encore précisément 25 connues de l'utilisateur au moment de la création de la spécification de test, de sorte qu'il n'est pas en mesure d'éliminer les degrés de liberté. Cette argumentation amène à retarder la spécification des conditions temporelles exactes vers l'arrière à l'intérieur du processus allant de l'exigence au test, en conséquence de quoi la 30 flexibilité est maintenue plus longtemps. Le méta-modèle de spécification de test contient ainsi pour la définition des instants et des indications temporelles les mêmes éléments que le méta-modèle d'exigence. Du fait que l'utilisateur peut souvent utiliser librement un InterfaceElement à l'intérieur d'une 35 exigence pour lui affecter divers éléments de type ValueElement à des instants différents, l'utilisateur risque de définir des exigences contradictoires. L'exigence de la figure 47 contient 2907933 66 une pré-condition dans laquelle l'InterfaceElement vitesse doit adopter à des instants différents les valeurs 20 km/h et 30 km/h . La définition des indications temporelles pour les deux consignes d'état est constituée par des intervalles qui se chevauchent. Le chevauchement des intervalles de temps spécifiés pour l'attribution de valeurs différentes à 5 un InterfaceElement peut donner naissance à une exigence contradictoire. Pour exclure avant la génération d'un test concret qu'il puisse s'agir d'une exigence contradictoire, la présence d'une contradiction peut être testée en utilisant un algorithme. On peut citer comme exemple l'algorithme de backtracking qui vise à faire pas à pas d'une solution 10 partielle atteinte une solution globale. Soit l'algorithme trouve une solution, soit il n'y a pas de solution au problème. Le test de présence d'une contradiction dans les exigences a été essayé avec l'algorithme de backtracking. Si l'algorithme de backtracking ne trouve pas de solution, il s'agit d'une exigence contradictoire. L'algorithme de backtracking n'est qu'un simple exemple, car il peut présenter une durée exponentielle. Si un test de présence d'une contradiction dans le 15 prototype devait être effectué pour l'utilisateur, il faudrait développer un algorithme plus efficace. Mais pour un tel calcul visant à l'identification de la présence d'une contradiction, il a fallu mettre en oeuvre quelques mesures. Il a par exemple fallu fixer quelle durée concrète doit entrer dans le calcul si au plus 2 secondes est spécifié en tant que durée dans l'exigence,. Les degrés de 20 liberté ont donc dus être préalablement éliminés. En outre, il a fallu définir les conditions temporelles pour chaque attribution d'un ValueElement à un InterfaceElement. Mais étant donné que, comme déjà décrit, les éléments de spécification des conditions temporelles ont été modélisés à titre d'éléments optionnels, l'existence de spécifications temporelles n'est pas obligatoire. Dans un test réactif, on attend par exemple un évènement et on vérifie si un autre se 25 produit en réaction à l'évènement. Du fait qu'on ne sait pas quant l'évènement qu'on attend se produit, ceci ne peut pas être inclus dans la vérification de la présence d'une contradiction dans l'exigence. Ce qui montre qu'un tel contrôle de la présence d'une contradiction à ce stade est dépourvu de sens, et également comment l'élimination des degrés de liberté à l'intérieur de la chaîne allant de l'exigence au test concret est déplacée vers l'arrière. 30 L'exécution parallèle d'instructions dans un test permet d'exécuter un test avec une simplicité optimisée. Les étapes de test entraînent l'accès aux variables de l'objet de test. Si plusieurs accès à une variable sont exécutés simultanément du fait que des étapes de test sont exécutées parallèlement, l'outil de test interrompt le test. Les instructions contradictoires sont 35 ainsi identifiées par rapport à la durée. 2907933 67 Pour tester un objet de test, on a besoin d'un programme de test, qui est appelé ci-après implémentation du test. La figure 48 montre l'implémentation du test dans le contexte du concept global de la présente invention. . 5 Dans l'exigence, on décrit tout d'abord quel état est affecté à quel objet d'interface. La spécification de test décrit l'affectation de l'objet d'interface et de l'état dans les différentes étapes de test. Comme déjà décrit, l'exécution d'un test consiste à affecter des valeurs aux entrées de l'objet 10 de test et à lire des valeurs à ses sorties. Les valeurs lues sont comparées aux valeurs attendues. Pour la génération d'un test exécutable, les objets d'interface doivent être mappés sur les variables de l'objet de test. Il faut par ailleurs un mappage des états sur des valeurs concrètes. La figure 19 montre la relation entre objet d'interface, variable, état et valeur. Toute plateforme de test peut décrire les variables de l'objet de test et leurs valeurs de manière 15 différente. Un objet d'interface utilisé dans la spécification de test peut ainsi être mappé sur une variable précise de la plateforme de test. Mais il est également possible que l'objet d'interface exprime une circonstance qui est réalisée par plusieurs variables dans la plateforme de test. Ce qui entraîne le mappage d'un objet d'interface sur plusieurs variables. Cette situation est illustrée sur la figure 36. 20 L'outil de test utilisé peut offrir une fonctionnalité avec laquelle l'utilisateur peut entreprendre le mappage des objets de test et des états sur les variables et les valeurs de la plateforme de test. Le mappage nécessite que l'on sache quels objets de test et états doivent être affectés à quelles variables et valeurs de l'objet de test. 25 Tous les autres éléments de la spécification de test, comme par exemple les conditions temporelles ou l'élément ParStep pour l'exécution parallèle d'étapes de test, doivent être mappés sur les éléments fournis par l'outil de test pour produire un séquence de test exécutable dans l'outil de test. En général, les outils de test présentent entre autres des 30 éléments permettant la modélisation des conditions temporelles et de la parallélité. Comme il a déjà été décrit, les conditions temporelles peuvent présenter des degrés de liberté provenant d'indications telles que au moins 500 millisecondes . Mais dans l'implémentation du test, des indications temporelles précises doivent être définies pour que des instructions 35 concrètes puissent être exécutées. Les degrés de liberté doivent en conséquence être éliminés. Comme déjà exposé, cette concrétisation des conditions temporelles doit se faire le plus tard 2907933 68 possibilité dans la chaîne allant de l'exigence à l'implémentation du test de manière à conserver la flexibilité. En conséquence, les degrés de liberté sont encore présents dans la spécification de test, ce pour quoi leur élimination doit avoir lieu dans l'étape de l'implémentation du test. Une flexibilité la plus élevée possible peut être obtenue en représentant dans l'implémentation du test 5 les conditions temporelles ayant des degrés de liberté par des paramètres. La valeur de ces paramètres doit être ajustée par le testeur. Ceci crée la possibilité d'exécuter le test avec différentes entrées de paramètres, et donc différentes conditions temporelles concrètes, ce qui aboutit à une exécution du test avec plusieurs cas de test. 10 La figure 49 montre une séquence de test exécutable. Les deux premières étapes de test résultent des instances d'une spécification de test représentées à droite. À partir de l'InterfaceElement présentant la ValueCondition ExactlyValue et du ValueElement est produite une consigne, et à partir de la durée une instruction Wait. Ce processus de mappage peut être automatisé en étendant un outil de test par une fonctionnalité import qui réaliserait le 15 mappage des éléments de la spécification de test sur les éléments de test spécifiques à l'outil. Cette normalisation d'un format pour une spécification de test serait un progrès important. Chaque outil de test pourrait alors être étendu par une fonctionnalité import pour ce format standard et ne devrait réaliser que le mappage des éléments de spécification de test normalisés sur les éléments spécifiques à l'outil. Sans une telle normalisation, tous les outils 20 qui fournissent une spécification de test comme sortie utiliseraient un autre format. Un outil de test nécessiterait une fonctionnalité import propre à chaque format. Tous les formats qui ne seraient pas supportés par un outil de test ne pourraient pas être importés, ce qui aurait pour conséquence un traitement manuel. Un format normalisé pour une spécification de test ouvre une nouvelle perspective d'avenir. La figure 50 montre la chaîne complète allant d'une 25 exigence à l'implémentation d'un test qui serait rapidement entièrement automatisée par une spécification de test normalisée. Les informations indiquant quels objets d'interface sont mappés sur quelles variables, et quels états représentent quelles valeurs doivent par ailleurs être ajoutées manuellement. Ces informations peuvent par exemple être consignées dans des tableaux, comme le montre la figure 51. 30 Ci-après est présentée la transformation du mappage d'une spécification de test sur une implémentation de test dans l'exemple de l'outil de test AutomationDesk. Cette section a exposé la conception du méta-modèle d'exigence et de spécification de test, 35 ainsi que les règles de transformation par lesquelles une spécification de test peut être générée à partir d'une exigence. Elle a par ailleurs présenté le mappage d'une spécification 2907933 69 de test sur une implémentation de test. Etant donné que le critère le plus important de détermination de la qualité d'un logiciel est l'ensemble des exigences du client satisfaites, les tests basés sur les exigences établis avec cette approche occupent une position élevée dans le cadre de l'assurance de la qualité. L'automatisation réduit le coût de génération des tests. 5 L'approche de la génération de tests basée sur les exigences présentée dans la présente invention est basée sur le langage naturel, pour permettre à l'utilisateur une création intuitive de ses exigences. En même temps, l'utilisation du vocabulaire qui est défini par le méta-modèle d'exigences permet le traitement par machine des exigences. En conséquence, les 10 tests peuvent être générés à partir de ces exigences. Du fait que le méta-modèle d'exigences fournit la spécification de conditions temporelles dans les exigences, les propriétés des systèmes incorporés peuvent être décrites de manière très précises. Le comportement correct des systèmes incorporés dépend souvent de conditions temporelles, de sorte que la modélisation des aspects temporels pour la création d'exigences complètes 15 est nécessaire. Comme déjà exposé, il manque à chacune des approches déjà existantes au moins une des propriétés décrites à ce stade. Du fait de la génération des étapes de test à partir d'une exigence, le test exécutable produit au bout du compte est reproductible par l'utilisateur. La spécification de test, qui contient ces 20 étapes de test, a été conçue pour ne pas être éditable, de sorte qu'aucune information ne peut être modifiée ou affinée. Ceci parce qu'une spécification de test éditable entraînerait une incohérence entre l'exigence et la spécification de test. La spécification de test doit décrire les étapes de test qui sont nécessaires pour tester l'exigence à partir de laquelle elle a été générée. Si un test doit être décliné, pour que des tests supplémentaires puissent 25 éventuellement être exécutés indépendamment de l'exigence, il serait souhaitable de créer directement d'autres spécifications de test, et de produire à partir de là des programmes de test exécutables. Un autre concept qui offrirait la possibilité de générer des spécifications de test indépendamment d'une exigence ouvre une nouvelle perspective d'avenir. 30 Ci-après est présenté un prototype qui répond aux concepts exposés et montre donc la possibilité d'application pratique Dans le cadre de la présente invention, on a développé un prototype de génération automatisée de tests à partir d'exigences, qui est la transposition du concept décrit. Le 35 prototype offre une interface utilisateur graphique pour la formulation des exigences à partir du vocabulaire proposé. L'utilisateur présente l'exigence sous la forme du langage naturel, 2907933 tandis qu'en arrière-plan se trouve une instance du méta-modèle pour la définition de l'exigence. Pour montrer à l'utilisateur ce qui sera testé à l'aide de son exigence, on effectue un mappage du modèle d'exigence sur une instance du méta-modèle de spécification de test. Cette spécification de test apparaît sur l'interface utilisateur à nouveau sous la forme du 5 langage naturel. Pour terminer la chaîne allant de l'exigence au test concret, on génère à partir de la spécification de test un test exécutable qui peut être exécuté sur un outil de test. Comme exemple est présenté l'outil de test AutomationDesk, après quoi est décrit le processus allant d'une spécification de test au déroulement d'un test sur l'outil AutomationDesk. 10 Le prototype a été créé sous la forme d'une application Java dans l'environnement de développement Eclipse. Le choix du langage de programmation Java est motivé par son indépendance de la plateforme. Ce qui a pour avantage que l'exécution d'applications développées sous Java n'est pas liée à un système d'exploitation spécial. L'environnement de 15 développement Eclipse ne se contente pas d'être un environnement d'implémentation confortable. Dans le cadre des projets Open Source ont été développés de nombreux plugins Eclipse qui constituent des programmes supportant les défis les plus divers en matière de techniques de programmation. Le plugin Eclipse Omondo est utilisé pour la modélisation graphique de diagrammes UML ainsi que pour la génération automatique de codes à partir de 20 ces derniers. Pour le développement de la présente invention, Omondo a été utilisé pour la modélisation des méta-modèles qui ont déjà été décrits. Le développement d'un éditeur graphique comprend, outre les fonctions spécifiques à l'application, des opérations standard telles que par exemple sauvegarder, enregistrer, 25 annuler et rétablir, et est très coûteux. Pour qu'il ne soit pas nécessaire de développer à nouveau ces opérations standard pour chaque éditeur, ainsi que pour que soit supporté l'ensemble du développement d'un éditeur graphique, on a développé l'Eclipse Modeling Framework (EMF) et le Graphical Editor Framework (GEF). Ils offrent la possibilité de créer à moindre effort un éditeur graphique qui repose sur un modèle formel. À la base se trouve 30 l'architecture Model View Controller (MVC). Les éléments d'un modèle formel sont présentés à l'utilisateur sous la forme d'éléments graphiques (affichage). Les graphiques peuvent être modifiés. Le Controller a pour tâche de transférer les modifications au modèle, et de faire faire une nouvelle présentation des composants graphiques en conséquence. 35 EMF offre la possibilité de créer des modèles. À partir d'un tel modèle, EMF peut générer automatiquement des codes Java qui servent de base pour toute application Java [MDG+04]. 2907933 71 Un modèle produit en utilisant EMF constitue le modèle dans l'architecture MVC. GEF est un framework permettant la création d'un éditeur graphique. On dispose ainsi des opérations standard, de sorte que le développeur de l'éditeur n'a pas à produire les 5 fonctionnalités telles que l'enregistrement d'un modèle graphique. Le code modèle déjà développé par EMF est intégré dans l'éditeur GEF et forme ainsi une base pour l'implémentation de l'éditeur. Mais pour obtenir un éditeur complet, le code Java du modèle EMF doit encore être complété. Pour les éléments présents dans le modèle doivent être prévus des éléments graphiques qui représentent de manière appropriée pour l'utilisateur les 10 parties du modèle existant. Ces éléments graphiques forment l'affichage. Par ailleurs, il faut implémenter les fonctionnalités que l'utilisateur peut exécuter avec les graphiques. Pour l'affectation par l'utilisateur d'un identificateur textuel à un élément graphique, il faut par exemple implémenter un dialogue dans lequel l'utilisateur peut entrer un texte. 15 Pour la liaison entre l'afficheur et le modèle, il faut définir pour chaque élément du modèle quel élément graphique il représentera (controller). L'utilisateur peut ainsi exécuter au moyen des fonctionnalités les opérations des éléments graphiques sur les éléments des modèles. Les modèles volumineux entraînent donc des frais élevés d'implémentation lorsqu'ils sont 20 destinés à être utilisés pour un éditeur. Pour combler cette faille entre EMF et GEF, le Merlin Generator offre la fonctionnalité qui permet de générer un éditeur GEF à partir d'un modèle basé sur EMF [Ani05]. Cet éditeur peut être étendu et adapté individuellement. Il contient pour chaque classe du modèle un objet graphique, et pour chaque association entre deux classes une liaison avec laquelle les deux objets de cette classe peuvent être liés. Les 25 objets et associations peuvent être tirés-déposés dans une surface par drag and drop à partir d'un menu et les opérations disponibles peuvent être appliquées. Dans le cadre de la présente invention, l'éditeur graphique doit être conçu différemment. Les éléments du méta-modèle d'exigences doivent être présentés à l'utilisateur sous la forme de 30 modules de texte. Un libre choix des modules de texte, et la liaison entre les modules de texte, n'offrent dans ce cas en rien à l'utilisateur une assistance suffisante pour formuler une exigence. L'ordre dans lequel les modules de texte peuvent être agencés pour produire une structure de 35 phrase correcte ne serait pas prescrit dans un tel concept. L'utilisateur aurait la possibilité de lier tous les modules de texte comme ils le sont dans le modèle, de sorte qu'il produirait une 2907933 72 structure arborescente. Il pourrait alors commencer par tout module de texte existant. Le méta-modèle d'exigences définit la correspondance entre une classe et une autre par des relations partie-tout. Les associations sont donc orientées, de sorte que les classes reçoivent un ordre. Les classes sont agencées dans le modèle de telle manière que l'ordre 5 définit comment les modules de texte seront agencés dans une phrase grammaticalement correcte. Il est souhaitable de communiquer ces informations en tant qu'aide à l'utilisateur. Ce qui peut être rendu possible en n'offrant pour sélection dans un menu que les modules de texte qui peuvent être attachés à la phrase de manière grammaticalement correcte. L'objectif est en outre un éditeur générique qui traite les classes effectivement présentes 10 dans le méta-modèle, de sorte qu'une modification ou une extension du méta-modèle entre automatiquement dans l'éditeur. Étant donné qu'un éditeur GEF produit au moyen du Merlin Generator ne suffit pas pour les exigences nécessaires dans la présente invention, on a créé un éditeur spécifique sans utiliser ce framework. EMF est toutefois nécessaire pour la modélisation du méta-modèle d'exigences. À partir du méta-modèle, EMF génère un 15 document XML qui est utilisé dans le prototype. À l'éditeur prototype créé dans le cadre de la présente invention ont été fixées les exigences de base suivantes. Le vocabulaire défini par le méta-modèle d'exigences doit être proposé à l'utilisateur sous la forme de modules de texte. La sélection des modules de 20 texte doit permettre à l'utilisateur une formulation simple. Pour qu'il ne soit pas nécessaire d'effectuer des modifications manuelles de l'éditeur après une extension du méta-modèle d'exigences, l'intégration automatique de nouveaux modules de texte constitue un défi digne d'être relevé. 25 Les exigences mentionnées ci-dessus aboutissent à une configuration générique de l'éditeur. Ce qui vent dire que les modules de textes présents pour sélection ne sont pas intégrés fixement dans l'éditeur, mais que l'éditeur traite dynamiquement tous les éléments présents dans le méta-modèle pour en faire des éléments de menu. 30 Ci-après sont décrites les étapes qu'un utilisateur doit accomplir au cours de la création d'une exigence. En même temps sont esquissés les processus que l'interaction de l'utilisateur déclenche dans le prototype. Dans une première étape a lieu la définition de constructions textuelles spécifiques à 35 l'utilisateur, et qui doivent être proposées pour la formulation des exigences. Premièrement, l'utilisateur a besoin d'objets d'interface sous la forme du langage naturel pour la 2907933 73 représentation des interfaces du système auquel l'exigence doit être fixée. En utilisant un objet d'interface dans une exigence, l'utilisateur peut s'adresser à la variable d'une interface pour lui affecter des valeurs. Il faut par ailleurs définir des états qui décrivent les valeurs d'entrée et de sortie des variables. Ceci est illustré ci-dessous à l'aide d'un exemple simplifié 5 sous la forme d'une exigence qui ne présente pas de conditions temporelles pour être plus générale. L'exemple est formulé en anglais du fait que le prototype a été réalisé en utilisant le vocabulaire anglais et que l'exemple peut ainsi être mieux suivi dans le prototype. Exemple : 10 Pour l'exigence If the button 'remote unlock' is pushed then the vehicle is unlocked (si le bouton de déverrouillage à distance est pressé, alors le véhicule est déverrouillé), qui doit être fixée à une fonction de verrouillage centralisé, la surface de commande de la commande à distance portant la désignation the button `remote unlock' décrit un objet d'interface d'un appareil de commande qui participe à la réalisation de la fonction du 15 verrouillage centralisé. Si l'utilisateur appuie sur la surface de commande, à l'objet d'interface est affecté l'état pushed (pressé). L'utilisateur attend comme réaction un véhicule déverrouillé. L'objet d'interface the vehicle (le véhicule) doit recevoir l'état unlocked (déverrouillé). Pour pouvoir décrire une telle exigence, on a besoin des constructions de phrase the button `remote control' et the vehicle en tant qu'objet s 20 d'interface. On a par ailleurs besoin des états pushed et unlocked . Ces constructions de phrase doivent donc être définies par l'utilisateur avant que n'ait lieu la description d'une exigence. La figure 52 est une représentation graphique de l'exigence . La capture d'écran de la figure 53 contient à gauche une liste des constructions de phrase 25 déjà produites pour les objets d'interface. D'autres peuvent être ajoutées en entrant du texte dans le champ situé au dessous et en appuyant sur le bouton add (ajouter). Le bouton remove (supprimer) supprime l'élément mis en évidence dans la liste concernée. À droite se trouve une liste qui fonctionne de la même manière pour la définition des états qui peuvent être affectés aux objets d'interface. Ces constructions de texte déjà produites constituent les 30 éléments de base pour la formulation d'une exigence. Elles sont enregistrées en tant qu'instances des classes InterfaceElement et ValueElement qui ont déjà été présentées. Le méta-modèle et le vocabulaire complété par les entrées de l'utilisateur doivent être proposés à l'utilisateur sous la forme de modules de texte, pour qu'il puisse composer une 35 exigence à partir de ces modules de texte. Ces modules de texte sont générés dynamiquement à partir des éléments du méta-modèle d'exigence. Il s'agit soit d'éléments à 2907933 74 utiliser généralement pour toute exigence, tels que par exemple des opérateurs ou des conditions temporelles, soit d'objets d'interface et d'états définis par l'utilisateur. La sélection de modules de texte dans le vocabulaire donne naissance à une exigence. En arrière--plan est construite pas à pas une instance du méta-modèle. 5 Outre le vocabulaire, le méta-modèle contient des informations sur la structure d'une exigence. Il définit par des associations entre les classes quels éléments doivent être présents et quels éléments peuvent être en relation les uns avec les autres. En conséquence, l'ensemble complet des mots du vocabulaire du méta-modèle n'apparaît pas en même temps 10 à l'utilisateur. Si l'utilisateur pouvait à tout moment sélectionner parmi tous les termes, il risquerait de définir une exigence qui présente une structure qui ne suffirait pas au méta-modèle. Le prototype ne permet de créer que desexigences présentant cette structure. Le prototype ne peut également traiter que des exigences présentant cette structure pour en faire des spécifications de test. 15 Pour concevoir la création des exigences le plus intuitivement possible, on a intégré les modes de comportement humains classiques pendant la construction d'une phrase. Une phrase naît de l'alignement de mots les uns à la suite des autres. Chaque phrase présente ainsi une structure donnée. En anglais, les phrases sont souvent composées du sujet, du 20 prédicat et du complément d'objet. Ces éléments sont également agencés dans cet ordre. En conséquence, le prototype doit proposer les modules de texte dans l'ordre dans lequel ils sont nécessaires pour formuler l'exigence. Le méta-modèle contient les différents éléments permettant de produire une exigence, ainsi que leurs relations les uns aux autres, mais n'indique pas dans quel ordre les éléments doivent être présentés à l'utilisateur. Les 25 informations concernant la forme de la phrase sont en conséquence fournies au prototype par un document XML. Il contient pour tout élément présent dans le méta-modèle une définition concernant sa position à l'intérieur d'une phrase, ainsi que le mappage déjà défini de l'élément sur le langage naturel. La figure 54 montre un extrait de ce document XML. Il y est défini que pour chaque survenance de l'élément AND, le texte and est affiché pour 30 l'utilisateur. Les deux éléments BaseExpressionElement qui sont liés par cet opérateur doivent apparaître à droite et à gauche du texte and . L'élément XML displayOrder de la figure 55 définit que le premier BaseExpressionElement doit être présenté en premier à l'utilisateur. L'élément XML classlnstance indique que doit être affiché ensuite l'élément lui-même, donc l'élément AND. En dernier lieu vient le deuxième BaseExpressionElement. 35 Etant donné que le méta-modèle a été construit de telle manière que tous les éléments 2907933 nécessaires pour une exigence doivent exister dans une instance du méta-modèle, il n'est pas possible qu'une exigence soit spécifiée de manière syntaxiquement incomplète. Toute exigence doit contenir une pré-condition et une réaction attendue. Elles consistent au moins en un InterfaceElement et un ValueElement, de sorte qu'un objet d'interface est toujours 5 décrit par un état qui lui est affecté. Sans ces éléments de base, une exigence serait dépourvue de sens. Il faut en conséquence indiquer à l'utilisateur quels éléments sont absolument nécessaires pour une exigence. Des conditions temporelles sont proposées à l'utilisateur, car elles sont nécessaires pour de 10 nombreuses exigences, mais sont souvent ignorées de l'utilisateur. Dans l'exigence Si le bouton `déverrouillage' de la commande à distance est pressé alors le véhicule est déverrouillé , il manque par exemple des conditions temporelles pour tester un appareil de commande par rapport à cette exigence. Il faudrait définir par exemple pendant combien de temps le bouton doit être pressé pour que le véhicule soit déverrouillé. Il n'est toutefois pas 15 indispensable que des conditions temporelles soient spécifiées, car les conditions temporelles ne sont pas pertinentes pour toutes les exigences. Le prototype offre à l'utilisateur un guide pour la création d'une exigence, en ce qu'il ne propose pour sélection à l'utilisateur que les éléments qui doivent ensuite être produits pour 20 la création d'une instance du méta-modèle. Si l'utilisateur sélectionne un module de texte pour son exigence, il reçoit un nouvel ensemble de modules de texte. Il s'agit de constructions de phrases qui sont dans le modèle les successeurs du module de texte sélectionné. Ces successeurs sont obtenus à l'aide d'un algorithme qui sera présenté ultérieurement. 25 En sélectionnant un module de texte, l'utilisateur peut voir à l'écran à quelle place ce module de texte serait inséré dans la partie déjà créée de l'exigence. La place est marquée par une flèche, comme on le voit sur la figure 55. Cette fonctionnalité de prévisualisation sert à orienter l'utilisateur, et peut l'assister dans le processus qui consiste à décider si l'exigence 30 doit être étendue avec le module de texte sélectionné. À ce moment, l'utilisateur peut encore interrompre l'ajout du module de texte sélectionné en ne plaçant pas ce module de texte dans son exigence. La fonctionnalité prévisualisation peut être activée ou désactivée. La figure 55 montre à l'aide d'un exemple la production d'une exigence. Sur le côté gauche 35 sont rangés les uns à la suite des autres les modules de texte qui ont déjà été sélectionnés par l'utilisateur. Dans cet exemple, ils forment la phrase partielle if the button `remote 2907933 76 control' is pushed then the vehicle is... . À droite on voit le menu. Il contient les éléments qui peuvent être mis par drag and drop à la suite du fragment de phrase déjà existant. Une instance du méta-modèle est produite en arrière-plan à partir des éléments sélectionnés. Pour attacher un nouvel élément à cette instance, il faut déterminer à quel élément le 5 nouveau doit être lié. Etant donné qu'il n'est pas obligatoire de spécifier les conditions temporelles, il est possible de sauter la sélection des modules de texte comportant des aspects temporels. À cette fin est utilisée l'option de menu skip , illustrée sur la figure 56. 10 Pour qu'il ne soit pas nécessaire de produire à nouveau entièrement une exigence si l'utilisateur souhaite remplacer un élément déjà sélectionné par un autre, il est souhaitable de proposer une fonctionnalité répondant à cette fin. Dans cet éditeur générique, l'utilisateur peut sélectionner une construction textuelle, à la suite de quoi il reçoit une liste des éléments qui 15 peuvent prendre la place de l'élément précédemment sélectionné. La figure 57 présente cette liste d'éléments. Le texte locked peut par exemple être remplacé par unlocked . On a déjà décrit la nécessité pour cette invention des opérateurs, et leur conception. Les opérateurs nécessitent un traitement spécial dans l'implémentation, car ils introduisent une 20 autre partie de phrase à l'intérieur d'une exigence. Pendant la production d'une exigence, l'utilisateur peut souhaiter insérer à une place déterminée dans une phrase une autre partie de phrase qui doit être attachée par un opérateur. L'utilisation d'opérateurs est optionnelle. Une autre particularité réside dans le fait que les 25 opérateurs peuvent être utilisés à plusieurs places dans une phrase. En conséquence, la manière dont les opérateurs peuvent être ajoutés diffère de la spécification des autres éléments. Pour utiliser un opérateur, l'utilisateur doit commencer par sélectionner un fragment de phrase auquel l'opérateur doit être attaché. Il le fait en mettant en évidence la partie de phrase souhaitée. Les opérateurs ne pouvant pas être attachés à n'importe seul élément, 30 seuls sont grisés les éléments concernés qui font partie de la partie de phrase à laquelle l'opérateur doit être attaché. L'opération de mise en évidence fait apparaître en bas à droite un autre menu qui contient la liste des opérateurs possibles. La figure 58 présente une exigence entièrement produite. Elle doit être étendue par une nouvelle partie de phrase. Les modules de texte mis en évidence en gris forment la partie de phrase à laquelle la nouvelle 35 doit être attachée par un opérateur. On voit en bas à droite le menu Operator. Une fois qu'un module de texte Operator a été sélectionné, il s'attache à la partie de phrase mise en 2907933 évidence. Mais en interne, un opérateur n'est pas attaché à l'InterfaceElement qui est représenté par une partie des éléments mis en évidence mais est attaché avant cet InterfaceElement an 5 raison de la structure du méta-modèle d'exigence, de sorte que les associations doivent être actualisées. La figure 59 montre une partie de phrase à laquelle sont attachés un opérateur et l'instance correspondante du méta-modèle. L'association entre les éléments Implies et l'élément InterfaceElement a été supprimée et entre les deux a été attaché un opérateur qui présente un association avec ces deux éléments. S'il s'agit d'un opérateur binaire, il doit lier 10 ('InterfaceElement à un autre InterfaceElement ou à un autre opérateur, selon ce que l'utilisateur sélectionne ensuite. Une phrase en langage naturel peut, comme déjà décrit, entraîner des ambiguïtés lorsqu'on utilise plusieurs opérateurs. Étant donné que les exigences présentent une structure univoque 15 du fait du méta-modèle, les exigences peuvent être présentées de manière univoque à l'utilisateur. Ce qui peut se faire par exemple par l'affichage de parenthèses. Dans le prototype, la structure univoque est représentée par la mise en évidence des parties qui se correspondent. 20 La position de l'opérateur dépend de l'opérateur sélectionné. Les opérateurs AND, OR et XOR suivent la fin de la partie de phrase mise en évidence. L'opérateur NOT est en revanche placé au début des éléments mis en évidence, pour construire la phrase sous la forme la plus correcte possible et pour que l'exigence puisse ainsi être lue comme une phrase normale. Sur la figure 60, une exigence a été complétée par un opérateur NOT. 25 Une fois qu'une exigence a été étendue avec un opérateur il faut, dans le cas d'un opérateur binaire, produire une autre partie de phrase. À cette fin, le menu en bas à droite présente pour sélection les éléments qui ont été définis comme successeurs d'opérateurs dans le méta-modèle. S'il manque à l'exigence des éléments de texte à d'autres places, elle sera 30 complétée par les éléments qui sont proposés dans le menu en haut à droite. Pour produire une exigence l'utilisateur reçoit en premier lieu des modules de texte, avec lesquels il peut commencer une exigence. Comme déjà décrit, il s'agit des éléments Iff et Implies, qui constituent des spécialisations de la BaseExpression. Après la sélection de ce 35 module, on détermine à l'aide du méta-modèle quels modules de texte peuvent être attachés à l'élément déjà sélectionné. La détermination des constructions textuels les plus proches 77 2907933 78 possibles se fait en utilisant un algorithme qui découle dans le méta-modèle de l'élément effectivement sélectionné, pour une détermination la plus proche possible. Le méta-modèle d'exigence a été modélisé en utilisant un diagramme UML dans le framework 5 EMF. EMF produit à partir d'un diagramme UML un document XML qui représente le contenu du diagramme. Ce document XML forme la base sur laquelle l'algorithme agit. Au moyen de l'algorithme, le document XML est balayé par classes. L'algorithme, qui est représenté sur la figure 51 sous la forme d'un pseudo-code, est décrit ci-après. 10 La fonctionnalité de base de l'algorithme consiste à parcourir le méta-modèle d'exigences pour trouver pour l'utilisateur un ensemble d'éléments dans lequel il devra sélectionner l'élément suivant de l'exigence. Le point de départ est formé par le dernier élément sélectionné, qui est appelé sur la figure 61 chosenElement . Au début de la définition d'une exigence l'algorithme fonctionnera avec une réalisation concrète de l'élément BaseExpression 15 comme point de départ, du fait qu'à ce moment-là n'existe encore aucun élément sélectionné. Un élément de type BaseExpression définit la structure de base de l'exigence et forme le début de la phrase. La description formelle ci-dessous définit l'algorithme : Admettons que V est l'ensemble de toutes les classes du méta-modèle, et E c V x V 20 l'ensemble de toutes les associations. Deux classes a, b E V présentent une association si (a, b) E E. Dans ce cas, a représente la classe source et b la classe cible. Il s'agit donc d'associations unidirectionnelles. Par ailleurs, a load ail charger les exigences créées dans le prototype, de sorte qu'il reçoit une liste de toutes les exigences. Dans cette liste doit être sélectionnée une exigence, qui est présentée à l'utilisateur en langage naturel. 35 L'exécution de la séquence de menu Testspecification ù> create déclenche la transformation déjà décrite de l'exigence sélectionnée en une spécification de test. Des 2907933 82 instances des éléments du méta-modèle de spécification de test sont produites et liées par associations, de sorte qu'on obtient une instance de l'ensemble du méta-modèle de spécification de test. La transformation est conforme aux règles de transformation présentées. La spécification de test est également représentée en langage naturel. Du fait que les étapes 5 de test décrites dans la spécification de test se déroulent successivement, elles sont exécutées les unes après les autres. Les étapes devant être exécutées en parallèle sont annoncées par l'expression parallel et rendues identifiables par indentation. La figure 65 montre la liste de toutes les exigences, qui présente l'exigence en langage naturel et la spécification de test générée. 10 La spécification de test générée peut être enregistrée au format XML. XML a été choisi comme format de mémoire parce qu'un document XML est compréhensible par les gens du fait de la structuration du langage XML et d'une désignation bien pensée des éléments XML. Du fait qu'il existe des parsers pour XML, la spécification de test au format XML peut être lue 15 et traitée ultérieurement. Pour produire un test exécutable à partir d'une exigence il faut, après le mappage de l'exigence en spécification de test, une conversion pour l'implémentation du test. Dans cette section est présenté le langage de description de test TestML, ainsi que l'outil 20 d'automatisation de test AutomationDesk. On décrira ensuite le mappage des différents éléments de la spécification de test sur les éléments de l'implémentation de test, ainsi que le test AutomationDesk concret Le langage de description de test TestML a été développé dans le cadre du projet IMMOS. 25 L'automatisation croissante des processus de développement dans l'industrie automobile a donné naissance à divers outils de test qui sont utilisés pour assistance. Le renforcement de la collaboration entre les entreprises et leurs sous-traitant fait que le développement et les tests d'un appareil de commande s'étendent à plusieurs entreprises qui utilisent des outils de test différents. Ce qui empêche un développement intégré des tests et l'échange de scénarios 30 de test entre entreprises, car tous ces outils peuvent ne pas supporter les mêmes formats de fichiers. Le projet IMMOS vise donc entre autres à combler les écarts entre les différents outils de test. TestML fournit pour la description de test un format d'échange basé sur XML, dépassant l'outil, 35 pour en finir avec les entraves technologiques qui résultent de l'hétérogénéité des outils. Les outils de test peuvent être étendus par des fonctions import et export qui effectuent un mappage 2907933 83 entre une notation spécifique à l'outil de test et TestML. Cette solution permettra de continuer à utiliser dans l'avenir les outils existants, avec pour fonctionnalité supplémentaire la possibilité d'échanger les tests, et donc de les réutiliser. 5 L'outil AutomationDesk simplifie les tests automatisés et basés sur des modèles des logiciels des appareils de commande. Une interface utilisateur graphique permet à l'utilisateur un maniement intuitif. À l'aide d'AutomationDesk, il est possible de spécifier des déroulements de test qui sont construits comme des diagrammes d'activités UML. Cet outil fournit entre autres une bibliothèque avec laquelle il est possible d'accéder à des plateformes de test basées sur le 10 matériel. À cette fin il existe des blocs représentés graphiquement, tels que par exemple Read et Write , qui constituent des éléments nécessaires pour la description de tests. L'affectation d'une valeur à une variable de l'objet de test spécifique à la plateforme constitue par exemple une opération à l'intérieur d'un test. Un bloc de type Write assure cette fonction. Pour la lecture d'une variable de l'objet de test existe par exemple le bloc Read . Ces blocs 15 peuvent être regroupés en séquences par drag and drop. L'affectation des blocs aux variables de l'objet de test permet une exécution automatique du test sur l'objet de test. Pour obtenir un test exécutable, il faut convertir la spécification de test générée à partir de l'exigence en une implémentation de test concrète. L'outil d'automatisation de test 20 AutomationDesk peut être étendu par une fonctionnalité import qui produit une implémentation de test à partir d'une spécification de test. Pour le format TestML, une fonctionnalité import a été créée en mode test dans AutomationDesk, de sorte que le mappage du langage TestML sur une implémentation de test peut s'exécuter automatiquement dans AutomationDesk. 25 Mais la spécification de test décrite dans la présente invention contient des éléments qui ne peuvent pas être exprimés avec TestML. En font partie par exemple l'existence d'une parallélité. TestML a dû être étendu pour qu'il constitue une passerelle entre la spécification de test et l'implémentation de test. Le prototype relatif à la présente invention offre une fonctionnalité d'enregistrement de la spécification sous un format XML. 30 La figure 66 présente les prototypes qui fournissent comme sortie une spécification de test au format XML, et l'outil de test AutomationDesk contenant la fonctionnalité import pour TestML. Un mappage manuel entre le format XML de la spécification de test et TestML reste nécessaire, pour terminer la chaîne allant de l'exigence à l'implémentation du test. Pour 35 arriver à une automatisation complète de ce processus, il serait très intéressant de développer un format standard pour une spécification de test, et d'étendre chaque outil de test 2907933 84 par une fonctionnalité import pour ce format standard. Une autre possibilité serait d'étendre TestML de sorte que tous les éléments de la spécification de test puissent être exprimés en TestML. Dans ce cas, le prototype pourrait être modifié pour qu'il convertisse la spécification de test en TestML. 5 Comme déjà décrit, les tests sont décrits dans AutomationDesk par des étapes de test sous forme de blocs qui forment ensemble une séquence de test. La figure 67 montre une spécification de test, ainsi que l'implémentation correspondante, sous la forme d'une séquence de test. Elle a été créée manuellement en raison des éléments manquants dans 10 TestML. Cette séquence commence par le chargementd'informations relatives à l'objet de test, par exemple les variables. Les informations sont en même temps chargées vers la plateforme de test. Les blocs qui accèdent à la plateforme sont ensuite initialisés. La spécification de test montrée sur la figure 67 est mappée sur les blocs dans AutomationDesk. Une affectation d'un état à un objet de test dans la partie stimulus de la spécification de test 15 est mappée sur un bloc Write. L'objet d'interface the button `remote control' est mappé sur la variable remote_unlock et l'état pushed est exprimé par la valeur 1 . Une affectation d'un état à un objet d'interface de la partie référence de la spécification de test entraîne la lecture de la variable correspondante de l'objet de test et la comparaison de la valeur lue avec la valeur attendue qui est représentée par cet état. 20 Les opérateurs AND et OR de la spécification de test entraînent des implémentations différentes du comportement du test. Dans l'exemple de la figure 67, il y a un une opération AND dans la partie référence. Ce qui aboutit à un test qui vérifie si les expressions liées sont toutes deux vraies. Le test n'est passé avec succès que si les deux expressions sont 25 satisfaites. Si en revanche un opérateur OR est utilisé dans la spécification de test, une expression satisfaite suffira à fournir un test passé avec succès dans l'implémentation de test. Dans cette section a été présentée la procédure par laquelle l'utilisateur crée une exigence à l'aide du prototype, et peut à partir d'elle générer une spécification de test. Simultanément ont 30 été présentés les principaux aspects de l'implémentation. Après avoir exposé le mappage d'une spécification sur un test concret par l'exemple de l'outil de description de test AutomationDesk, nous poursuivons ci-après avec des exemples d'application. On trouvera dans la présente section des exemples à l'aide desquels sont illustrées les 35 possibilités d'application de la génération automatique de tests. Chaque exemple commence avec une exigence pour laquelle la spécification de test a été générée par le prototype. Suit le 2907933 mappage de la spécification sur les étapes BaseExpression test BaseExpression l'outil BaseExpression test AutomationDesk. Les étapes de test forment ensemble une séquence de test. Cette séquence de test constitue le test exécutable. 5 Les exigences s'en tiennent à l'exemple déjà utilisé, et décrivent donc la fonctionnalité d'un verrouillage centralisé. Chaque exigence vise à montrer l'utilisation d'éléments spéciaux dans le prototype. La première exigence ne contient que les éléments absolument indispensables, les objets d'interface et les états. Dans les autres exemples sont ajoutés les conditions temporelles, les opérateurs et les dépendances relatives. 10 L'expression le véhicule est verrouillé est utilisée comme synonyme de toutes les portes sont verrouillées . Si toutes les portes sont verrouillées, il sera également toujours vrai qu'une porte est verrouillée. 15 Le premier exemple d'exigence montre le cas le plus simple pour une exigence. Il utilise exclusivement les objets d'interface et les états, qui sont absolument indispensables dans une exigence. L'exigence décrit que le véhicule doit être déverrouillé si on a tout d'abord appuyé sur le bouton `déverrouillage' de la commande à distance. 20 Exigence : If the button ,remote unlock' is pushed then the vehicle is unlocked (si le bouton déverrouillage à distance est pressé, 25 alors le véhicule est déverrouillé). La spécification de test montre l'étape de test d'un test qui vérifie l'exigence. La pré-condition est que le bouton `déverrouillage' de la commande à distance soit mis dans l'état pressé. À la suite de quoi on s'attend à ce que le véhicule soit déverrouillé. C'est ce qu'il faut vérifier. 30 Spécification de test : Set the button , remote unlock' to pushed. Check if the vehicle is unlocked . (Mettre le bouton déverrouillage à distance sur pressé. 35 Vérifier si le véhicule est déverrouillé) 2907933 86 La figure 68 montre la séquence de test qui contient dans AutomationDesk les étapes de test de la spécification de texte. Les objets d'interface décrits textuellement, the button `remote unlock' et le véhicule sont mappés sur les variables spécifiques à la plateforme remote_unlock et door status . A également lieu un mappage des états pushed 5 et unlocked sur les valeurs 2 et 0 . Au début de la séquence de test, les variables et la plateforme, par exemple MATLAB /Simulink ou une carte processeur, sont initialisés. Pour exécuter l'étape de test Set the button `remote control' to pushed , on utilise un bloc Write, avec lequel est fixé 10 remote_unlock = 2 . La variable door status est lue par un bloc Read et sa valeur est ensuite vérifiée. Le test est passé avec succès si la valeur est de 0 , puisqu'il s'agit de la valeur attendue. Dans cet exemple sont ajoutées des conditions temporelles. Le bouton `déverrouillage' de la 15 commande à distance doit être pressé au moins pendant 500 millisecondes (durée). Comme réaction on s'attend à ce que l'éclairage intérieur du véhicule s'allume après 100 millisecondes pendant au moins 10 000 secondes (durée). Exigence : 20 If the button `remote unlock' is pushed for at least 500 milliseconds, then the light inside is on after 100 milliseconds for at least 10000 milliseconds . (Si le bouton deverrouillage à distance est pressé pendant au moins 500 millisecondes, alors l'éclairage intérieur est allumé après 100 millisecondes pendant au moins 10 000 millisecondes.) 25 La spécification de test montre les étapes de test ci-dessous, qui sont nécessaires pur la vérification de l'exigence. Au bouton `déverrouillage' de la commande à distance est affecté l'état pressé. On attend ensuite au moins 500 millisecondes, du fait que la pré-condition doit s'appliquer pendant cette durée. Un autre temps d'attente de 100 millisecondes découle du 30 fait que la réaction attendue doit se produire après ces 100 millisecondes. On vérifie pendant au moins 10 000 millisecondes que l'éclairage intérieur est allumé. Spécification de test : Set the button `remote unlock' to pushed. Wait 35 at least 500 milliseconds. Wait 100 milliseconds. 2907933 87 For at least 10000 milliseconds Check if the light inside is on . (Mettre le bouton de déverrouillage à distance sur pressé. Attendre au moins 500 millisecondes. Attendre 100 millisecondes. 5 Pendant au moins 10 000 millisecondes Contrôler si l'éclairage intérieur est allumé.) La séquence de test dans AutomationDesk commence sur la figure 69 comme dans le premier exemple par l'initialisation de la plateforme et des variables. La définition de remo- 10 te_unlock = 2 se fait en utilisant un bloc Write. Un bloc Sleep permet l'attente dans AutomationDesk. Il doit exister dans l'implémentation de test une indication temporelle exacte pour une instruction Wait. Les degrés de liberté, tels qu'ils découlent par exemple de conditions temporelles telles que at least 500 milliseconds doivent donc être éliminés. Comme déjà décrit, les conditions temporelles peuvent être représentées par des paramètres 15 dont les valeurs doivent être fixées concrètement pour l'exécution du test. Pour vérifier que l'éclairage intérieur est allumé pendant au moins 10 000 millisecondes, il faut définir à quelle fréquence la variable light inside doit être lue pour vérification pendant ce laps de temps de 10 000 millisecondes. À cette fin est définie une variable nommée 20 fréquence . L'utilisateur doit pouvoir indiquer lui-même la fréquence. Après la lecture de la variable light inside , il faut attendre 10 000/la fréquence. Les 10 000 millisecondes se répartissent ainsi sur l'étape définie par la fréquence. Cet exemple utilise un opérateur. La pré-condition ne doit plus concerner uniquement 25 l'actionnement du bouton `déverrouillage', mais il faut en plus qu'après 10 000 millisecondes, la poignée de la porte conducteur soit tirée. On s'attend à ce que la porte conducteur soit ensuite ouverte. Exigence 30 If the button `remote unlock' is pushed for at least 500 milliseconds and the outside driver door handle is pulled after 10000 milliseconds then the driver door is open . (Si le bouton de déverrouillage à distance est pressé pendant au moins 500 millisecondes et la poignée extérieure de la porte du conducteur est tirée après 10 000 millisecondes, alors la 35 porte du conducteur est ouverte.) 2907933 88 La spécification de test contient l'instruction selon laquelle l'étape de test doit être exécutée parallèlement. Les deux parties décrites ci-dessus de la pré-condition sont effectuées parallèlement, et liées l'une à l'autre par l'opérateur AND. On vérifie ensuite si la porte conducteur est ouverte. 5 Spécification de test : parallel: Set the button ,remote unlock' to pushed. Wait at least 500 milliseconds. 10 and Wait 10000 milliseconds. Set the outside driver door handle to pulled. Check if the driver door is open . (parallèle : 15 Mettre le bouton de déverrouillage à distance sur pressé. Attendre au moins 500 millisecondes. et Attendre 10 000 millisecondes. Mettre la poignée extérieure de la porte du conducteur sur tirée. 20 Contrôler si la porte du conducteur est ouverte.) Dans AutomationDesk, la séquence de test commence, comme montré sur la figure 70, par l'initialisation de la plateforme et des variables. L'instruction parallèle est réalisée par un bloc Parallel qui exécute parallèlement deux blocs Seriel. Les blocs Seriel contiennent les deux 25 instructions de la pré-condition. La variable remote_unlock reçoit la valeur 1 adressée par un bloc Write. L'indication temporelle at least 500 millisecondes doit tout d'abord être concrétisée. Comme déjà décrit, la condition temporelle peut être représentée par un paramètre dont la valeur doit être spécifiée pour l'exécution du test. Comme réglage standard, la valeur du paramètre pourrait être fixée à 500 . Un bloc Sleep réalise l'attente de 500 30 millisecondes. Parallèlement, un bloc Sleep entraîne tout d'abord une attente de 10 000 millisecondes, après quoi un bloc Write est exécuté pour affecter à la variable driver_door_handle la valeur 1 . On lit ensuite la variable driver door status , et on vérifie si elle présente la valeur 1 . 35 Dans cet exemple, il y a une référence temporelle relative entre deux affectations entre les objets et les états. Après avoir appuyé sur le bouton `déverrouillage' de la commande à 2907933 89 distance, on attend que le bouton de porte d'une porte soit mis en position basse. Mais cette réaction attendue n'est pas dépendante dans le temps du maniement de la commande à distance, mais de l'instant du verrouillage effectif du véhicule. Une seconde après qu'une porte a été verrouillée, son bouton de porte doit passer en position basse. 5 Exigence : If the button remote lock is pushed then the door knob is low 1 second after the door is locked (Si le bouton de déverrouillage à distance est pressé 10 alors le bouton de la porte est baissé 1 seconde après que la porte a été fermée) Ce comportement relatif est exprimé dans la spécification de test par l'instruction Wait until the door is locked . 15 Spécification de test : Set the button remote lock to pushed. Wait until the door is locked. Wait 1 second. Check if the door knob is low . 20 (Mettre le bouton de déverrouillage à distance sur pressé. Attendre jusqu'à ce que la porte soit fermée. Attendre 1 seconde. Contrôler si le bouton de la porte est baissé.) 25 La figure 71 montre le déroulement de l'étape de test dans AutomationDesk. L'attente du verrouillage effectif du véhicule est modélisée par un bloc While. Il est exécuté jusqu'à ce que l'évènement qu'on attend se produise, À l'intérieur du bloc Write est lue la variable door lock status . Cette opération est répétée tant que cette valeur spécification de test réduit la consommation de temps. Par ailleurs, les exigences 20 peuvent être spécifiées de manière plus complète, étant donné que sans l'assistance d'un outil, l'ajout de conditions temporelles risque d'être oublié. La possibilité d'utilisation intuitive du prototype est porteuse d'un potentiel d'amélioration. Ci-dessous sont récapitulés les concepts exposés et leurs possibilités d'application, et 25 sont présentées les perspectives d'avenir. Dans le cadre de la présente invention un concept a été créé qui permet la spécification formelle d'exigences en langage naturel et la génération automatique de tests sur la base de ces exigences. 30 Pour à la fois permettre à l'utilisateur de créer une exigence sous la forme du langage naturel, et obtenir une exigence lisible par machine, on a formulé un vocabulaire ainsi qu'une syntaxe en utilisant un méta-modèle. Sur la base du méta-modèle, l'utilisateur peut créer une exigence formelle qui lui est toutefois présentée en langage naturel. Il est possible de définir des 35 identificateurs pour les objets d'interface et les états, et d'étendre ainsi le vocabulaire à des termes qui sont spécifiques au système à tester. Le méta-modèle offre la possibilité de 2907933 93 spécifier des conditions temporelles. Grâce la modélisation d'une exigence comportant des conditions temporelles, l'exigence acquiert la précision qui est nécessaire pour tester des systèmes incorporés. 5 Etant donné que le concept du méta-modèle d'exigences a été, comme décrit, modélisé pour qu'il puisse être étendu, des éléments peuvent être ajoutés pour compléter le vocabulaire. Il est par exemple possible d'ajouter des éléments qui permettent de former différentes structures de phrase et qui permettent des emboîtements de constructions si...alors . Comme nous l'avons montré, il est par ailleurs possible d'ajouter un élément avec lequel 10 peuvent être spécifiées des conditions temporelles présentant une autre référence temporelle pour la réaction attendue. On a ainsi créé la possibilité de formuler des exigences dans lesquelles une réaction attendue doit se produire dans le temps parallèlement à la pré-condition, et non après la pré-condition. 15 Une telle exigence est utilisée pour la génération automatique d'un test. Pour présenter les différentes étapes de test à l'utilisateur avant la production d'un test exécutable, on effectue la génération d'une spécification de test. Les étapes de test qui y sont définies montrent comment le système auquel cette exigence a été fixée doit être vérifié. Les règles décrites dans la présente invention pour une transformation du modèle permettent de générer une 20 spécification de test à partir d'une exigence. La production d'un test exécutable à partir d'une spécification de test pour la vérification d'un système incorporé nécessite un mappage des objets d'interface et des états indépendants de la plateforme de test sur les variables et les valeurs de l'objet de test spécifiques à la 25 plateforme. L'implémentation d'un tel test exécutable peut être effectuée dans un outil de test. Les degrés de libertés résultants d'indications temporelles imprécises qui sont encore présents dans la spécification de test doivent être éliminés pour l'exécution du test, pour qu'on puisse y exécuter des instructions concrètes. En conséquence, les indications temporelles doivent être concrétisées avant l'exécution du test. 30 L'automatisation du déroulement allant d'une exigence à un test exécutable réduit la consommation de temps pour la création du test et aide à maintenir la cohérence entre l'exigence et la spécification de test. L'utilisation du langage naturel permet aux utilisateurs ne connaissant pas les méthodes formelles de produire des exigences qui sont lisibles par 35 machine et pourront donc être traitées ultérieurement. La possibilité d'ajouter des conditions temporelles pendant la création de l'exigence contribue à spécifier des aspects temporels qui 2907933 94 risquent d'être oubliés si l'exigence est formulée manuellement. Du fait que les degrés de liberté présents dans les conditions temporelles sont conservés jusqu'à la fin, il est possible d'exécuter le test avec plusieurs cas de test, les valeurs temporelles concrètes variant à l'intérieur de leurs degrés de liberté. 5 Le concept décrit dans la présente invention est basé sur les exigences. Étant donné que la satisfaction des exigences est un critère important pour un logiciel de haut niveau, les tests basés sur les exigences occupent une place importante dans l'assurance de la qualité. Le concept de génération automatique de tests exécutables à partir des exigences comble une 10 lacune à l'intérieur de processus de test, qui est de plus en plus automatisé. Il apporte une valeur ajoutée élevée, du fait que le coût de la création des tests peut être considérablement réduit par l'automatisation. La possibilité d'application du concept dans la pratique a été montrée à l'aide d'un prototype. Les résultats de l'évaluation font apparaître que l'automatisation de la génération de tests à partir d'exigences en langage naturelle permet un 15 gain de temps à l'intérieur du processus de test. Étant donné que les tests représentent une part importante du coût de développement, la baisse du coût du développement des tests des systèmes incorporés rend le processus de développement plus rentable. Bien qu'il permette de passer d'une exigence à une implémentation de test, le concept décrit 20 dans la présente invention offre la possibilité d'être encore étendu. La spécification de test générée automatiquement à partir de l'exigence existe dans un format qui a été adapté à la spécification de test conceptualisé dans la présente invention. Pour qu'un test exécutable puisse être produit automatiquement à partir d'une spécification de test, on a besoin d'une fonctionnalité import dans l'outil de test dans lequel le test est exécuté. Comme déjà montré, 25 la normalisation d'un format pour une spécification de test serait une bonne solution. Le langage de description de test TestML pourrait être étendu à différents éléments et devenir ainsi une norme. Comme autre perspective il convient de mentionner un concept avec lequel on produit 30 différents cas de test qui sont proposés pour sélection à l'utilisateur au moment d'effectuer le test exécutable. Les degrés de liberté des conditions temporelles permettent de réaliser des tests ayant des valeurs temporelles concrètes différentes. Si une exigence contient dans la pré-condition la condition temporelle au moins 4 secondes , on peut tester si : 1. la réaction attendue se produit si la pré-condition est remplie pendant au moins 4 35 secondes, 2. ou si la réaction attendue se produit aussi si la pré-condition est remplie pendant 5 2907933 secondes ou plus. Différentes combinaisons de différentes valeurs d'entrée aboutissent également à plusieurs cas de test. Il existe de nombreuses approches pour la production des cas de test possibles, 5 par exemple dans les documents [CTFO1, HuOO]. Il est possible d'étudier s'il existe une approche qui fournit un concept approprié pour être intégré dans la présente invention. Les exigences existent souvent tout d'abord sous la forme du langage naturel. Étant donné que la capacité d'expression verbale des gens est en générale plus fiable et plus riche dans leur 10 langue maternelle, les exigences formulées dans la langue maternelle présentent un moindre risque d'erreur. Le concept de création d'exigences en langage naturel dans différentes langues constitue donc une perspective à laquelle la présente invention pourrait être étendue. Mais de nombreuses langues présentent des propriétés toutes autres que celles de l'anglais utilisé dans la présente invention en termes de structure de phrase et de grammaire. La 15 possibilité d'une transposition du concept de la présente invention à des langues présentant des caractéristiques différentes est porteuse d'un important potentiel de recherche. Mais les exigences ne sont pas décrites exclusivement à l'aide du langage naturel, et sont souvent complétées par d'autres formes de représentation. Il est fréquent qu'on établisse des 20 graphiques ou qu'on insère des vues sous forme de tableaux. Par ailleurs, des notations formelles telles que les automates d'état précisent les exigences textuelles. En combinant la description des exigences sous forme de langage naturel et différentes autres notations,il est possible de concevoir la possibilité d'expression de manière plus large. Il demeure un potentiel de recherche pour formaliser les exigences à partir de notations combinées pour une 25 génération automatique des tests. 2907933 Bibliographie [ACD93] Rajeev Alur, Costas Courcoubetis, and David L. Dill. Model-Checking in Dense Real-time. Information and Computation, 104(1):2-34, 1993. 5 [Ani05] Chris Aniszczyk. Using GEF with EMF. Eclipse Corner Articles, January 2005. [Ba198] Helmut Balzert. Lehrbuch der Softwaretechnik. Spektrum Akademischer Verlag, 1998. [BNO3] Bart Broekman and Edwin Notenboom. Testing Embedded Software. Addison-Wesley, 2003. 10 [BvdBK98] Manfred Broy, Michael von der Beeck, and Ingolf Kruger. SOFTBED: Problemanalyse fur das GroBverbundprojekt "Systemtechnik Automobil - Software fur eingebettete Systeme". In Ausarbeitung fur das BMBF, 1998. [CES86] Edmund M. Clarke, E. Allen Emerson, and A. Prasad Sistla. Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications. ACM 15 Trans. Program. Lang. Syst., 8(2):244-263, 1986. [CGP00] Edmund M. Clarke, Orna Grumberg, and Doron A. Peled. Model Checking. MIT Press, Cambridge, MA, 2000. [CLL97] Chin-Liang Chang, Richard C. Lee, and Richard Char-Tung Lee. Symbolic Logic and Mechanical Theorem Proving. Academic Press, Inc., Orlando, FL, USA, 1997. 20 [CLRS01] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. Introduction to Algorithms. The MIT Press, September 2001. [CSWO6] Mirko Conrad, Sadegh Sadeghipour, and Hans-Werner Wiesbrock. Automatic Evaluation of ECU Software Tests. In Proceedings of the SAE 2005 World Congress, page 583, Detroit, USA, April 2006. Software Quality Research Lab, 25 McMaster Univeristy, Hamilton, Canada. SAE Techn. Paper No. 2005-01-1659. [CTF01 ] Philippe Chevalley and Pascale Th'evenod-Fosse. Automated Generation of Statistical Test Cases from UML State Diagrams. compsac, 00:205, 2001. [Dij70] Edsger W. Dijkstra. Notes on Structured Programming. Forschungsbericht 30 EWD249, April 1970. [EMSS91] E. Allen Emerson, Aloysius K. Mok, A. Prasad Sistla, and Jai Srinivasan. Quantitative Temporal Reasoning (Extended Abstract). In E. M. Clarke and R. P. Kurshan, editors, Computer-Aided Verification: Proc. of the 2nd International ConferenceCAV'90, pages 136-145. Springer, Berlin, Heidelberg, 1991. 35 [FMR00] Stephan Flake, Wolfgang Müller, and Jurgen Ruf. Structured English for Model Checking specification. In GI-Workshop Methoden und Beschreibungssprachen 96 2907933 97 zur Modellierung und Verifikation von Schaltungen und Systemen in Frankfurt, Berlin, 2000. VDE Verlag. [FP05] Mario Friske and Holger Pirk. Werkzeuggestützte interaktive Formalisierung textueller Anwendungsfallbeschreibungen für den Systemtest. In A. B. Cremers, P. 5 Manthey, P. Martini, and V. Steinhage, editors, Beitrâge der 35. Jahrestagung der Gesellschaft für Informatik e.V. (Band2), Bonn, 19. bis 22. September 2005., volume 68 of LNI, September 2005. [FriO4] Mario Friske. Testfallerzeugung aus Use-Case-Beschreibungen. Softwaretechnik-Trends, 24(3), August 2004. 21. Treffen der Fachgruppe 2.1.7 Test, Analyse und 10 Verifikation von Software (TAV) der Gesellschaft für Informatik (GI). [FS05] Mario Friske and Holger Schlingloff. Von Use Cases zu Test Cases: Eine systematische Vorgehensweise. In T. Klein, B. Rumpe, and B. Schâtz, editors, Tagungsband Dagstuhl-Workshop MBEES: Model Based Engineering of Embedded Systems, number 2005-01 in Informatik-Bericht. TU Braunschweig, January 15 2005. [GCF+06] Juergen Grossmann, Mirko Conrad, Ines Fey, Alexander Krupp, Klaus Lamberg, and Christian Wewetzer. TestML - A Test Exchange Language for Modelbased Testing of Embedded Software. In Proceedings of Automotive Software Workshop, March 2006. 20 [GG93] Matthias Grochtmann and Klaus Grimm. Classification Trees for Partition Testing. volume 3 of Software Testing, Verification and Reliability, pages 63-82. 1993. [GHJVO4] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Entwurfsmuster. Addison-Wesley, July 2004. [Gmb99] Robert Bosch GmbH. Kraftfahrtechnisches Taschenbuch. Springer Verlag, 1999. 25 [GraOO] Jens Grabowski. TTCN-3 - A new Test Specification Language for Black Box Testing of Distributed Systems. In Proceedings of the 17th International Conference and Exposition on Testing Computer Software (TCS'2000), Theme: Testing Technology vs.Testers' Requirements, Washington D.C., June 2000, June 2000. 30 [HuOO] Mou Hu. A New Test Design Method for Requirement-Based Software Testing. Beijing, China, August 2000. [IEE90] IEEE. IEEE Standard Glossary of Software Engineering Terminology, December 1990. [iST01] British Computer Society Specialist Interest Group in Software Testing. Standard for software component testing (draft 3.4), April 2001. 35 [KBPO1] Erik Kamsties, Daniel M. Berry, and Barbara Paech. Detecting Ambiguities in Requirements Documents Using Inspections. In Mark Lawford and David L. 2907933 98 Parnas, editors, Proceedings of the First Workshop on Inspection in Software Engineering (WISE'01), pages 68-80, Paris, France, July 2001. Software Quality Research Lab, McMaster Univeristy, Hamilton, Canada. [Ken02] Stuart Kent. Model Driven Engineering. In M. Butler, L. Petre, and K. Sere, 5 editors, Proceedings of the Third International Conference on Integrated Formai Methods (IFM 2002), volume 2335 of Lecture Notes in Computer Science, page 286-298, Turku, Finland, May 2002. Springer Verlag. [Lam06] Klaus Lamberg. Software-Entwicklung: Software-Testen. In H. Wallentowitz and K. Reif, editors, Handbuch Kraftfahrzeugelektronik Grundlagen - Komponenten Systeme -Anwendungen. Vieweg Verlag, Wiesbaden, 2006. [Lig02] Peter Liggesmeyer. Software-Qualitât. Spektrum Akademischer Verlag, 2002. [Lov78] Donald W. Loveland. Automated theorem proving: A Iogical basis. In Fundamental studies in computer science, volume 6, Amsterdam, New York, 1978. North-Holland Publishing Co. 15 [LR05] Peter Liggesmeyer and Dieter Rombach. Software Engineering eingebetteter Systeme. Spektrum Verlag, 2005. [MDA02] The OMG's Model Driven Architecture, January 2002. [MDG+04] Bill Moore, David Dean, Anna Gerber, Gunnar Wagenknecht, and Philippe Vanderheyden. Eclipse Development using the Graphical Editing Framework and 20 the Eclipse Modeling Framework. January 2004. [Obj05] Object Management Group. UML 2.0 Superstructure Specification, August 2005. Document ptc/05-07-04. [ONS06] Rainer Otterbach, Oliver Niggemann, and Joachim Stroop. Software Entwicklung: Entwicklungsprozesse, Methoden und Werkzeuge. In H. Wallentowitz and K. Reif, 25 editors, Handbuch Kraftfahrzeugelektronik Grundlagen - Komponenten - Systeme - Anwendungen. Vieweg Verlag, Wiesbaden, 2006. [Pei] Jan Peleska. Verbesserte Softwarequalitât durch effiziente Testprozesse. Technologie-Zentrum Informatik und Verified Systems International GmbH. Revision: 1.5. 30 [Pnu77] Amir Pnueli. The Temporal Logic of Programs. In Proceedings of the 18th IEEE Symposium on the Foundations of Computer Science, pages 46-57. IEEE, 1977. [Rup04] Chris Rupp. Requirements-Engineering und -Management. Hanser Verlag, 2004. [SACO3] Rachel L. Smith, George S. Avrunin, and Lori A. Clarke. From Natural Language Requirements to Rigorous Property Specification. In Workshop on Software 35 Engineering for Embedded Systems (SEES 2003): From Requirements to Implementation, pages 40-46, September 2003. 2907933 99 [SchOO] Uwe Schüning. Logik für Informatiker. Spektrum-Akademischer Verlag, January 2000. [ThaOO] Georg E. Thaller. Software-Test: Verifikation und Validation. Verlag Heinz Heise, 2000. 5 [WHHO5] Rupert Wiebel, Steffen Hüh, and Stefan Hendrata. Specifiaction Requirements Interchange Format (RIF), 2005. 2907933 Annexe A Mappage des éléments du méta-modèle d'exigences sur la logique temporelle RTCTL 5 Le mappage sur les expressions RTCTL se fait de manière inductive. La notation Iff(precondition, expectedReaction) signifie alors que les instances de l'élément Iff du méta-modèle reçoivent avec les instances des éléments qui ont été obtenus par les associations precondition et expectedReaction la sémantique suivante. Les éléments qui ont été obtenus par les associations présentent à leur tour une définition sémantique. Par les 10 associations precondition et expectedReaction, on obtient par exemple les éléments de type BaseExpressionElement. Les instanciations concrètes de cet élément sont AND, OR, XOR, NOT, et InterfaceElement, dont la sémantique est définie. De l'ensemble des définitions découlent ensuite les formules RTCTL. 15 • BaseExpression - Iff(precondition, expectedReaction) ù> precondition expectedReaction - Implies(precondition, expectedReaction) ù> precondition expectedReaction • BinaryOperator - XOR(childOne, childTwo) ù> (childOne A -1childTwo) v (-1 childOne A childTwo) 20 -OR(childOne, childTwo) ù> childOne v childTwo - AND(childOne, childTwo) ù> childOne A childTwo • UnaryOperator -NOT(baseExpressionElement) - baseExpressionElement 25 Les mappages vers PointOfTime et LengthOfTime d'un élément InterfaceElement ne peuvent pas être effectués indépendamment les uns des autres, car une référence temporelle commune est nécessaire. Pour un InterfaceElement, les mappage se font en conséquence dans son contexte (InterfaceElement(pointOfTime, lengthOfTime, valueCondition) 30 Soient t E N et V la ValueCondition correspondante dans RTCTL qui est formée comme suit : • ValueCondition - AtMostforValue(interfaceElement, valueElement) ù> interfaceElement valueElement 35 - AtLeastforValue(interfaceElement,40 valueElement) ù> 2907933 101 interfaceElement valueElement -ExactlyValue(interfaceElement, valueElement) ù> interfaceElement = valueElement - WithinValue(interfaceElement, lowerValue, upperValue) ù> 5 lowerValue interfaceElement upperValue Du fait que comme déjà décrit, les conditions temporelles de la réaction attendue présentent un point de référence autre que celui qu a été spécifié dans la pré-condition, la sémantique des conditions temporelles est définie différemment pour la pré-condition et pour 10 la réaction attendue. Ci-dessous figure la définition de la sémantique des conditions temporelles dans la pré-condition. • V s'applique à l'instant ExactlyTime(time) pour la durée ExactlyDuration(duration) ù> A(true Uùtime v) A -1E(true U[tme,tme+duraton]_Iv ) -1E(true U>time+durationV) • V s'applique à l'instant ExactlyTime(time) pour la durée AtLeast(duration) ù> 15 A(true Uùtune v) A -1E(true U[tme,tme+duraton]_Iv ) • V s'applique à l'instant ExactlyTime(time) pour la durée AtMost(duration) ù> A(true Uùtune v) A -1E(true U>time+durationV) • V s'applique à l'instant ExactlyTime(time) pour la durée BetweenDuration(lowerDuration, upperDuration) ù> 20 A(true Uùtune v) A-1E(true U[tme,tme+lowerDuraton]_1v ) A-1E(true U>tme+upperDuratonV) • V s'applique à l'instant Soonest(time) pour la durée ExactlyDuration(duration) ù> t time A(ù,V U=tV) n ùiE(true U[t,t+duration]-,V) A-,E(true U>t+durationV) • V s'applique à l'instant Soonest(time) pour la durée AtLeast(duration) ù> t time A(ù, V U-tV) n -1E(true U[t,t+duration]ù1V) >_n 25 • V s'applique à l'instant Soonest(time) pour la durée AtMost(duration) ù> t ~ time A(ù1V UùtV) -1E(true U>t+durationV) • V s'applique à l'instant Soonest(time) pour la durée BetweenDuration(lowerDuration, upperDuration) ù> t ~ time A(ù1V U=tV) n -1E(true U[t,t+lowerDuration]_1V) n -1E(true U>t+upperDurationV) 30 • V s'applique à l'instant NotLaterThan(time) pour la durée ExactlyDuration(duration) ù> t Ç time A(~V U=tV) nùiE(true U[t,t+duration] ~V) nùiE(true U>t+durationV) • V s'applique à l'instant NotLaterThan(time) pour la durée AtLeast(duration) ù> 2907933 102 ttime nA ( V U -tV) n -1E(true U ~`,t+aurarion]~V ) • V s'applique à l'instant NotLaterThan(time) pour la durée AtMost(duration) ù> t Ç time n A(-1V UùtV) n -1E(true U>t+durarionV) • V s'applique à l'instant NotLaterThan(time) pour la durée BetweenDuration(lowerDuration, 5 upperDuration) ù> ttimenA ( V UùtV) n -1E(true U[t,t+lowerDurarion] -1V) n -1E(true U>t+upperDurarionV) • V s'applique à l'instant BetweenTime(lowerTime,upperTime) pour la durée ExactlyDuration(duration) ù> lowerTime t upperTime n A(-1V U-tV) n -1E(true U[t,t+aurarion, -1V) A -1E(true U -dur on 10 • V s'applique à l'instant BetweenTime(lowerTime,upperTime) pour la durée AtLeast(duration) -lowerTime t upperTime n A(-1V U -tV) n -1E(true U ~t,t+aurarion~ù1V ) • V s'applique à l'instant BetweenTime(lowerTime,upperTime) pour la durée AtMost(duration) 15 - lowerTime t upperTime n A(-1V U-tV) n 1E(true U>t+durarionV) • V s'applique à l'instant BetweenTime(lowerTime,upperTime) pour la durée BetweenDuration(lowerDuration, upperDuration) ù> lowerTime t upperTime n A(-1V U-tV) n -1E(true U[ t,t+lowerDurarion] ~V) n -1E(true U>t+upperDurarionV) Les conditions temporelles dans la réaction attendue sont définies comme suit. Admettons 20 que m est le premier instant auquel toutes les conditions de la pré-condition sont closes. L'instant m forme ainsi le point de référence pour les conditions temporelles de la réaction attendue. • V s'applique à l'instant ExactlyTime( m +time) pour la durée ExactlyDuration(duration) ù> A(true Uùm+rime V) n -1E(true U[m+ri ~V) n-1E(true Umm+duarionV) me,m+time +durarion] 25 • V s'applique à l'instant ExactlyTime( m +time) pour la durée AtLeast(duration) ù> A(true U--rime v) A -iE(true U[m+rime,m+time +durarion]ùV) • V s'applique à l'instant ExactlyTime( m +time) pour la durée AtMost(duration) ù> A(true Uùm+ rime V) n -1E(true U>m+rime+durarionV) • V s'applique à l'instant ExactlyTime( m +time) pour la durée 30 BetweenDuration(lowerDuration, upperDuration) ù> A(true U ùm+rime V) n p(t% ue U [m+rime,m+time +lowerDurarion]~V) n ù p(true U >m+rime+upperDurarionV ) • V s'applique à l'instant Soonest( m +time) pour la durée ExactlyDuration(duration) ù> 2907933 103 t ~ m + time A(ùiV U =tV) A ùiE(true U [t,t+duration]ùiV) A ùiE(true U >t+durationV ) • V s'applique à l'instant Soonest( m +time) pour la durée AtLeast(duration) ù> t ~ m + time A(ù1V U=tV) A -1E(true U [t,t+durat on]~ ) • V s'applique à l'instant Soonest( m +time) pour la durée AtMost(duration) ù> 5 t ~ m + time A(ù1V U=tV) -1E(true U't+durationV ) • V s'applique à l'instant Soonest( m +time) pour la durée BetweenDuration(lowerDuration, upperDuration) ù> t ~ m + time A(ù,V U =tV) A ùiE (true U [t,t+lowerDurat on]_1v ) A ùiE(true U't+upperDurat onv ) • V s'applique à l'instant NotLaterThan( m +time) pour la durée ExactlyDuration(duration) 10 ù> t t Ç m + time n A(ù1V U=tV) -1E(true U [t't+duration]ùiV ) • V s'applique à l'instant NotLaterThan( m +time) pour la durée AtMost(duration) ù> t Ç m + time A(ù1V U=tV) -1E(true U >t+durationv ) 15 • V s'applique à l'instant NotLaterThan( m +time) pour la durée BetweenDuration(lowerDuration, upperDuration) ù> t Ç m + time n A(ù1V U ùtV) -1E(true U [t,t+lowerDuration] ùV) A ùE(true U't+upperDurat onV ) • V s'applique à l'instant BetweenTime( m +IowerTime, m +upperTime) pour la durée ExactlyDuration(duration) ù> 20 m + lowerTime t m + upperTime n A(ù1V U=tV) A -1E(true U [t't+duration] -1V) A -1E(true U >t+durationV ) • V s'applique à l'instant BetweenTime( m +IowerTime, m +upperTime) pour la durée AtLeast(duration) ù> m+lowerTime t m + upperTime n A(ù1V U=tV) Aù1E(true U[t't+duration]_1v) • V s'applique à l'instant BetweenTime( m +IowerTime, m +upperTime) pour la durée 25 AtMost(duration) ù> m + lowerTime t m + upperTime n A(ù1V U=tV) n ùE(true U't+dnrarionV ) • V s'applique à l'instant BetweenTime( m +IowerTime, m +upperTime) pour la durée BetweenDuration(lowerDuration, upperDuration) ù> m + lowerTime t m + upperTime 30 n A(ùiV U =tV) n ùiE(true U [t't+lowerDura on] ~V) AùL+(true U>t+upperDurationv) 4 Revendications 1. Procédé pour la création d'une description d'exigences pour un système incorporé, en particulier pour un appareil de commande d'un véhicule, caractérisé en ce qu'on enregistre dans un système de traitement de données un vocabulaire constitué de modules de texte en langage naturel pouvant être sélectionnés, qui peuvent être combinés les uns avec les autres pour former au moins une phrase en langage naturel, notamment en anglais, formant une description des exigences lisible par machine, et en ce que chaque module de texte est lié à un ensemble d'autres modules de texte pouvant y être combiné, le système de traitement de données présentant automatiquement sur une unité d'affichage pour un module de texte sélectionné les autres modules de texte pouvant y être combinés en vue d'une sélection. 2. Procédé selon la revendication 1, caractérisé en ce que les modules de texte sont rangés dans des classes d'un méta-modèle d'exigences enregistré, en particulier dans des classes UML. 3. Procédé selon la revendication 2, caractérisé en ce que pour chaque module de 20 texte sélectionné une instance du méta-modèle d'exigence est complétée par une instance de la classe du méta-modèle d'exigence liée au module de texte. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que chaque module de texte est affecté à une classe d'un méta- modèle d'exigences et en ce que 25 pour chaque classe est enregistrée une information sur au moins une relation et la direction de la relation par rapport à au moins une autre classe, pour que les relations directionnelles forment une séquence de classes qui définit un agencement grammaticalement correct des modules de texte affectés aux classes. 30 5. Procédé selon l'une des revendications précédentes, caractérisé en ce que la liaison et la représentation d'un module de texte sélectionné avec un ensemble de modules de texte pouvant y être combinés se fait par la détermination de la classe qui est affectée, dans le méta-modèle d'exigences, au module de texte sélectionné, puis par la détermination d'au moins une classe qui suit la classe déterminée selon une relation directionnelle, puis par 35 le regroupement des éléments de la au moins une classe suivante déterminée en un 2907933 105 ensemble dont les éléments sont représentés respectivement par les modules de texte affectés, puis par l'affichage de ces modules de texte sur une unité d'affichage, en particulier sous la forme d'options de menu sélectionnables. 5 6. Procédé selon l'une des revendications précédentes, caractérisé en ce que sont affichés des ensembles de modules de texte obligatoires et des ensembles de modules de texte possibles, les ensembles de modules de textes possibles, en particulier ceux qui concernent des conditions temporelles, pouvant être sautés en ne sélectionnant pas de module de texte. 10 7. Procédé selon l'une des revendications précédentes, caractérisé en ce que les modules de texte déjà sélectionnés dans une description des exigences formée peuvent être remplacés par des modules de texte de substitution, ce pour quoi après la sélection d'un module de texte à remplacer est affiché automatiquement à des fins de sélection un ensemble 15 de modules de texte de substitution possibles, le module de texte à remplacer étant automatiquement remplacé par la sélection d'un module de texte de substitution dans l'ensemble affiché. 8. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'après la création d'une description des exigences en langage naturel, le système de traitement des données effectue une transformation par laquelle la description des exigences est convertie en une spécification de test en langage naturel indépendante de la plateforme. 9. Procédé selon la revendication 8, caractérisé en ce que pour la réalisation de la transformation, l'instance du méta-modèle d'exigence formée parallèlement est convertie par une transformation de modèle en une instance d'un méta-modèle de test, ce pour quoi au moins une partie des éléments de l'instance du méta-modèle d'exigence sont transformés en éléments d'une instance du méta-modèle de test, une instance du méta-modèle de test ainsi obtenue étant représentée sur l'unité d'affichage du système de traitement des données sous la forme d'une spécification de test en langage naturel, ce pour quoi aux éléments de l'instance du méta-modèle de test sont affectés des modules de texte en langage naturel. 10. Procédé selon la revendication 8 ou 9, caractérisé en ce que les éléments de l'instance du méta-modèle d'exigence qui décrivent une condition sont transformés en éléments d'une instance du méta-modèle de test qui provoquent l'affectation d'une valeur aux entrées d'un système incorporé, et en ce que les éléments de l'instance du méta-modèle 15 2907933 106 d'exigence qui décrivent une réaction à une condition sont transformés en éléments d'une instance du méta-modèle de test qui vérifie les valeurs des sorties. 11. Procédé selon l'une des revendications 8 à 10, caractérisé en ce que les 5 éléments de l'instance du méta-modèle d'exigence qui décrivent un aspect temporel imprécis sont transformés en éléments de l'instance du méta-modèle de test qui comprennent un degré de liberté temporel pouvant être concrétisé. 12. Procédé selon l'une des revendications 8 à 11, caractérisé en ce qu'un 10 programme de test dépendant de la plateforme est généré à partir de l'instance du méta-modèle de test indépendante de la plateforme. 13. Procédé selon la revendication 12, caractérisé en ce qu'un degré de liberté est concrétisé avant la génération. 14. Produit de programme informatique qui est enregistré sur un support de données et qui met en oeuvre un procédé selon l'une des revendications précédentes lorsqu'il est exécuté sur un système de traitement des données.