JP2001043110A - Debugging method for program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce man-hour for debugging and to reuse the debugging by comparing time described in a simulation input file with a described programmed value at that time and recording compared result in the simulation output file. SOLUTION: An interface part with a simulator of an interface 1 with the simulator is embedded in a source of an application program. Then, an execution program 'regular. exe' execution file 3 linking the simulator by linking a simulator library 2 is prepared. A simulator input file name of a simulator input file 'SimIn. txt' 4 is applied as an argument of a command line and 'regular. exe' 'SimIn. txt' are executed. The executed result is recorded in a simulation output file 'output. txt' 5 recorded in the simulation output file.

Description

DETAILED DESCRIPTION OF THE INVENTION

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention creates a file in which input values and confirmation data values in a debugging operation are described together with elapsed time, and uses this file to operate and confirm a program on a computer. How to debug

2. Description of the Related Art Standard techniques for debugging programs have not been established. 1. Anyway, let's see if there is a part that operates strangely by human beings in the dark cloud. 2. Operate according to the specifications and confirm that there is no operation different from the specifications. Things are going on. As a more advanced debugging method, to eliminate missing check items 1. 1. Create a state transition table, perform operations for all state transitions, and confirm that there is no abnormal operation. A check list is created for all parts of the program where a conditional branch occurs, and an operation for generating the conditional branch is performed to confirm that there is no abnormal operation. There was a Microsoft product called "MS-Test". As of August 1999, Rational Rose purchased rights from Microsoft and said, "Rational Visual
l Test ". This software allows Microsoft Windows software to let the computer do the work that the tester does. This software automates the test work. It does the following: 1. Run the basic Microsoft Windows software. Perform keyboard and mouse operations. Record the operation in a file. 2. The bit map data of the Windows screen created as a result of responding to the operation is recorded in a file. 3. When testing on a personal computer that has a different CPU and board, according to the previously recorded operation file,
The computer operates the program to be tested. 4. The bits resulting from running the program under test
Have the computer compare the map screen with the previously recorded bit map screen and have the computer confirm that there is no difference. 5. Instead of recording the key operation and mouse operation, W
A script that calls the Windows API can also be created. In this way, many types of personal computers themselves can perform program operation checks on Microsoft Windows. “MS-Test” “Rational V”
"Isual Test" is the same as that of the present invention in that the software is automatically checked. You can use them not only for testing different types of personal computers, but also for testing software with some improvements. However, they differ in the following points. 1. There is no need to describe in advance the time change of the expected values of the dormitory variables and output variables in the simulation input file. The number of loops, the elapsed time, and the simulation input file are not associated with each other and reflected in the operation of the program. 3. The expected value of the output variable change is described in the simulation input file, and the computer does not check whether the expected value matches the expected value. “MS-Test” “Ration
al Visual Test "is software for test engineers. The present invention is a debugging method for a programmer. The present invention and "Rational V
“Isual Test” is similar but different. Conventional techniques and debugging techniques generally used for program debugging itself, which should be compared with the present invention, involve manually operating software and confirming it by a human.

