<Desc/Clms Page number 1>
"Un appareil de contrôle de logiciels" La présente invention concerne un appareil de contrôle de logiciels d'application.
Dans la description du présent brevet, le terme"contrôle"se rapporte à l'ensemble des opérations de contrôle réalisées avant l'expédition d'un logiciel ou d'un ensemble de logiciels, ce au cours du développement et de l'étape finale de ce développement, de même qu'il se rapporte à la maintenance permanente, au développement et au support du logiciel après l'expédition de celui-ci vers l'utilisateur final.
Plusieurs méthodes spécifiques de contrôle sont connues actuellement, dont une est décrite dans la description du brevet européen nO EP-BI-0286361 (Westinghouse).
Toutefois, un des problèmes auxquels ont été confrontés les ingénieurs de champ d'essai lors du contrôle de logiciels d'application a été d'assurer l'accès à la version la plus récente du logiciel utilisée sur un système destinataire. Fréquemment, il se produit des retards lorsqu'il s'agit d'accéder aux programmes et aux fichiers de données corrects destinés à un système destinataire particulier et des erreurs sont souvent entraînées par l'utilisation d'une version incorrecte de logiciel. Cela peut conduire à une perte de temps considérable, à une perte de revenus et à une perte de confiance des clients. Cela fut particulièrement le cas pour des organisations de développement de logiciels où un grand nombre de logiciels d'application utilisés sur des systèmes destinataires sont développés par l'organisation.
Une façon d'aborder le problème a été d'accéder en mode interactif via le modem au système destinataire et de transmettre les signaux de diagnostic d'erreurs via les lignes de communication. Alors que ce procédé se révèle satisfaisant dans une certaine mesure, il présente des limites quant à la nature du contrôle pouvant être réalisé. Par exemple, il n'est dans certains cas pas pratique de réaliser des contrôles très étendus utilisant de larges volumes de données et de programmes utilisés par les
<Desc/Clms Page number 2>
systèmes destinataires. En outre, cette approche ne permet pas un accès rapide aux programmes et aux données tels qu'ils ont été développés sur le système central dans des situations où différentes pièces de logiciels d'application sont développées.
Les objectifs de la présente invention sont donc de développer un appareil de contrôle de logiciels, lequel : - est capable de fournir un accès presque immédiat à tous les programmes et à toutes les données de contrôle appropriées, ceux-ci étant développés en interne et à distance sur des systèmes destinataires sur site ; - fournit un accès correct aux mises à jour les plus récentes de programmes et de fichiers de données, ce de manière simple et ne requérant que très peu de temps de programmation ; - permet un vaste contrôle dans toutes les situations ; et - assure l'efficacité du contrôle de nouvelles versions de logiciels d'application destinés à être installés sur un grand nombre de systèmes destinataires.
Conformément à la présente invention, il est prévu un appareil de contrôle de logiciels destiné à contrôler un logiciel de système destinataire développé sur un système central, l'appareil comprenant : - un contrôleur d'essai connecté à une mémoire vive ; - une pile de disques durs connectée à un contrôleur de disques comprenant : . un fichier d'instructions de contrôle d'accès de sécurité ;
<Desc/Clms Page number 3>
. un groupe d'instructions de contrôle de logiciels ; et . des programmes et des données pour le logiciel devant être testé, - une interface d'entrée connectée au contrôleur d'essai et destinée à la réception des commandes d'essai ;
et - une interface de sortie, appareil de contrôle dont la pile de disques renferme des sous-répertoires pour chaque ensemble de logiciels d'application, les sous-répertoires comprenant : - un niveau émetteur cible contenant plusieurs groupes de programmes, chaque groupe étant associé à un système destinataire et contenant des programmes développés ou modifiés sur ledit système destinataire ; - un niveau émetteur central contenant plusieurs groupes de programmes, chaque groupe étant associé à un système destinataire et contenant des programmes destinés au dit système destinataire et étant développés ou modifiés sur un système central afin de développer le logiciel ; - un niveau de base contenant un ensemble de fichiers communs à tous les systèmes destinataires ;
et - un niveau de données contenant plusieurs fichiers de données de contrôle, chaque fichier étant associé à un système destinataire, appareil de contrôle dont le contrôleur d'essai comprend un dispositif permettant de : - déterminer automatiquement les sous-répertoires corrects et, à l'intérieur des
<Desc/Clms Page number 4>
dits sous-répertoires, les groupes corrects de programmes dans les niveaux émetteur cible et émetteur central ainsi que les fichiers corrects de données dans le niveau de données pour chaque séance d'essai déclenchant le signal introduit sur l'interface d'entrée ;
et - commander automatiquement l'extraction des dits groupes de programmes, des programmes de base et des dits fichiers de données par l'accès aux niveaux émetteur cible, émetteur central et aux commandes de base et de données ainsi que par la transcription des programmes et des données restituées sur la mémoire vive, par l'extraction des instructions de contrôle et par la commande de contrôle des programmes et des données restitués dans la mémoire vive.
Selon une forme de réalisation de l'invention, la pile de disques durs enregistre un fichier de codes de système destinataire, chaque code étant associé à une séance d'essai, et le contrôleur d'essai comprend un dispositif destiné à extraire un code de système destinataire conformément aux signaux reçus de déclenchement de la séance d'essai et destiné à permettre automatiquement l'accès aux programmes et aux données appropriés de même qu'aux instructions de contrôle ainsi que leur extraction par décodage du code du système destinataire.
De préférence, la pile de disques mémorise un fichier de listes, chaque liste étant associée à un code particulier de système destinataire et comprenant les adresses pour les programmes appropriés des sous-répertoires et les fichiers de données associés.
Selon une autre forme de réalisation de l'invention, le fichier des codes du système destinataire et le fichier des listes sont mis à jour de manière dynamique par le contrôleur d'essai en temps réel.
Selon une autre forme de réalisation de l'invention, les fichiers de données de
<Desc/Clms Page number 5>
contrôle comprennent des échantillons de données d'essai pour le système destinataire associé, et le contrôleur d'essai comprend un dispositif destiné à la mise à jour automatique d'un fichier de données comprenant des données réelles provenant du système destinataire à distance et requises pour le contrôle.
On comprend plus clairement la présente invention grâce à la description de certaines formes de réalisation qui est donnée ci-après uniquement à titre d'exemple et faisant référence au dessin annexé, lequel est un schéma illustrant un appareil de contrôle de logiciels conforme à l'invention.
Si l'on se réfère au dessin, celui-ci représente un appareil de contrôle de logiciels conforme à l'invention et désigné généralement par le numéro de référence 1. L'appareil 1 comprend un contrôleur d'essai 2, lequel est un circuit de contrôle à micro-processeur de modèle IBM AS400 9406F. 50 comprenant un disque dur de 12,5 Gb et une mémoire vive de 96 Mb.
L'appareil 1 est destiné au contrôle de logiciels d'application pour systèmes destinataires et développés sur un système central. Le contrôle du logiciel a lieu au cours du développement, lors des étapes finales de développement et après le lancement du programme pour un support permanent et le développement de nouvelles versions pour les systèmes destinataires.
Le contrôleur d'essai 2 est connecté à une interface d'entrée 3 permettant à un ingénieur de champ d'essai d'enregistrer les instructions régissant les opérations de contrôle devant être exécutées. Le contrôleur 2 lit un fichier de contrôle d'accès de sécurité 4 enregistré sur disque et comprenant des instructions de contrôle de sécurité afin de permettre l'accès des utilisateurs aux données et aux programmes mémorisés.
Le fichier 4 est généré par le système d'exploitation de l'appareil 1 et comprend l'accès aux instructions de contrôle. Ces instructions de contrôle d'accès sont mémorisées comme un profil pour chaque utilisateur de l'appareil 1, chaque
<Desc/Clms Page number 6>
utilisateur disposant d'une entrée indexée dans le fichier d'utilisateur de type définition également mémorisé dans le disque. De cette manière, une demande d'utilisation du système est dans un premier temps contrôlée afin de fixer un code autorisé d'identification de l'utilisateur. Lorsque l'identité de l'utilisateur a été validée, la liste indexée de profils est adressée afin de déterminer les droits d'accès de cet utilisateur particulier.
Toutefois, il est en outre prévu un groupe d'instructions de contrôle d'accès en fonction du niveau de contrôle, ce afin de fournir un niveau de sécurité qui est plus élevé que celui établi par le système d'exploitation. Cette mesure est appliquée par la définition d'un groupe exclusif de types de définitions d'utilisateurs en plus des définitions du système d'exploitation. Les droits d'accès établis dans ces types de définitions peuvent par exemple exclure l'accès à certaines versions d'outils logiciels et/ou de développement assurant ainsi que l'accès au cadre d'utilisation correct de développement ou de contrôle soit fixé par un directeur de projet ou un officier de sécurité. Le fait de déterminer l'accès de cette manière éloigne la possibilité pour l'ingénieur du champ d'essai d'accéder à un logiciel auquel il n'a pas accès.
Les codes pour les objets des systèmes destinataires (programmes et données) sont mémorisés dans un fichier 5 sur une pile de disques durs à laquelle on accède par le contrôleur d'essai 2. Ces codes sont associés directement aux instructions d'accès de sécurité du fichier 4 de telle sorte que chaque utilisateur ayant accès à l'appareil de contrôle de logiciels 1 peut uniquement accéder aux objets désignés par les codes du fichier 5. Les codes du fichier 5 peuvent dans la pratique se rapporter aux objets telle qu'une phase de contrôle particulière d'un certain projet de développement de logiciels.
Le format peut être : Code du système prototype Objets TSC 0073 Programmes et données pour les logiciels d'application #05, phase
<Desc/Clms Page number 7>
de contrôle #3 TSC 0135 programmes et données pour le support de logiciels d'application #7 installés sur un système destinataire #105 et contrôle du service de support.
Un aspect très important concerne le fait que le contrôleur d'essai 2 maintient de manière dynamique le fichier 5 en temps réel afin d'offrir un accès de sécurité aux versions appropriées du logiciel.
D est prévu un fichier 6 mémorisant les listes bibliothèques pour les codes du système destinataire. Les objets (programmes et données) sont mémorisés sur l'appareil de contrôle de disque 1 sous forme de groupes ou de listes et la séquence permettant d'accéder aux bibliothèques pour toute tâche particulière est régie par une liste. Dans l'appareil 1, il est prévu une liste pour chaque code de système prototype du fichier 5 dans une liaison bi-univoque. Pour chaque code du fichier 5, il est prévu une liste bibliothèque dans le fichier 6 régissant la séquence dans laquelle on accède aux objets pour l'opération particulière. H est prévu un contrôleur de disques 7 permettant au contrôleur 2 d'accéder aux objets qui sont mémorisés sur une pile de disques durs.
Sur le dessin, le flux des signaux d'accès aux objets mémorisés sur la pile de disques 8 est désigné par le groupe de flèches 20 (en traits interrompus). Lors du fonctionnement, lorsque un ingénieur de champ d'essai souhaite accéder aux objets pour le contrôle, il encode simplement les détails corrects requis par le contrôleur d'essai, en réponse aux instructions de contrôle d'accès extraites à partir du fichier 4.
Une fois cet encodage réalisé, le contrôleur d'essai 2 détermine automatiquement le code correct du système destinataire, la liste bibliothèque associée et extrait ensuite
<Desc/Clms Page number 8>
les objets appropriés. Lors de cette étape, le contrôleur d'essai 2 crée automatiquement le cadre d'essai correct pour l'ingénieur de champ d'essai. H s'agit là d'une étape très importante dans la mesure où différentes opérations de contrôle sont possibles et où un nombre déroutant de systèmes destinataires doit être supporté.
Un avantage pratique concerne le fait que lors de l'utilisation des fichiers 4,5 et 6 et lors d'une mise à jour en temps réel et dynamique du fichier du code du système prototype 5 et du fichier de liste 6, l'ingénieur de champ d'essai sera toujours confronté à un cadre d'essai correct, de même que les pertes de temps et les erreurs dues au travail sur des versions de logiciels dépassées seront par exemple évitées.
Pour chaque groupe de logiciels d'application, la pile de disques durs 8 présente des sous-répertoires 8 (a) comme le montre le dessin. Par souci de clarté, ces sousrépertoires 8 (a) se rapportent uniquement à quatre systèmes destinataires, alors que dans la pratique ils sont présents dans un nombre généralement beaucoup plus élevé.
En outre, alors que chaque système destinataire est représenté comme ne comprenant qu'une seule bibliothèque, on appréciera le fait que la présence d'un plus grand nombre est possible et même probable. Les sous-répertoires 8 (a) comprennent le niveau TO (émetteur-cible), le niveau HO (émetteur central), le niveau B (base) et le niveau D (données).
Le niveau TO contient une bibliothèque pour un système destinataire gérant (ou destiné à gérer) le groupe particulier de logiciels d'application associé aux sousrépertoires 8 (a). Chaque bibliothèque est associée à un système destinataire et aux programmes spécifiques au système destinataire particulier et qui sont émis sur le système destinataire.
Le niveau HO contient une bibliothèque pour chaque système destinataire gérant (ou destiné à gérer) le groupe de logiciels d'application. Chaque bibliothèque est associée à un système destinataire et présente des programmes spécifiques au système destinataire. Toutefois, dans ce cas, des programmes sont émis par le système central.
<Desc/Clms Page number 9>
Le niveau B présente une simple (vaste) bibliothèque associée au groupe de logiciels d'application mais est commun à tous les systèmes destinataires gérant (ou destinés à gérer) ce logiciel. Cette bibliothèque ne comprend que des programmes objets.
Enfin, le niveau D présente un groupe de bibliothèques de fichiers de données, chacune étant associée à un système destinataire particulier. Les fichiers de données sont dans de nombreux cas des échantillons de données d'essai qui peuvent être reçus en différé ou qui peuvent dans certains cas être mis à jour en direct à partir du système destinataire, ce en fonction de la nature du contrôle requis. L'association de ces fichiers aux programmes associés est mise à jour de manière dynamique grâce à l'utilisation d'une base de données de tables d'accès presque relationnelle. Les fichiers de données des bibliothèques D peuvent également contenir des paramètres pour le fonctionnement du système destinataire.
Lors du fonctionnement, les programmes et les données pour une séance d'essai sont extraites par le contrôleur de disques 7 accédant automatiquement aux bibliothèques correctes pour la séance par détermination des sous-répertoires corrects et des adresses de bibliothèques à partir de la liste extraite à partir du fichier 6. L'accès aux bibliothèques est possible dans les séquences TO, HO, B et D même si une bibliothèque de TO ou HO est vide. La restitution des programmes et des données associées à la mémoire vive 9 est désignée par les flèches 30.
On appréciera immédiatement le fait que l'appareil de contrôle de logiciels 1 mémorise tous les programmes et toutes les données de contrôle associées pour tous les systèmes destinataires pour lesquels le logiciel d'application est développé et a été développé par le système central de l'appareil 1. Etant donné que les programmes spécifiques au système destinataire sont séparés, l'appareil 1 peut mémoriser une bibliothèque à un seul niveau pour chaque pièce de logiciel d'application. En outre, la subdivision des programmes spécifiques du système destinataire en niveaux HO et TO offre une nouvelle structure et augmente les facilités d'accès.
Dans la mesure
<Desc/Clms Page number 10>
où, dans la moyenne, la bibliothèque de base B mémorise plus de 80% de tous les programmes localisés dans les différents systèmes destinataires, chacun ayant son propre logiciel d'application, les niveaux TO et HO peuvent être relativement petits et bien entendu, la bibliothèque de base ne doit être enregistrée qu'une fois. Ce dispositif permet à l'appareil de mémoriser tous les programmes pour les systèmes destinataires sans avoir besoin d'une très grande capacité de mémoire et en évitant des temps de réponse très lents.
En réalité, cela signifie que le cadre d'essai destiné au contrôle de développement de prédiffusion, au contrôle de support de post-diffusion et également au contrôle de mise à jour de la version et de la diffusion est développé de la même manière. Cela offre une uniformité et une cohérence de contrôle à tous les niveaux. La flexibilité est également fournie. Par exemple, un ingénieur de champ d'essai expérimenté et un stagiaire auront différentes listes bibliothèques pour la même séance d'essai. Celles-ci doivent être pré-encodées dans le fichier 6 de telle sorte que le cadre d'essai pour le stagiaire comprend des pseudo-bibliothèques copiant le véritable cadre d'essai. Les programmes peuvent donc être utilisés par le stagiaire et tout changement ou dommage commis par inadvertance n'aura pas d'effet nuisible sur le véritable cadre d'essai.
Le statut de tels programmes et de telles données dans la liste du stagiaire peut être contrôlé afin de déterminer la progression de la formation.
Un autre avantage de la mémorisation des programmes et des données d'une telle manière concerne le fait que les listes contenues dans le fichier 6 peuvent être réglées à l'avance pour chaque code de système destinataire et peuvent contrôler la manière d'accès aux programmes et aux données par une voie prédéterminée avec peu ou pas de risque d'erreur. Par exemple, lors du contrôle du projet 1, phase 1, il sera prévu un code de système destinataire particulier dans le fichier 5 et à cet effet une liste bibliothèque dans le fichier 6. Cette liste bibliothèque régira la manière selon laquelle le contrôleur de disques 7 permet l'accès du contrôleur d'essai 2 aux programmes et aux données mémorisées.
Il est donc prévu une structure d'ensemble assurant dans un premier temps l'accès aux programmes émetteur cible et dans un second temps
<Desc/Clms Page number 11>
l'accès aux programmes émetteur central, ce avant l'accès aux programmes équivalents dans la bibliothèque de base. Ce procédé assure qu'il y ait toujours un accès aux mises à jour les plus récentes des programmes pour chaque système destinataire.
Le flux de signaux le plus important par la suite concerne la restitution par le contrôleur d'essai 2 des instructions d'essai provenant d'un fichier 10. Ces instructions sont transmises (comme le montre la flèche 40) directement vers la mémoire vive 9 de telle sorte que les données et les programmes qui sont transcrits peuvent être testés. Toute la procédure de contrôle est exécutée dans la mémoire vive 9. Les signaux de sortie de contrôle sont transmis vers un écran de sortie 12 comme le montre la flèche 50.
Lorsqu'une nouvelle donnée relative à un cadre d'essai particulier ou une nouvelle donnée de contrôle relative à un projet est reçue par le fichier d'essai 10, la base de données des conditions d'essai est transcrite ou ajoutée, tel que requis.
Lors de la réception d'une demande pour un signal d'essai ou de donnée provenant du contrôleur d'essai 2, les fichiers d'essai ou de données associés à l'unité testée sont extraits conformément aux liaisons associées gardées en mémoire par la base de données sur le disque et mémorisés dans la mémoire vive 9. Ces valeurs de données ou ces paramètres de contrôle sont alimentés vers l'unité testée en série ou en mode parallèle à travers le bus. La manière selon laquelle ils sont reçus est déterminée par l'unité testée.
Le fichier de contrôle 10 est structuré afin de répondre à l'unité testée au moyen d'instructions de contrôle configurées à l'étage de programme, à l'étage de module et à l'étage de système. Les instructions de contrôle génèrent des signaux de contrôle valides et des signaux de contrôle non valides, chacun pouvant être guidé vers un décodeur de signal de contrôle (non représenté) et pouvant indiquer à l'ingénieur de
<Desc/Clms Page number 12>
champ d'essai la procédure de contrôle interactif. De manière alternative, elles peuvent prévoir un contrôle automatique de régression par l'accès à d'autres paramètres de contrôle également mémorisés sur le disque. Cela dépend du code de système destinataire approprié.
B convient d'apprécier que l'appareil 1 permet une augmentation de la productivité des ingénieurs de champ d'essai dans la mesure où les objets sont déterminés très rapidement et automatiquement pour chaque projet particulier. On appréciera également le fait que en raison de la structure du dispositif de stockage 8, l'accès aux dernières mises à jour des programmes et des données est toujours correct. En outre, l'accès aux données et aux programmes est très rapide, même dans le cas où des programmes et des données destinées à un grand nombre de systèmes destinataires doivent être mémorisées.
Cela évite dans de nombreuses circonstances la nécessité de recourir à un accès en ligne aux fichiers de données d'un système destinataire particulier et permet un accès vaste et rapide à toutes les dernières mises à jour des programmes et des données pour chaque système destinataire. La structure permet une mémorisation d'une seule bibliothèque de base pour chaque pièce de logiciel d'application et il est donc possible d'enregistrer le code pour tous les systèmes destinataires.
Un autre aspect de l'invention concerne la manière selon laquelle les opérations de contrôle peuvent être étendues afin de fournir de meilleures lignes de codes pour un système destinataire. Dans le cas où un tel programme est développé, il est possible, grâce à une opération très simple, de réaliser une recherche à travers la ou les listes de bibliothèque pour chaque système destinataire afin de déterminer s'il existe une version spécifique de système destinataire de ce programme de telle sorte qu'une comparaison puisse être réalisée de même qu'une décision de changement ou de non changement puisse être prise.
En d'autres termes, les caractéristiques de l'appareil de contrôle 1 permettent une augmentation efficace de la puissance des programmes sur un grand nombre et une grande variété de systèmes destinataires.
<Desc/Clms Page number 13>
La présente invention ne se limite pas aux formes de réalisation décrites ci-dessus qui peuvent varier dans leur construction et dans leurs détails.
<Desc / Clms Page number 1>
The present invention relates to an application software monitoring device.
In the description of this patent, the term "control" refers to all of the control operations carried out before the shipment of software or a set of software, during development and the final stage. of this development, as it relates to ongoing maintenance, development and support of the software after it is shipped to the end user.
Several specific control methods are currently known, one of which is described in the description of European patent No. EP-BI-0286361 (Westinghouse).
However, one of the problems faced by test field engineers when testing application software was to provide access to the most recent version of the software used on a recipient system. Frequently, delays occur when accessing the correct programs and data files for a particular recipient system, and errors are often caused by using the wrong version of software. This can lead to a considerable loss of time, loss of income and loss of customer confidence. This was particularly the case for software development organizations where a large number of application software used on recipient systems is developed by the organization.
One way of tackling the problem was to access the receiving system in interactive mode via the modem and to transmit the error diagnosis signals via the communication lines. While this process is found to be satisfactory to some extent, it has limitations as to the nature of the control that can be performed. For example, it is not practical in some cases to perform very extensive checks using large volumes of data and programs used by
<Desc / Clms Page number 2>
recipient systems. In addition, this approach does not allow rapid access to programs and data as they have been developed on the central system in situations where different pieces of application software are developed.
The objectives of the present invention are therefore to develop a software control device, which: - is capable of providing almost immediate access to all the programs and to all the appropriate control data, these being developed internally and distance on recipient systems on site; - provides correct access to the most recent updates to programs and data files, in a simple manner and requiring very little programming time; - allows extensive control in all situations; and - ensures the effectiveness of the control of new versions of application software intended to be installed on a large number of recipient systems.
In accordance with the present invention, there is provided a software control apparatus for controlling recipient system software developed on a central system, the apparatus comprising: - a test controller connected to a RAM; - a stack of hard disks connected to a disk controller comprising:. a security access control instruction file;
<Desc / Clms Page number 3>
. a group of software control instructions; and. programs and data for the software to be tested, - an input interface connected to the test controller and intended for the reception of test commands;
and - an output interface, a control device whose disk stack contains sub-directories for each set of application software, the sub-directories comprising: - a target transmitter level containing several groups of programs, each group being associated to a recipient system and containing programs developed or modified on said recipient system; a central transmitter level containing several groups of programs, each group being associated with a recipient system and containing programs intended for said recipient system and being developed or modified on a central system in order to develop the software; - a basic level containing a set of files common to all the recipient systems;
and - a data level containing several control data files, each file being associated with a recipient system, a control device, the test controller of which includes a device making it possible to: - automatically determine the correct sub-directories and, when inside
<Desc / Clms Page number 4>
said sub-directories, the correct groups of programs in the target transmitter and central transmitter levels as well as the correct data files in the data level for each test session triggering the signal introduced on the input interface;
and - automatically controlling the extraction of said program groups, basic programs and said data files by access to the target transmitter level, central transmitter and to the basic and data commands as well as by the transcription of the programs and data restored on the random access memory, by the extraction of the control instructions and by the control command of the programs and the data restored in the random access memory.
According to one embodiment of the invention, the stack of hard disks records a file of recipient system codes, each code being associated with a test session, and the test controller comprises a device intended to extract a code from recipient system in accordance with the signals received to initiate the test session and intended to automatically allow access to the appropriate programs and data as well as to the control instructions as well as their extraction by decoding the code of the recipient system.
Preferably, the disk stack stores a list file, each list being associated with a particular recipient system code and comprising the addresses for the appropriate programs of the subdirectories and the associated data files.
According to another embodiment of the invention, the code file of the recipient system and the list file are updated dynamically by the test controller in real time.
According to another embodiment of the invention, the data files of
<Desc / Clms Page number 5>
control include samples of test data for the associated recipient system, and the test controller includes a device for automatically updating a data file comprising actual data from the remote recipient system and required for Control.
The present invention will be understood more clearly thanks to the description of certain embodiments which is given below only by way of example and with reference to the appended drawing, which is a diagram illustrating a software control apparatus in accordance with invention.
If one refers to the drawing, this represents a software control device according to the invention and generally designated by the reference number 1. The device 1 comprises a test controller 2, which is a circuit microprocessor control unit model IBM AS400 9406F. 50 including a 12.5 Gb hard drive and 96 Mb RAM.
The apparatus 1 is intended for the control of application software for recipient systems and developed on a central system. Control of the software takes place during development, during the final stages of development and after the launch of the program for permanent support and the development of new versions for the recipient systems.
The test controller 2 is connected to an input interface 3 allowing a test field engineer to record the instructions governing the control operations to be performed. The controller 2 reads a security access control file 4 recorded on disk and comprising security control instructions in order to allow user access to the stored data and programs.
The file 4 is generated by the operating system of the device 1 and includes access to the control instructions. These access control instructions are stored as a profile for each user of the device 1, each
<Desc / Clms Page number 6>
user with an entry indexed in the user file of the definition type also stored in the disk. In this way, a request to use the system is first checked in order to set an authorized user identification code. When the identity of the user has been validated, the indexed list of profiles is sent to determine the access rights of this particular user.
However, there is further provided a group of access control instructions depending on the level of control, in order to provide a level of security which is higher than that established by the operating system. This measure is applied by defining an exclusive group of types of user definitions in addition to the operating system definitions. The access rights established in these types of definitions may, for example, exclude access to certain versions of software and / or development tools, thus ensuring that access to the correct development or control framework is fixed by a project manager or security officer. Determining access in this way removes the possibility for the engineer of the test field to access software to which he does not have access.
The codes for the objects of the recipient systems (programs and data) are stored in a file 5 on a stack of hard disks which is accessed by the test controller 2. These codes are associated directly with the security access instructions of the file 4 so that each user having access to the software tester 1 can only access the objects designated by the codes in file 5. The codes in file 5 can in practice relate to objects such as a phase special control of a certain software development project.
The format can be: Prototype system code Objects TSC 0073 Programs and data for application software # 05, phase
<Desc / Clms Page number 7>
control # 3 TSC 0135 programs and data for the support of application software # 7 installed on a recipient system # 105 and control of the support service.
A very important aspect concerns the fact that the test controller 2 dynamically maintains the file 5 in real time in order to provide security access to the appropriate versions of the software.
A file 6 is provided which stores the library lists for the codes of the recipient system. The objects (programs and data) are stored on the disk control apparatus 1 in the form of groups or lists and the sequence allowing access to the libraries for any particular task is governed by a list. In device 1, a list is provided for each prototype system code of file 5 in a one-to-one connection. For each code in file 5, a library list is provided in file 6 governing the sequence in which objects are accessed for the particular operation. There is provided a disk controller 7 allowing the controller 2 to access the objects which are stored on a stack of hard disks.
In the drawing, the flow of the access signals to the objects stored on the disk stack 8 is designated by the group of arrows 20 (in dashed lines). During operation, when a test field engineer wishes to access objects for control, he simply encodes the correct details required by the test controller, in response to the access control instructions extracted from file 4.
Once this encoding has been carried out, the test controller 2 automatically determines the correct code of the recipient system, the associated library list and then extracts
<Desc / Clms Page number 8>
appropriate objects. During this step, the test controller 2 automatically creates the correct test frame for the test field engineer. This is a very important step insofar as different control operations are possible and where a confusing number of recipient systems must be supported.
A practical advantage relates to the fact that when using files 4,5 and 6 and during a real-time and dynamic update of the code file of the prototype system 5 and of the list file 6, the engineer test field will always be confronted with a correct test framework, as well as the loss of time and errors due to work on outdated software versions will be avoided for example.
For each group of application software, the stack of hard disks 8 has subdirectories 8 (a) as shown in the drawing. For the sake of clarity, these subdirectories 8 (a) relate only to four recipient systems, while in practice they are present in a generally much higher number.
In addition, while each recipient system is represented as comprising only one library, it will be appreciated that the presence of a larger number is possible and even probable. Subdirectories 8 (a) include the TO level (target transmitter), the HO level (central transmitter), the B level (base) and the D level (data).
The TO level contains a library for a recipient system managing (or intended to manage) the particular group of application software associated with the subdirectories 8 (a). Each library is associated with a recipient system and programs specific to the particular recipient system that are issued on the recipient system.
The HO level contains a library for each recipient system managing (or intended to manage) the group of application software. Each library is associated with a recipient system and presents programs specific to the recipient system. However, in this case, programs are transmitted by the central system.
<Desc / Clms Page number 9>
Level B presents a simple (vast) library associated with the group of application software but is common to all the recipient systems managing (or intended to manage) this software. This library only includes object programs.
Finally, level D presents a group of data file libraries, each of which is associated with a particular recipient system. The data files are in many cases samples of test data which can be received offline or which can in some cases be updated live from the recipient system, depending on the nature of the check required. The association of these files with the associated programs is updated dynamically through the use of an almost relational access table database. The D library data files can also contain parameters for the operation of the recipient system.
During operation, the programs and the data for a test session are extracted by the disk controller 7 automatically accessing the correct libraries for the session by determining the correct sub-directories and the addresses of libraries from the list extracted at from file 6. Access to libraries is possible in sequences TO, HO, B and D even if a library of TO or HO is empty. The restitution of the programs and of the data associated with the RAM 9 is designated by the arrows 30.
It will immediately be appreciated that the software tester 1 stores all of the programs and all of the associated control data for all of the recipient systems for which the application software is developed and has been developed by the central system of the device 1. Since the programs specific to the recipient system are separate, device 1 can store a library at one level for each piece of application software. In addition, the subdivision of the specific programs of the recipient system into HO and TO levels offers a new structure and increases ease of access.
Insofar
<Desc / Clms Page number 10>
where, on average, the basic library B stores more than 80% of all the programs located in the different recipient systems, each having its own application software, the levels TO and HO can be relatively small and, of course, the base library need only be registered once. This device allows the device to memorize all the programs for the recipient systems without needing a very large memory capacity and avoiding very slow response times.
In reality, this means that the test framework for pre-release development control, post-release media control, and also version and release update control is developed in the same way. This provides uniformity and consistency of control at all levels. Flexibility is also provided. For example, an experienced test field engineer and an intern will have different library lists for the same test session. These must be pre-encoded in file 6 so that the test frame for the trainee includes pseudo-libraries copying the real test frame. The programs can therefore be used by the trainee and any inadvertent change or damage will not have a detrimental effect on the actual test setting.
The status of such programs and data in the trainee list can be checked to determine the progress of the training.
Another advantage of storing programs and data in such a way is that the lists contained in file 6 can be set in advance for each recipient system code and can control how the programs are accessed. and to data by a predetermined channel with little or no risk of error. For example, when checking project 1, phase 1, a specific recipient system code will be provided in file 5 and for this purpose a library list in file 6. This library list will govern the way in which the disk controller 7 allows the access of the test controller 2 to the stored programs and data.
An overall structure is therefore provided, firstly ensuring access to the target transmitter programs and secondly
<Desc / Clms Page number 11>
access to central transmitter programs, before access to equivalent programs in the basic library. This process ensures that there is always access to the most recent program updates for each recipient system.
The most important signal flow thereafter relates to the restitution by the test controller 2 of the test instructions coming from a file 10. These instructions are transmitted (as shown in arrow 40) directly to the RAM 9 so that the data and programs that are transcribed can be tested. The entire control procedure is carried out in the random access memory 9. The control output signals are transmitted to an output screen 12 as shown by arrow 50.
When new data relating to a particular test framework or new control data relating to a project is received by test file 10, the database of test conditions is transcribed or added, as required .
Upon receipt of a request for a test or data signal from the test controller 2, the test or data files associated with the unit under test are extracted in accordance with the associated links kept in memory by the database on the disk and stored in the random access memory 9. These data values or these control parameters are supplied to the unit tested in series or in parallel mode through the bus. How they are received is determined by the unit tested.
The control file 10 is structured in order to respond to the unit tested by means of control instructions configured in the program stage, in the module stage and in the system stage. The control instructions generate valid control signals and invalid control signals, each of which can be guided to a control signal decoder (not shown) and can indicate to the engineer
<Desc / Clms Page number 12>
test field the interactive control procedure. Alternatively, they can provide automatic regression control by accessing other control parameters also stored on the disk. It depends on the appropriate recipient system code.
It should be appreciated that the apparatus 1 allows an increase in the productivity of the test field engineers insofar as the objects are determined very quickly and automatically for each particular project. It will also be appreciated that due to the structure of the storage device 8, access to the latest updates of programs and data is always correct. In addition, access to data and programs is very fast, even when programs and data intended for a large number of recipient systems have to be stored.
This in many circumstances avoids the need for online access to the data files of a particular recipient system and allows extensive and rapid access to all the latest program and data updates for each recipient system. The structure allows storage of a single basic library for each piece of application software and it is therefore possible to save the code for all recipient systems.
Another aspect of the invention relates to the manner in which control operations can be extended to provide better lines of code for a recipient system. In the case where such a program is developed, it is possible, by means of a very simple operation, to carry out a search through the library list or lists for each recipient system in order to determine whether there is a specific version of recipient system of this program so that a comparison can be made as well as a change or no change decision can be made.
In other words, the characteristics of the control device 1 allow an effective increase in the power of the programs on a large number and a wide variety of recipient systems.
<Desc / Clms Page number 13>
The present invention is not limited to the embodiments described above which may vary in their construction and in their details.