[Problems to be Solved by the Invention] [The debugging result cannot be reused] A lot of man-hours are spent for program debugging without omission. One-thirty percent of software development man-hours can be considered debug man-hours. In some cases, more than half is spent on debugging. The program has been reused many times with some modifications. Debugging can record results, but was difficult to reuse. It is very difficult to predict what problems a program bug will cause and what it will do. Each time a part of the program is modified, the previous debugging sequence is repeated again. Because the debugging done before cannot be reused, a lot of debugging man-hours were generated many times. [It takes time to get a debug result] It takes time to perform operations and check by humans. 0 for computer.
It takes about one second for humans to perform operations and confirmation processes that can be performed with 01mSec. [Dedicated device (ICE) is required] In cross software development of different CPUs such as software development of one-chip microcomputer, ICE (In
Circuit Emulator) is required. Extra equipment, cost and effort are required. [The reproducibility of the bug is poor for debugging. Many factors are involved in the malfunction of a program. If you find a bug in a program, you must reproduce the behavior of the bug in order to identify the cause and take action. Sometimes it is difficult to reproduce the bug because the operation differs depending on the delicate timing of the operation. In the final stage of program development, it is often troubled to deal with such bugs. In particular, when an erroneous operation occurs less frequently than once a day, it is extremely difficult to find the reproduction condition. [It is difficult to debug when the input change is fast.] Some mechanical systems operate at a speed of several tens of mSec. A human cannot manually change such a high-speed input for debugging to create a signal. In order to confirm that no malfunction occurs due to a change in timing, it is necessary to make a dedicated jig. There are many examples where only the desktop debugging has been spared. [Low reliability of debugging results] Operations and confirmations performed by humans include mistakes. When performing hundreds or thousands of checks for debugging using the state transition table, operational errors, missing confirmations, or incorrect confirmations occur. The enormous debugging effort included a few percent of mistakes. Its reliability remained low. [Specifications cannot be used directly for debugging and checking operation] A human being read and debugged a program specification. Despite being a program specification that is a file that can be directly handled by a computer, it has not been used to let the computer compare the specification with the actual program operation using it. [Transmission of specification information] The specification of the program is described in a natural language such as Japanese or English. The operating specifications of the program are transmitted in natural language. But it is difficult to accurately convey all of the vast amount of information. Sentence expression using natural language has ambiguity. The meaning of the words used is slightly different for each person. The problem becomes more apparent when programmers in different languages develop software. [Difficult to communicate debug results] When debugging was done by a different person than the programmer, it was difficult to tell the programmer who fixed the information when a bug was found in the program. This is because the person who is debugging cannot fully understand and represent the malfunction phenomenon and its reproduction conditions. There are limitations of natural language here as well.

[Means for solving the problems] The program is: 1. In response to input change 2. Upon receiving an interrupt It operates by calling OS application interface such as keyboard and mouse operations. These can be replaced by computer operations by doing the following. 1. Changes in inputs change the input variables of the program. 2. 2. For the occurrence of an interrupt, call a subroutine (function) that handles the interrupt. Instead of operating the keyboard and mouse, the application interface of the OS is directly called. Confirmation of the operation result can also determine whether the output variable has changed and whether or not the scheduled value should be compared with the computer.
This will be described in more detail. Instead of human beings performing operations and confirmations for debugging, it is possible to cause a computer to perform operations and confirmations for debugging using the following procedure. . 1. The sequential change of the input is described in the simulation input file as numerical data of the time when the change occurred and the value of the result of the change. 2. Link the simulator library with the application program. 3. The simulator program reads from the simulation input file the time at which the input variable changes and its value, the type of interrupt, and the time at which it should occur. 4. The simulator program runs in synchronization with the application program and manages the operation time. At the time when the above input variables change, the input variables are changed to the values shown in the simulation input file. 5. The simulator program calls the interrupt subroutine at the time when the above interrupt occurs. By doing so, the simulator program injects the time change of the input described in the simulation file into the application and reflects it on the operation of the program, instead of the human performing the input operation for debugging. Not just input operations. Instead of confirming the operation result of the program by a human, the computer causes the computer to confirm the program in the following procedure. 1. The change time of the output variable determined by the response of the application to the sequential change of the input and its value are also described in the simulation input file. 2. At a certain time described in the simulation input file, the simulator program compares the output variables of the application with the expected values described in the simulation file. 3. The comparison result is recorded in the simulation output file together with the time.

[Action] Debugging operations are represented on the simulation input file in the form of time-varying input variables. 2. 2. Software operation specifications are described using symbols as input / output time-varying data. The computer performs the input operation of the program to be tested which has been performed by a human. 4. The computer confirms the operation result of the program to be tested that has been performed by a human. 5. According to the method of the second aspect, when the program is not only a time-dependent program but also a program that is repeatedly executed as shown in the second embodiment, the computer is debugged using the number of loops instead of the time. 6. According to the method of claim 3, the computer records the result of the confirmation performed by a human. 7. The result of the operation by the simulation input of the program remains as an output file that can be processed by the computer. 8. According to the fourth aspect, an input operation that is complicated only by describing a change in an input value can be replaced by a simpler call of a subroutine (function) and a direct setting of an internal variable.

Embodiment 1 Simple Example First, an example of a simple AND gate will be considered. Although not practical, an example of "FIG. 1Y = one second delay (A and B)" will be used to make the operation of the simulator easy to understand. This is 1. 1. When either input A or input B changes, The result of the AND operation appears on the output Y one second later. An example of a program in a main loop format including a simulation program is shown in "Flowchart of Embodiment 1 in FIG. 2". The processes of “FIG. 2” (1) “Registration of input / output variables” and (2) “Synchronization of simulator and application” are programs added to the application to enable simulation / debugging. When shipping after debugging, remove them from the application program. In FIG. 2 (1), input variables A and B are registered in the simulator. As a result, the memory addresses actually arranged as variables A and B in the application program correspond to the input variable names in the simulation input file. A simulator program in which addresses and variable names of input variables are registered can reflect a change with time of an input variable described in a simulator input file as a change in an input variable of an application program. Similarly, the output variable Y is also registered. Thereby, the memory address actually arranged as the variable Y in the application program is made to correspond to the output variable name in the simulation input file. The simulator program in which the address and the variable name of the output variable are registered can detect the change of the output variable.
The changed time and its value can be recorded in the simulator output file. An example of the simulation input file is shown in "FIG. 3 Simulation Input File". This simulation input file contains input variables A,
The time change of B and the scheduled sequence of the output variable Y are listed. The relative elapsed time is indicated by writing a numerical value following the “+ number” and the “+” sign. 1. In FIG. 3 (1), both inputs A and B are set to 0 at the first time 0 in "setting of initial values of A and B inputs". 2. In FIG. 3 (2) “Confirmation of Y output after 1100 mSec”, it is confirmed that output Y continues to be 0 after slightly more than one second. In FIG. 3 (3) “Inputs A and B are set to 1”, both inputs A and B are changed to 1 after 100 mSec from the top. 4. In FIG. 3 (4) “Confirmation of Y output after 500 mSec”, it is confirmed that the output Y is still 0 after 500 mSec from the top. 5. In FIG. 3 (5) “Confirmation of Y output after 600 mSec”, it is confirmed that one second has passed since A and B became 1, and output Y became 1. The initial program specification states that the output changes one second after the input changes. The output during this one second is not specified in the specification. In this simulation input file, for one second after the input changes
It has been confirmed in FIG. 3 (4) that the output Y continues the previous value. The details of the operation that would be too complicated to describe in the specification of the natural language can be described in the simulation input file in the form of a list of symbols. The simulation input file is described with symbols that can be handled by a computer. Therefore, the simulation input file is also an accurate program specification that can be understood by programmers with different native languages.

Second Embodiment Regular Expression A regular expression is a method for expressing a character string pattern. Originally started with Unix. Currently, DOS, MS
Widely used in Windows. Regular expressions are essential knowledge for programmers. Regular expression is DO
'*' Or '? The 'wildcard-is a more generalized version of the character. It defines a general string pattern using metacharacters as follows: '＾' Beginning of line '＄' End of line '. 'Any single character' ￥ 'quote next character' * 'Zero or more characters repeated' + 'One or more characters repeated'? 'Repetition of 0 or 1 character "[aeiou0-9]" a, e, i, o, u, or any one of characters from 0 to 9 "[@ aeiou0-9]" a, e, i, o, u , Or One character other than 0 to 9 Next, a specific example of a character string pattern by a regular expression is shown. [Ac] xy represents any character string of “axy”, “bxy”, “cxy” [ac]? xy represents any character string of “xy”, “axy”, “bxy”, “cxy” [ac] * xy represents “xy”, “axy”, “bxy”, “cxy” “ab xy” Regular expressions representing an infinite number of character strings such as "," abcxy "are often used to extract character strings that match a given character string. Example Matching of regular expression "hijkabcxyzLMN" is [ac] + xy
Has a partial character string "abcxy". A program for processing such a regular expression character string pattern is described in the C / C ++ language and has a scale of about 1000 lines. The program itself can be developed in a few months. However, it is difficult to show that there are no bugs in the resulting program. This is because there are infinite combinations of character string patterns based on regular expressions. More complex elements are added to the regular expression program used in business, such as the character code used. Consider debugging in which the present invention is applied to such a regular expression program. The entire flow is shown in "Flowchart of Embodiment 2 in FIG. 4". Synchronizing the application operation with the simulation by “FIG. 4” (1) “Registering input / output variables” and “FIG. 4” (2) “Synchronization of simulator and application” is “Example 1”.
Is the same as The relationship between the application and the simulator program library is shown in "FIG. 5 Linking and executing the simulator". "Figure 5" (1) "Interface with simulator" in the source of the application program (regular expression program in this case)
Embed the interface with the simulator.
And link with the simulator library "Figure 5"
(3) "Execution program linked with simulator"
egular. Create an exe executable file. “FIG. 5” (4) “Simulator input file SimIn.t
xt "input the simulator input file name as a command line argument. exe SimIn. txt. The result of the execution is shown in FIG. 5 (5) “Record in simulation output file” Simulation output file: output. txt. A program including the simulator of the "second embodiment" is shown in "Pseudo code in C language of the second embodiment in FIG. 6". "Figure 6" 5
DfSimInitialize (.) On the line performs initialization related to the simulation. Among them, doAtInitial (char * p
ChAg). doAtInitial (.)
In the processing of 1. setRglExprsnStrin (char
*): Set a regular expression character string from the simulator. setSentenceString (char
*): Set a character string to be searched with a regular expression. checkMatchedString (char
*): Register a function that compares and confirms the character string of the matching result. These three functions should be described in FIG. 5 (1) in the interface part of the regular expression application with the simulator. The simulator performs up to the point where the registered function is called. Set the regular expression pattern input character string of the application,
The function of setting the sentence input to be checked for matching and confirming the result is performed by a function described on the application side. Although the simulator does not provide such general-purpose functions, complex functions can be set and confirmed by calling functions. . "Figure 6"
DfSimTickBreak () on the seventh line is a part for synchronizing the operation of the application shown in FIG. 4 (2) with the operation of the simulator. In debugging a regular expression, the simulator is operated by the number of loops, not by the elapsed time of the application. Set according to the number of loops
The simulator calls RglExpressnString () and three other functions. Simulator input file used in “Example 2”: SimIn. txt is shown in "Simulator input file of the second embodiment in FIG. 7". The regular expression character string "[AF] +" is given in the first line of FIG. The application is caused to generate a “regular expression automaton” according to the “flowchart of the second embodiment in FIG. 4”. In FIG. 7, the third line sets a character string “xaAABFxabcb” to be tested in the second loop. Then, a character string that matches the above regular expression is searched according to the “flowchart of FIG. 4 Example 2”. It is confirmed that the character string matched in the fourth line of FIG. 7 is “AABF”. Lines 6 and 7 repeat the same. "Figure 7"
The debugging is terminated at the ninth line, and the process returns to the OS. That is,
The seventh line in FIG. 6 executes the break instruction. In this way, the computer sets the regular expression character string and the character string to be searched, and checks the result. By applying the present invention, an operation test in an infinite number of combinations, such as a regular expression program, can be left in a reusable file. This makes debugging much more efficient. Program modifications occur many times during debugging. For a thorough check, the checks performed before the program modification must also be performed after the program modification. At this time, if the debug before the correction is left in the simulation input file, the computer can perform the operation confirmed so far after the correction of the program.

Third Embodiment Debugging of One-Chip Microcomputer In recent years, the ROM size of a one-chip microcomputer has been generally 64 Kbytes. Programs are often described in C language. As the ROM size increases, the size of the program also increases. Even a one-chip microcomputer program has become tens of thousands of lines in C language. The items required for confirming the operation of the program have been extremely increased. Check items in the state transition table may exceed 10,000. Applicable to such practical examples,
An embodiment of the present invention using a one-chip microcomputer will be described. In such a large-scale program, "Fig. 5" (6) "RT
An application task is described using an RTOS such as “OS library”. Link the RTOS library to the application. From a simulator perspective, an RTOS can be considered a time driven engine. 1mSe
If the RTOS manages the time based on the interrupt for each c, the 1 mSec interrupt program is called from the simulator each time the main loop is executed. By doing so, the number of times of going around the main loop can be made to correspond to the elapsed time of the program. By using the present invention, even with such a one-chip microcomputer, most of the program can be debugged in a cross environment such as a personal computer without using ICE. Even if there is no actual machine on which the program runs, debugging is possible. 1. The operation test of the one-chip microcomputer program described in the C language can be performed by another computer on which the C program operates. Changes in the input ports of a one-chip microcomputer can be simulated by setting them as changes in input port variables. A change in the output port of the one-chip microcomputer can be simulated as a change in the output port variable. 4. The interrupt input of the one-chip microcomputer can be simulated by calling the C function describing the interrupt processing. 5. In many cases, a one-chip microcomputer incorporates a display circuit for dynamically lighting a fluorescent display tube. Usually, a ram corresponding to the segment to be lit one-to-one exists inside the microcomputer. In order to confirm the display result of the microcomputer, the value of the corresponding ram variable may be confirmed. Because. An embodiment in which the present invention is applied to an operation of debugging a one-chip microcomputer on a personal computer that enables debugging of one-chip microcomputer software on a personal computer by utilizing the present invention will be described.
Consider a control program of a one-chip microcomputer as shown in "FIG. 8 One-chip microcomputer embodiment".
The operation specifications of this one-chip microcomputer program are as follows. 1. When the switch is on, every time a key is pressed, the display is changed to 1, 2, 3, 1, 2,. . Repeat 2. The key input is an A / D converter input. When the key is away, it becomes 0xff, and when the key is pressed, it becomes 0x00.
Shall be 3. When the switch is off, every time a key is pressed, the display is changed to 7, 8, 9, 7, 8,. . Repeat 4. 4. When there is an interrupt input, the display is set to 0 after one second. OutPort is 0 when DispRAM is even,
When this operation, which becomes 1 when the number is odd, is expressed by using a simulation input file as shown in “FIG. 9 Simulation input file with one-chip microcomputer”.
(Fig. 9) (1) Data "7 '" that causes an error is set in consideration of the "simulation error." The C program for realizing the operation specifications of this microcomputer and the part where variables are registered The source is shown in "Source program of one-chip microcomputer in FIG. 10". Also in this case, "FIG. 10" (1) "Interface with simulator" portion is a portion in which variables are registered. Because it can be written at the end of the program, it can be easily removed from the application. The simulation output file when this is executed is shown in "FIG. 11 Simulation Result". "Figure 11" (1) "Simulation error"
In the part, the detection of the previously set error by simulation is shown. In FIG. 11, the result of the simulation is expressed as a sequence of time, variable names, and variable values. This is also a file that can be processed by a computer. What is converted into a time chart format that is easy for humans to understand is "display of simulation result time chart in FIG. 12". Again, the error created in the simulation input file is "Figure 11"
(1) Displayed as "Simulation error". This error behavior is reliably reproduced. This is because the number of loops is regarded as the passage of time. There is no uncertainty that errors occur and do not occur as in actual machines. It is easy for anyone other than the program creator to create a simulation input file. It merely converts sequential changes in input and output variables into a sequence of symbols in the simulation input file according to the operating specifications. If you can create a simulation input file with errors,
The error can be reproduced by anyone. By using the program creator's debugger to follow the operation of the simulation input file where errors occur reliably, the cause of the errors can be easily found. This debugger can use a C compiler debugger in a cross environment. The timing of the input change in the simulation input file can be arbitrarily set in 1 mSec units. It is also possible to make key input ON / OFF at an extremely high speed of every 10 mSec. If you run the application and simulation input on software called a profiler, you can count which lines of the program have been checked with objective% figures. The result of the coverage measurement is shown in “FIG. 13 Profile Result”. "FIG. 13" (1) The "coverage" portion indicates that the coverage by the current simulation input file is 100%. Thus, the one-chip microcomputer program described in C is executed and confirmed on the cross platform. Debugging is possible without an ICE or without an actual device. It is possible to debug more than ICE or real machine can execute.

[Effect] 1. By causing a computer to perform a debugging operation that has been performed by a human, debugging man-hours can be reduced. 2. Debugging can be accelerated by causing a computer to perform a debugging operation that has been performed by a human. 3. By causing a computer to perform a debugging operation that has been performed by a human, mistakes made by the human in debugging can be eliminated. Debugging reliability can be improved. 4. By describing the change time and value of the input variable and the change time and value of the output variable in the simulation file,
Enables reuse of debugging work. Even if some operations change due to changes in program specifications, etc., most of the previous debugging results can be reused by changing only the corresponding parts of the simulation file. 5. The operation of a program can be represented by sequential time and value in a simulation file. If the operating specifications of a program are expressed in a simulation file, the specifications can be used for computer debugging. 6. The operation of a program can be represented by sequential time and value in a simulation file. The operation specification can be easily and reliably expressed without including the ambiguity of natural language. 7. The operation of a program can be represented by sequential time and value in a simulation file. There is no ethnicity or regionality like natural language. As long as they have simple mathematical abstraction capabilities, even people with different native languages can surely communicate their operation specifications. 8. There is reproducibility. It's just a computer program. Repeat the same operation at the same timing. If you make a simulator input file that causes a malfunction, be sure to cause the same malfunction. Although there is a malfunction, but I do not know the reproduction conditions,
You will not have to look for ways to reliably reproduce the malfunction over the days. 9. The result remains in the file as time / value pair data. It can be converted into a display such as a time chart that is easy for humans to understand intuitively. 10. 10. Can be used in combination with existing tools such as debuggers and profilers Can be used to prove program reliability. Testing and reconfirmation on the user side are possible. If you use the profiler's coverage function, you can objectively check the debug confirmation achievement rate,
It can be represented by a reproducible% value. If a simulator file is included in the program documentation in addition to the source code, it becomes extremely difficult to insert a malicious program. 12. Third parties can easily modify the program and check the operation. If you have a simulation input file, you can debug it in the same way as the author. Countermeasures such as the year 2000 problem will also be easy. The following effects are also obtained in the development of embedded software. 1. Even if there is no actual machine, the program operation can be checked. 2. Debugging can be performed without a device dedicated to debugging represented by ICE. 3. There is no need to create data for operating the ICE. Debugging is faster. 4. Simulations can be performed without having to develop Emulator ICs. Development of application software for a core CPU such as a DSP is facilitated. The software required to check the operation of the peripheral circuits is made by using the C language. The circuit operation confirmation software is generally simple.

[Brief description of the drawings]

FIG. 1 Y = one second delay (A and B)

FIG. 2 is a flowchart of the first embodiment 1: registration of input / output variables 2: synchronization of a simulator and an application

FIG. 3 Simulation input file 1: Initial value setting of A and B inputs 2: Confirmation of Y output after 1100 mSec 3: Setting of A and B inputs to 1: 4: Confirmation of Y output after 500 mSec 5: 600 mSec Check Y output later

FIG. 4 is a flowchart of the second embodiment 1: registration of input / output variables 2: synchronization of simulator and application

[Fig. 5] Linking and execution of simulator 1: Interface with simulator 2: Simulator library 3: Execution program linked with simulator 4: Simulator input file SimIn. txt 5: Record in simulation output file 6: RTOS library

FIG. 6 is a pseudo code in C language according to the second embodiment.

FIG. 7 is a simulator input file according to the second embodiment.

FIG. 8 is an embodiment using a one-chip microcomputer.

FIG. 9: Simulation input file for one-chip microcomputer 1: Simulation EF

FIG. 10: Source program of one-chip microcomputer 1: Interface with simulator

FIG. 11: Simulation result 1: Simulation error

FIG. 12 is a time chart display of a simulation result 1: simulation error

FIG. 13: Profile result 1: Coverage

Claims (8)

[Claims] An output value is controlled in response to a change in an input value.
In the operation check of the software program to be changed, ・ The input value storage means is provided to store the time and value at which the input changes ・ The output value and time scheduled as a result of the program responding to the input value are stored When the operation time of the program reaches the time recorded in the input value storage means, the input value of the time stored in the input value storage means is input to the program. A means for reflecting the change in the value to the operation of the program is provided.When the operation time of the program reaches the time recorded in the storage means for the expected output value, the scheduled output value recorded And a means for comparing an output value of a result of the operation of the program with the program. 2. The program operation check method according to claim 1, wherein the program operation check is performed using the number of repetitions of processing instead of time. 3. The program according to claim 1, further comprising storage means for storing a time and a value at which an input variable in the program changes in addition to an external input variable of the program. How to check the operation. 4. The program according to claim 1, further comprising storage means for storing a time and a value at which an output variable in the program changes in addition to an external output variable of the program. How to check the operation. 5. A storage means for storing not only input values but also subroutines (functions) in the program and a time for calling them. ・ A means for calling the subroutine when the operation time of the program reaches the time is provided. A method for confirming the operation of a program according to claim 1, characterized in that: 6. The method according to claim 1, further comprising storage means for storing an output variable value determined as a result of the operation result of the program and a time when the output variable value has changed. . 7. A medium on which a program having the function of claim 1 is recorded. 8. A medium recording a program having at least one function according to claims 2 to 7 in addition to claim 7.