JP2000267898A - Program execution history recorder and recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To make an MSC in which a hierarchical structure on design philosophy is shown correspond to execution history by considering the hierarchical structure on the design philosophy of an object-oriented programming and recording the execution history. SOLUTION: An ID correspondence table preparing block 11a prepares an ID correspondence table where an object, a method and an identification number are made to correspond to one another from object information 22. A probe embedding block 11b embeds a probe into a source program 21 on the basis of the ID correspondence table. Then, an execution history recording block 11e executes a program which becomes an execution format in a compile block 11c and into which the probe is embedded and also records execution history obtained by considering a hierarchical structure owned by a scenario on the basis of sub scenario information in scenario information 23 converted into an identification number by a scenario information conversion block 11d.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a technique for recording the execution history of an object-oriented program.

[0002]

2. Description of the Related Art In recent years, object-oriented programming has been proposed and implemented for the purpose of reusing programs. Object-oriented refers to the idea of proceeding with work focusing on the operation target as when a human is acting.
It is modeled on a computer system. In this object-oriented programming, the processing of a program is considered in units of objects.

[0003] In other words, an object is a software module in which data and a program (hereinafter, referred to as a "method") that is a procedure for processing the data are grouped together. In object-oriented programming, all functions of the program are implemented as components. An object is prepared for each unit function such as each unit.
Then, in the object-oriented programming, each object is connected using the concept of message transmission and reception between objects, that is, so-called message communication between objects.

[0004] In the following description, an operation expression using an object as a subject such as "the object ..." or "the object ..." is actually operated by the CPU of the computer system according to the object ( In other words, this is realized by the CPU executing the method of the object).
Further, “the object operates” indicates that the CPU of the computer system executes the method of the object.

As described above, by encapsulating (encapsulating) a method as a processing procedure and data to be processed, it is possible to reuse an object in creating a program. Therefore, on the premise that the unit function is realized by each object, the object-oriented program design is to design the connection of objects by sending and receiving messages between objects. In the object-oriented programming design, a design using a message sequence chart (hereinafter referred to as “MSC”) as shown in FIG. 12 is generally performed.

[0006] The MSC shown in FIG. 12 shows a combination of four objects Obj1, Obj2, Obj3, and Obj4. The MSC indicates an object by a vertical line and a message from the object to the object by an arrow drawn between the vertical lines, and indicates that messages are transmitted and received in order from the upper arrow. That is, in FIG. 12, first, the object Obj1 outputs the message MSG1 to Obj2, and then the object Obj2
Outputs message MSG2 to Obj3, then object Obj3 outputs message MSG3 to Obj4, then object Obj4 outputs message MSG4 to Obj3, and finally object Obj3
The message MSG5 is output to bj1. In each object, a method is activated according to the received message, and the next message is output to another object based on the method.

[0007] Such an operation sequence of the objects, that is, an order of sending and receiving messages of the objects is called a "scenario". That is, in the object-oriented program design, this scenario is designed. Therefore, in the test of an object-oriented program, a unit test for checking the function of each object using a so-called white-box test method and whether each object operates according to a scenario expressed in the MSC, that is, as designed, An integration test that checks whether a message is sent and received between objects is mainly used.

[0008]

Incidentally, the above-mentioned scenario sometimes has a hierarchical structure based on the design concept. For example, a scenario for realizing a certain function includes:
In other words, a scenario of a lower hierarchy (hereinafter, referred to as a “sub-scenario”) for realizing a part of the function is included.

Since such sub-scenarios are usually designed separately as one scenario, when designing a scenario having a hierarchical structure, the order of message transmission and reception of objects corresponding to the sub-scenarios in the lower hierarchy is considered. Is not designed. That is, the MSC indicating the sub-scenario
Are separately prepared as shown in FIG. 13B, for example, in the MSC indicating a scenario having this sub-scenario in a lower layer, for example, as shown in FIG. It is described as

On the other hand, consider a case where a process based on a program created based on a scenario is executed and an execution history of the program is recorded. 2. Description of the Related Art Conventionally, there is known an apparatus that records an execution history of a program for each execution level in order to test whether the program operates according to a design document. For example, the apparatus disclosed in Japanese Patent Application Laid-Open No. 9-259011 inserts data for history recording at the entry and exit of a function, records the history of each function, and devises a method of displaying the recorded execution history. This makes it possible to take correspondence with the source program.

However, the object-oriented program itself created based on the scenario does not express the hierarchical structure of the design concept that appears in the MSC indicating the scenario. Therefore, when the execution history is recorded using the conventional apparatus, a hierarchical structure based on the design concept is not represented in a series of execution histories. For example, when the execution history is recorded using a conventional device, it is conceivable that the execution order of the methods may be listed. For this reason, it is not clear which part of the series of execution histories is a part corresponding to a sub-scenario in a lower hierarchy, and an MSC indicating a scenario having a hierarchical structure and a sub-scenario in a lower hierarchy of a scenario having a hierarchical structure There arises a problem that it cannot be associated with an MSC indicating a scenario.

According to the present invention, the execution history is recorded in consideration of the hierarchical structure on the design concept of the object-oriented programming.
An object is to enable association between C and an execution history.

[0013]

In the program execution history recording apparatus of the present invention, the execution means executes processing based on an object-oriented program composed of objects subdivided for each unit function. I do. The history recording unit records a history of message transmission / reception between objects generated by the execution of the process by the execution unit.

The above-described program is created based on a scenario showing a procedure for transmitting and receiving a message between objects. Here, the scenario has a hierarchical structure based on the design concept. As described above, the hierarchical structure refers to a structure based on a design concept in which a scenario for realizing a certain function includes a scenario for realizing a part of the function. It is assumed that this scenario includes a sub-scenario which is a scenario of a lower hierarchy.

In the present invention, in particular, the history recording means determines the message transmission / reception corresponding to the sub-scenario based on the sub-scenario information which is information for specifying the message transmission / reception corresponding to the sub-scenario. The message transmission / reception history between objects is recorded in a format in which the corresponding message transmission / reception history can be distinguished from other histories.

Here, "other histories" refers to histories corresponding to the scenario, excluding the histories corresponding to the sub-scenarios. In addition, "recording in a distinguishable format" may be specifically defined as the following (1) to (3). (1) It is conceivable to record the history corresponding to the sub-scenario together with other histories in a format in which the history corresponding to the sub-scenario can be specified. As a format in which the history corresponding to the sub-scenario can be specified, for example, a predetermined marker may be recorded at the beginning and end of the history corresponding to the sub-scenario in a series of histories.

Since there may be a plurality of sub-scenarios in the lower hierarchy of the scenario, information that can specify the sub-scenario such as a number assigned to the sub-scenario at the time of design is included in the sub-scenario information. It is advantageous to record information that can identify a scenario together with the above-described indicator, since it is possible to determine which sub-scenario corresponds to each history corresponding to a different sub-scenario.

(2) It is conceivable to record the history corresponding to the sub-scenario and another history separately. For example, they are recorded in separate files. In addition, for example, recording is performed separately in the same file. As described above, as a conventional technique, an object binding test based on a sub-scenario usually includes an M which indicates the contents of a sub-scenario prepared separately from the MSC indicating the scenario.
This is because it is performed using SC. Therefore, if such separate recording is performed, the history corresponding to the sub-scenario will correspond to the MSC indicating the content of the sub-scenario, while the other history indicates the MSC indicating the scenario.
This corresponds to C. As a result, the execution history and M
SC can be easily associated with.

(3) It is conceivable to record only other histories. In a situation where an object binding test based on a sub-scenario has already been performed, it is sufficient to determine whether or not the object is operating according to the MSC that indicates the scenario and the content of the sub-scenario is not described. Therefore, in this case, there is no need to record the history corresponding to the sub-scenario.

As described above, according to the program execution history recording apparatus of the present invention, the history corresponding to the sub-scenario is distinguished from other histories, so that the MSC reflecting the execution history and the hierarchical structure of the design concept is reflected. Can be easily associated with. By the way, as described above, the history recording unit determines the message transmission / reception corresponding to the sub-scenario based on the sub-scenario information for specifying the message transmission / reception corresponding to the sub-scenario. do it.

As a premise, it is assumed that the sub-scenario information is information for specifying a method related to start / end of message transmission / reception corresponding to the sub-scenario. At this time, the history recording means determines the start / end of message transmission / reception corresponding to the sub-scenario depending on whether the executed method is the method specified in the sub-scenario information, and as a result, What is necessary is just to comprise so that message transmission / reception corresponding to a scenario may be determined.

FIG. 13 shows “methods related to start / end of message transmission / reception corresponding to sub-scenario”.
The sub-scenario specifically shown in the MSC of (b) will be described as an example. "Start of message transmission / reception corresponding to sub-scenario" refers to object Obj in FIG.
2 means transmission and reception of message MSG6 from Obj3.
The “method related to the start of message transmission / reception” refers to the method of Obj2 that outputs message MSG6 or the method of Obj3 activated by MSG6.

The same applies to the "method for ending the message transmission / reception corresponding to the sub-scenario".
That is, the “end of message transmission / reception” includes “
The transmission / reception of the message MSG8 in (b) corresponds to the “method related to the end of message transmission / reception”.
The method of Obj4 that outputs SG8 or the method of Obj3 activated by MSG8 corresponds to this.

As the "information for specifying a method", for example, when the method name is unique among the objects, the use of the method name can be considered as an example. For example, if it is determined that the start of message transmission / reception based on the sub-scenario is determined by the method name of the method for outputting a message, in the example of FIG. 13B, the method name of the object Obj2 that outputs the message MSG6 to the sub-scenario information Will be recorded. At this time, the history recording unit compares the executed method name with the method name recorded in the sub-scenario information, and determines the start of the sub-scenario when they match.

When specifying the method name of an executed method, the history recording means may be configured to specify the method name based on, for example, a message transmitted and received. However, in this case, it is necessary to consider a message delivery structure, and it is difficult to apply the method to an object-oriented program realized by, for example, a function call.

Therefore, assuming that the computer system is configured to function as history recording means by executing processing based on a program, the method of each object can be used as a processing step as history recording means or as a history recording means. A recording step, which is a processing step for calling the above processing, may be provided, and information for specifying the method may be recorded in the recording step provided for each object method. With this configuration, the history recording unit can be configured without considering the message delivery structure.

It is conceivable that the above-mentioned recording step is inserted into a method as a source program by a user using an editor or the like, for example, but when the number of methods increases, it takes time and increases the number of work steps. . Therefore, it is further configured to include a recording step insertion unit,
Preferably, the recording step insertion means inserts a recording step into the created program. This eliminates the need for the user to manually insert a recording step for each method, thereby improving user convenience.

Information for specifying the method is as follows:
As described above, if the method name of each object is unique, a method name may be used as an example. However, considering that the method name of each object is not necessarily unique, and that a long method name exists in, for example, the C ++ language, information for specifying the method is described as follows.
It is preferable that the identification number is assigned based on a predetermined correspondence.

For the "predetermined correspondence", for example, "0", "1", "2",.
.. Are allocated, and method IDs “0”, “1”, “2”,... (Hereinafter simply referred to as “OID”) are assigned to the methods of each object. Also described as "MID".)
For example, it is conceivable to create by assigning. That is, as shown in FIG.

Based on such a correspondence, for example, the method eacct_cut shown in FIG.
And MID, and can be represented by an identification number (1, 0). According to this correspondence relationship, even if different objects have methods with the same name, a unique identification number corresponds to each method.

The history recording means may record, for example, a message delivery source object, a message delivery destination object, and a method activated by the message as a message transmission / reception history.
In this case, for example, if the OID of the delivery source object, the OID of the delivery destination object, and the MID of the method are recorded, compared to recording the object name or the method name as it is, for example, a file for recording the execution history is used. Can be reduced in size. Further, when the execution history is displayed on the screen, the possibility that the execution history is displayed over any number of screens can be reduced.

The correspondence between the method and the identification number as described above may be created by the user. However, if there is list information of the object names and the method names at the program design stage, the correspondence creation means is further provided. May be provided. The correspondence creating means creates the correspondence between each method and the identification number from the list information of the object name and the method name. By doing so, the convenience of the user is further improved.

By the way, it is conceivable that the history recording means records the message delivery source object as a message transmission / reception history together with the message delivery destination object and the method activated by the message as described above. In this case, the message delivery source object may be specified based on, for example, a message to be transmitted / received. However, it is necessary to consider a message delivery structure. For example, the message delivery source object is applied to an object-oriented program realized by a function call. hard.

Therefore, assuming that message transmission / reception between objects is realized by a so-called function call method, every time a message is transmitted / received, a method activated by the message transmission / reception corresponds to the method. It is conceivable to configure the history recording means to record information for identifying the object, and to delete the information recorded last from the last recorded information every time there is a callback from the method of the object. Can be That is, when a message is sent / received, information for specifying an object corresponding to the activated method is stacked. Therefore, when a method of another object is activated from the method, information for specifying an object corresponding to the activation source method is stacked.
As a result, the message delivery source object can be specified without considering the message delivery structure. At this time, it is of course possible to use, for example, a unique identification number for the object as information for specifying the object.

Further, assuming that the message transmission / reception between objects is realized by the function call method, the number of message transmission / reception and the number of callbacks from the method activated by the message transmission / reception are determined. At the same time, the history recording means may be configured to end the recording of the history. In this way, a history corresponding to an arbitrary part (scenario) in a series of programs can be recorded.

The function of realizing each unit of the execution history recording device in a computer system can be provided, for example, as a program activated on the computer system side. For such a program,
For example, floppy disk, magneto-optical disk, CD-
It can be used by recording it on a computer-readable recording medium such as a ROM or a hard disk, loading it into a computer system as needed, and starting up. Alternatively, the program may be recorded in a ROM or a backup RAM as a computer-readable recording medium, and the ROM or the backup RAM may be incorporated in a computer system and used.

[0037]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is an explanatory diagram showing a schematic configuration of an execution history recording system including an execution history recording device 10 that embodies a program execution history recording device of the present invention.

The execution history recording system according to the present embodiment includes an execution history recording device 10 and a server 90. The execution history recording device 10 includes a device main body 11, a keyboard 13 as input means, and a monitor 12 as display means.
, A so-called computer system.

On the other hand, the server 90 is also a computer system, and includes an apparatus main body 91 and a monitor 91 as display means.
It has. A large-capacity hard disk device 20 is connected to the device main body 91. The hard disk device 20 has a source program 21 and object information 2.
2 and scenario information 23 are recorded.

The source program 21, the object information 22, and the scenario information 23 are created by the user and recorded on the hard disk device 20 of the server 90. For example, the user creates the source program 21 in the server 90 via a terminal (not shown), creates the object information 22 and the scenario information 23 together therewith,
In other words, the information is recorded on the hard disk 20 of the server 90.

The execution history recording device 10 of the present embodiment reads these three pieces of information from the server 90 and records the execution history based on these three pieces of information. So first,
These three pieces of information will be described using the MSC shown in FIGS. 7A and 7B as an example.

The source program 21 is an object-oriented program for recording an execution history. This source program 21 is created based on the MSC shown in FIGS. 7A and 7B. The scenario shown here is for realizing a predetermined function of initializing the engine control software. this is,
This is a part of the process executed first when the engine is started.

The source program 21 created based on this scenario is composed of five objects. That is, a scheduler object (elm), an air conditioner cut object (eacct), an engine ON / OFF output object (eaengoo), an adjust object (eadj), and an SRAM manager object (gasram). Note that the object name described in the parentheses is the object name described in the source program 21. The source program 21
Are managed in the server 90 as a plurality of files in object units. The file name of each file is an object name.

Next, each object will be briefly described. The scheduler object issues various processing requests to other objects at appropriate timing. In this scenario, an initialization request for making each object operable is issued.

The air conditioner cut object controls the amount of power transmitted from the engine to the air compressor to adjust the indoor temperature. The engine system ON / OFF output object controls the level (ON or OFF) of the output terminal of the engine ECU. That is, when there is a request to turn the level of a predetermined output terminal ON or OFF, the level of the output terminal is inverted based on the request.

The adjust object manages the number of times the engine has been started. The SRAM manager object records and holds the contents of the memory in the backup RAM when the ignition key is turned off. When there is a request to refer to or update the contents of the backup RAM, the contents of the backup RAM are referred to and updated.

Next, the MSC shown in FIGS.
, The operation of each of the above-described objects will be described. First, the scheduler object starts operating (that is, the CPU starts executing the method of the scheduler object). Then, the scheduler object outputs an initialization request message to the air conditioner cut object. According to this message, the method (eacct_pwon) of the air conditioner cut object is activated.

By executing this method (eacct_pwon), the air conditioner cut object performs initialization processing of the air conditioner cut object itself, and thereafter transmits an air conditioner clutch disengagement request message to the engine system ON / OF.
Output to F output object. According to this message, the method (gaacmg_cut) of the engine ON / OFF output object is started.

By executing this method (gaacmg_cut), the engine system ON / OFF output object turns off the air conditioner clutch output terminal of the engine ECU. As a result, when the engine is started, the power transmission amount of the engine to the air compressor is cut.

Subsequently, the scheduler object outputs an initialization request message to the adjust object. The adjust object method (eadj_pwon) is invoked according to this message. This method (ead
By executing j_pwon), the adjustment object performs initialization processing as shown in FIG. In this process, the number of times of starting the engine is incremented. Then, the adjust object outputs a learning value write request message to the SRAM manager object. According to this message, the method (u1g_gasram_write) of the SRAM manager object is activated.

By executing this method (u1g_gasram_write), the SRAM manager object updates the number of engine starts stored in the backup RAM. The processing based on the source program 21 described above is an ideal operation according to the MSC shown in FIGS. 7A and 7B. In addition, this source program 21
Is described in a functional language, and a message as a processing request is realized using a so-called function call method.

In this embodiment, when the processing based on the source program 21 is executed, each object
The execution history recording device 10 executes a process based on the source program 21 and records a history of message transmission and reception between objects for the purpose of determining whether or not the operation is performed as described above.

By executing the processing based on the source program 21, each object performs a series of operations shown by two MSCs in FIGS. 7 (a) and 7 (b). On the other hand, the scenario of initializing the engine control software has a hierarchical structure based on the design concept,
It includes a sub-scenario, which is a lower-level scenario for realizing the learning value writing function. This is as shown in FIG. Since such a sub-scenario is also one scenario for realizing a predetermined function, it is necessary to design the sub-scenario shown in FIG.
In the MSC shown in (a), the contents of the sub-scenario are shown in a black box, and as shown in FIG. 7 (b), the MSC showing this sub-scenario is generally prepared separately.

Therefore, the history corresponding to the sub-scenario in the series of execution histories of the source program 21 becomes an unnecessary history for comparison with the scenario chart shown in FIG. 7A, for example. Therefore, the execution history recording device 10 of the present embodiment records the execution history of the source program 21 in consideration of the hierarchical structure of the design concept of such a scenario.

Information for considering the hierarchical structure of the design concept of the scenario is scenario information 23. Therefore, next, the scenario information 23 will be described. As shown in FIG. 6A, the scenario information 23 includes information on a sub-scenario in a lower hierarchy of the scenario. The sub-scenario information includes a number uniquely assigned to the sub-scenario, an object name of the start (end) of the sub-scenario, and a method name of the start (end) of the sub-scenario. This sub-scenario information corresponds to “sub-scenario information” described in the claims.

In the MSC shown in FIG. 7A, according to the initialization request message from the scheduler object,
The sub-scenario is started / terminated by executing the method (eadj_pwon) of the adjust object. Therefore, as shown in FIG. 6A, the object name at the start (end) of the sub-scenario is the object name “adj” of the adjustment object, and the method name is the method name “eadj_pwon” of the adjustment object.

Further, in the present embodiment, as described later, information for specifying an object or a method is an identification number based on an ID correspondence table. Information for creating the ID correspondence table is the object information 22. The object information 22 corresponds to M in FIG.
An object and a method existing in the SC are described, and as shown in FIG.
This is list information of each object name defined in No. 1 and a method name of the object.

The execution history recording apparatus 10 of the present embodiment reads the source program 21, the object information 22, and the scenario information 23, and considers the hierarchical structure existing in the scenario of the source program 21 as described above. Record the execution history.

Next, the operation of the execution history recording apparatus 10 of the present embodiment in the apparatus main body 11 will be described with reference to the explanatory diagram of FIG. As described above, the execution history recording device 10
In this document, information for identifying an object or a method is used as an identification number. Therefore, in the ID correspondence table creation block 11a, the input object information 22
To create an ID correspondence table.

The creation of the ID correspondence table is described in FIG.
Unique object IDs (OIDs) “0”, “1”, “2”,... Are sequentially assigned to the object names described in the object information shown in FIG. Method ID "0", "1", "2", ... for the method name
(MID). The table in FIG. 3A is converted like the table shown in FIG. Therefore, the object is specified by the OID. On the other hand, the method is specified by the OID and the MID.

Next, the probe embedding block 11b
Performs embedding of a probe in the source program 21. Here, the probe is a processing step as a “recording step” for calling a process for recording an execution history, and is inserted at the beginning and end of a function defining a method of each object. In the probe embedding process, by referring to the ID correspondence table described above,
OID and MID for specifying the method are also inserted as information for recording the execution history.

Here, the probe embedding process will be described with reference to the flowchart shown in FIG. First, in a first step S100, a file name is set as an object name. As described above, in the server 90, the source program 21 is managed in a file for each object, and the file name is an object name. Therefore, in this process, the file name is extracted as the object name.

At S110, the object name extracted at S100 and the ID correspondence table creation block 1
A comparison is made with the ID correspondence table created in 1a (see FIG. 3B). Then, in the next S120, it is determined whether or not the object name matches the object name described in the ID correspondence table. If it is determined that they match (S120: YES), the process proceeds to S130. On the other hand, when it is determined that they do not match (S120:
NO), an error is displayed in S220, and then the present probe embedding process ends. The error information is
It is displayed on the monitor 12 of the execution history recording device 10.

In S130, the object ID (OI) corresponding to the object name is determined based on the ID correspondence table.
D). Next, in S140, one method name in the file (in the object) is extracted. Continue S15
At 0, the method name extracted in S140 is compared with the ID correspondence table created in the ID correspondence table creation block 11a (see FIG. 3B).

In the next S160, it is determined whether or not the method name matches the method name described in the ID correspondence table. If it is determined that they match (S16
0: YES), and proceeds to S170. On the other hand, when it is determined that they do not match (S160: NO), an error display is performed in S220, and then the present probe embedding process ends. As described above, the error information is displayed on the monitor 12 of the execution history recording device 10.

In S170, a method ID (MID) corresponding to the method name is obtained based on the ID correspondence table. In S180, the head and tail of the method described in the file are extracted. Then, in the next S190, probes are inserted at the beginning and end of the extracted method. In the present embodiment, STAR is added at the beginning of the method.
A processing step for calling the T function is embedded, and a processing step for calling the END function is embedded at the end of the method. Since the execution history is recorded by the START function and the END function, the OID acquired in S130 and the MID acquired in S170 are used as information for specifying the method for calling the START function and the END function. Is an argument. Thereby, ST
The ART function and the END function can specify a method and an object having the method.

At S200, it is determined whether probes have been embedded in all the methods in the selected object. Here, when it is determined that the probes are embedded in all the methods (S200: YES),
Move to S210. On the other hand, when it is determined that there is a method in which the probe is not embedded (S200: N
O), repeat the processing from S140.

In S210, it is determined whether or not processing for all objects has been completed. Here, when it is determined that the processing for all objects has been completed (S210:
YES), the probe embedding process ends. on the other hand,
If it is determined that there is an object that has not been processed (S210: NO), the processing from S100 is repeated.

Next, the probe embedding process will be described more specifically with reference to FIG. FIG. 5A is an explanatory diagram showing a method before the probe embedding process is performed, while FIG. 5B is an explanatory diagram showing a method after the probe embedding process is performed. The source program 21 is managed as a file for each object as described above. FIG. 5A shows files corresponding to the scheduler object (elm) and the air conditioner cut object (eacct). The file names are elm and eacct, respectively.

When the above-described probe embedding process is executed, first, the file name elm is extracted as an object name (S100 in FIG. 4). Then, FIG.
Is compared with the object name described in the ID correspondence table shown in (S110), and if they match (S120:
YES), OID corresponding to object name elm
“0” is acquired (S130). Subsequently, the method name elm_pwon in the file (in the object) is extracted (S140), and is compared with the method name described in the ID correspondence table shown in FIG. 3B (S150). If they match (S160: YES), the method name el
MID “0” corresponding to m_pwon is acquired (S17)
0). Next, the start and end of the method (elm_pwon) are extracted (S180), and a processing step for calling the START function and a processing step for calling the END function (steps indicated by the symbol A in FIG. 5B) Is embedded (S190). At this time, the acquired OID “0” and M
ID “0” is used as an argument.

Then, the same process is performed for another method of the scheduler object, and when the processes for all the methods of the scheduler object are completed (S200: YES), the same process is performed for the other objects. As a result, a processing step as a probe is embedded at the beginning and end of the method of each object. For example, the method (eacct_pwon) of the air conditioner cut object (eacct) includes "ST
ART (1,0) "and" END (1,0) "are embedded, and the air conditioner cut object (eacc
The method (eacct_cut) of (t) includes “SRART (1,
1) ”and“ END (1, 1) ”are embedded (see FIG. 5B).

After the probe is embedded for the method of each object in the probe embedding block 11b, the source program 21
At 1c, it is converted into an executable form. Next, scenario information 2
3 will be described.

The scenario information conversion block 11d converts the input scenario information 23 into an ID correspondence table created by the ID correspondence table creation block 11a (FIG. 3B).
Conversion). That is, as described above, the scenario information 23 includes the sub-scenario information shown in FIG. 6A, that is, the number uniquely assigned to the sub-scenario, the object name of the start (end) of the sub-scenario, and the start of the sub-scenario. (End) method name is described. Therefore, in the scenario information conversion block 11d,
The object name and the method name as the sub-scenario information are associated with the OI in the ID correspondence table.
D, MID. That is, the object name “eadj” in the scenario information 23 shown in FIG.
Is converted as OID "2" and the method name "ea
dj_pwon ”is converted as MID“ 0 ”(FIG. 6
(B)). The number assigned to the sub-scenario is a sub-scenario ID.

Then, in the execution history recording block 11e, a process based on the program converted into the execution format in the compilation block 11c is executed, and based on the converted scenario information 23 output from the scenario information conversion block 11d, Record the history of sending and receiving messages between objects. This execution history recording processing is realized by processing of a START function and an END function called from each method.

Then, processing of the START function and EN
The processing of the D function will be described in order. First, the SRART function processing will be described based on the flowchart of FIG. First,
In step S300, it is determined whether the storage number is “0”. This stored number is used to determine the start / end of the scenario.
The scenario information is included together with the sub-scenario information, and an instruction to set the storage number to “0” is recorded (see FIG. 6B). Therefore, immediately after the start of the execution of the program, the stored number becomes “0”, and the next time the stored number becomes “0”, it means the end of the scenario. As a result, a history corresponding to an arbitrary scenario of the source program 21 can be recorded. Here, when it is determined that the number of stored items is “0” (S300: YES),
In S310, a log indicating the start of the scenario is recorded, and in S35
Move to 0. On the other hand, when it is determined that the number of stored pieces is “0” (S300: NO), the process proceeds to S320.

At S320, a message log is recorded. The message log includes a message delivery source object ID (delivery source OID), a message delivery destination object ID (delivery destination OID), and a method ID (M
ID) is recorded. Where destination OID and MID
Is the OID and MID that are the arguments of the function. Also,
The delivery source OID is read from a stack area described later.

At S330, it is determined whether the OID and the MID are both IDs indicating the start of the sub-scenario. This is determined based on the scenario information 23 from the scenario information conversion block 11d. Here, if it is determined that both the OID and the MID are IDs indicating the start of the sub-scenario (S330: YES), a sub-scenario start log is recorded in S340, and thereafter, the process proceeds to S350. The sub-scenario start log includes a start indicator “S” and a sub-scenario ID. On the other hand, OID or MID
If it is determined that at least one of the IDs is not the ID indicating the start of the sub-scenario (S330: NO), S3
The process proceeds to S350 without executing the process of S40.

In S350, OIDs are stacked. This is because, when the START function processing is once completed, a message is output, the method is started, and when the START function processing is executed again, the OID is set in the stack area so that the object of the delivery source of the message can be specified. This is the process of recording.

At S360, the stored number is incremented, and then the present START function processing is terminated. next,
The END function processing will be described based on the flowchart of FIG. First, in the first step S400, the stored number is decremented. In subsequent S410, it is determined whether or not the storage number is “0”. This storage number is for determining the start / end of the scenario as described above,
Immediately after the start of the execution of the program, the stored number is always “0”. Then, the next time the stored number becomes “0”, it means the end of the scenario. If the number of stored items is “0” (S410: YES), a scenario end log is recorded in S420, and then the END function process ends. On the other hand, if the storage number 格納 “0” (S410: NO),
Move to 430.

In S430, it is determined whether or not both the OID and the MID are IDs indicating the end of the sub-scenario.
This is determined based on the scenario information 23 from the scenario information conversion block 11d. Where OID and M
If it is determined that both IDs are IDs indicating the end of the sub-scenario (S430: YES), a sub-scenario end log is recorded in S440, and then the END function processing ends. The sub-scenario end log is an end indicator “E”. On the other hand, if it is determined that at least one of the OID and the MID is not an ID indicating the end of the sub-scenario (S430: NO), the END function process is terminated without executing the process of S440.

The START function processing and the END
Function processing is called from each method,
The execution history will be recorded. Further, the START function processing and the END function processing will be specifically described with reference to FIGS. FIG. 8 is an explanatory diagram showing the source program 21 after the probe is embedded in the source program 21 of the present embodiment created based on the MSC shown in FIGS. 7A and 7B. In addition,
In each method, predetermined processing is performed in addition to the function call shown in FIG. 8, but this processing is not shown. FIG. 11 is an explanatory diagram showing a recorded execution history.

In FIG. 8, first, the method (elm_pwon) of the scheduler object (elm) is executed. Then, the START function is called. The arguments at this time are OID “0” and MID “0”. At this stage, the storage number is “0” based on the scenario information 23. Therefore, a scenario start log is recorded as shown by the symbol A in FIG. 11A (S31 in FIG. 9).
0), the OID “0” is stacked (S350), and the storage number is incremented to “1” (S3).
60).

Subsequently, the scheduler object (el
The method (eacct_pwon) of the air conditioner cut object (eacct) is started from the method (elm_pwon) of (m). This is as shown in FIG. Then, STA
The RT function is called. The argument at this time is OID
“1” and MID “0”. At this time, since the storage number is “1”, a message log is recorded following the scenario start log as shown by a symbol B in FIG. 11A (S320 in FIG. 9). And OID "1", M
Since the ID “0” is not an ID indicating the start / end of the sub-scenario (S330: NO), the OID “1” is stacked (S350), and the storage number is incremented to “2” (S360).

Subsequently, the air conditioner cut object (ea)
cct) from the method (eacct_pwon) to the engine system ON
The method (gaacmg_cut) of the / OFF output object (gaengoo) is activated. This is as shown in FIG. Then, the START function is called. The arguments at this time are OID “3” and MID “0”. At this time, since the storage number is “2”, a message log is recorded as indicated by a symbol C in FIG. 11A (S320 in FIG. 9). And OID "3", MID
Since “0” is not an ID indicating the start of the sub-scenario (S3
30: NO), OID "3" is stacked (S35)
0), and the storage number is incremented to “3” (S360). In this method (gaacmg_cut), after a predetermined process, the END function is called. Argument is OI
D “3” and MID “0”. Therefore, the storage number is decremented to “2” (S40 in FIG. 10).
0). The storage number is “2” and the OID
Since “3” and MID “0” are not IDs indicating the end of the sub-scenario, negative determinations are made in both S410 and S430 in FIG.

When the execution of this method (gaacmg_cut) is completed, the method (eacct) of the air conditioner cut object (eacct) that started this method (gaacmg_cut)
t_pwon). As shown in FIG. Then, the END function is called. The argument is O
The ID is “1” and the MID is “0”. Therefore, the storage number is decremented to “1” (S40 in FIG. 10).
0). The storage number is “1”, and the OID
Since “1” and MID “0” are not IDs indicating the end of the sub-scenario, negative determinations are made in both S410 and S430 in FIG.

Then, the air conditioner cut object (e)
When the execution of the method (eacct_pwon) of the (acct) is completed, a callback is made to the method (elm_pwon) of the scheduler object (elm) that started the method (eacct_pwon). As shown in FIG.

Next, the scheduler object (el
The method (eadj_pwon) of the adjust object (eadj) is started from the method (elm_pwon) of (m). As shown in FIG. Then, START
The function is called. The argument at this time is OID
“2” and MID “0”. At this time, since the storage number is “1”, a message log is recorded as indicated by a symbol d in FIG. 11A (S32 in FIG. 9).
0). OID “2” and MID “0” are IDs indicating the start of the sub-scenario (see FIG. 6B). Therefore, as indicated by the symbol E in FIG. 11A, a sub-scenario start log is recorded following the message log (S3).
40). Then, the OID "2" is stacked (S35).
0), and the storage number is incremented to “2” (S360).

Subsequently, the adjustment object (ead
j) method (eadj_pwon) to SRAM manager object (gasram) method (u1g_gasram)
_write) is invoked. This is as shown in FIG.
Then, the START function is called. The arguments at this time are OID “4” and MID “0”. At this time,
Since the stored number is “2”, a message log is recorded as indicated by a symbol in FIG. 11A (S in FIG. 9).
320). Since the OID “4” and the MID “0” are not IDs indicating the start of the sub-scenario (S330: N
O), the OID “4” is stacked (S350), and the storage number is incremented to “3” (S3).
60). In this method (u1g_gasram_write), after a predetermined process, the END function is called. Argument is OID
“4” and MID “0”. Therefore, the storage number is decremented to “2” (S40 in FIG. 10).
0). The storage number is “2” and the OID
Since “4” and MID “0” are not IDs indicating the end of the sub-scenario, negative determinations are made in both S410 and S430 in FIG.

This SRAM manager object (g
When the execution of the method (u1g_gasram_write) of the asram) is completed, a callback is made to the method (eadj_pwon) of the adjustment object (eadj) that started the method (u1g_gasram_write). As shown in FIG. Then, the END function is called. The arguments are OID “2” and MID “0”. Therefore,
The storage number is decremented to "1" (S400 in FIG. 10). Since OID “2” and MID “0” are IDs indicating the end of the sub-scenario (see FIG. 6B), a positive determination is made in SS430 in FIG.
As shown by the symbol G in (a), a sub-scenario end log is recorded (S440).

This adjust object (eadj)
When the execution of this method (eadj_pwon) is completed, a callback is made to the method (elm_pwon) of the scheduler object (elm) that started this method (eadj_pwon). As shown in FIG. Then, the END function is called. Arguments are OID "0", MID
It is "0". Therefore, the storage number is decremented to “0” (S400 in FIG. 10). Therefore, S
An affirmative determination is made at 410, and a scenario end log is recorded as indicated by the symbol H in FIG.

The above is a specific execution history recording process using the START function and the END function. The data is recorded on the memory as shown in FIG. Here, returning to FIG. 2, the execution history recorded in the execution history recording block 11e in this way is displayed on the monitor 12 of the execution history recording device 10 by the monitor / external output block 11f, for example, the server 90 or the like. Output to an external device.

Next, the execution history recording apparatus 10 of the present embodiment
The effect exhibited by will be described. The execution history recording device 10 according to the present embodiment starts and ends the sub-scenario when executing each method based on the object ID (OID) of the sub-scenario start (end) and the method ID (MID) recorded in the scenario information 23. And a sub-scenario start log (shown by symbol E in FIG. 11A) and a sub-scenario end log (shown by symbol G in FIG. 11A) in the history of message transmission and reception between objects. Record That is, considering the hierarchical structure of the design concept of the scenario in the object-oriented programming, the execution history that matches the design concept is recorded. as a result,
An execution history based on a sub-scenario included in a series of execution history based on a scenario can be distinguished. For example, in FIG. 11A, an execution history indicated by a symbol is an execution history based on a sub-scenario. Therefore, the correspondence with the MSC, which is the design document, becomes clear, and the correspondence between the MSC and the execution history becomes easy. Further, since the sub-scenario ID is recorded as the sub-scenario start log together with the start indicator “S”, even if a plurality of sub-scenarios exist in the scenario, which history corresponds to which sub-scenario. It can be easily specified whether the history is history.

Further, the execution history recording device 10 of the present embodiment
Is an object ID (OID) and a method ID (MI
D) is used. Then, on the memory, FIG.
As shown in the table, the object ID and the method ID
To record the message log. This makes it possible to reduce the size of the file for recording the execution history, for example, as compared with recording the object name or method name as it is. Further, when the execution history is displayed on the monitor 12 of the execution history recording device 10, the possibility that the execution history is displayed over many screens can be reduced.

Further, the execution history recording device 10 of the present embodiment is configured to execute the object and method and the object ID (OI) for specifying the object and method.
D) and I indicating the corresponding relationship with the method ID (MID)
The D correspondence table (the table shown in FIG. 3B) is created from the object information 22, that is, the list information of the object names and the method names of the objects (the information shown in FIG. 3A). Then, based on the ID correspondence table, the scenario information 23 is converted, and a probe for recording an execution history is embedded in the source program 21. Therefore, if the user creates the object information 22 that is a list of the object names and the method names of the objects, there is no need to consider the correspondence between the objects, the methods, and the IDs. Therefore, it is convenient for the user.

Further, the execution history recording device 10 of the present embodiment
Then, a probe for recording the execution history is automatically embedded in the source program 21. Therefore, the user
There is no need to modify the source program 21 using an editor or the like, and the execution history can be obtained using the created source program 21 as it is.

The execution history recording device 10 of the present embodiment
The computer system included in the apparatus main body 11 is composed of an “executing unit”, a “history recording unit”, and a “processing step inserting unit”.
And "correspondence creating means". The processing shown in the flowcharts of FIGS. 9 and 10 corresponds to the processing as the history recording means, the processing shown in the flowchart of FIG. 4 corresponds to the processing as the processing step inserting means, and the ID correspondence in FIG. The ID correspondence table creation processing executed in the table creation block 11a corresponds to the processing as the correspondence creating means.

As described above, the present invention is not limited to such embodiments at all, and can be implemented in various forms without departing from the gist of the present invention. For example, in the execution history recording device 10 of the above embodiment, a sub-scenario start log indicating the start of a sub-scenario and a sub-scenario end log indicating the end of a sub-scenario are recorded in a series of execution histories to distinguish the history corresponding to the sub-scenario. It was a configuration that
For example, the execution history corresponding to the sub-scenario and another history may be recorded in separate files. It is also conceivable that the history corresponding to the sub-scenario is not recorded under the premise that the program based on the sub-scenario has already been tested.

[Brief description of the drawings]

FIG. 1 is an explanatory diagram illustrating an execution history recording system according to an embodiment.

FIG. 2 is an explanatory diagram showing a process in a device main body of the execution history recording device.

3A is a table showing object information, and FIG. 3B is an ID correspondence table showing correspondence of identification numbers.

FIG. 4 is a flowchart showing a probe embedding process.

FIG. 5 is an explanatory view specifically showing embedding of a probe.

FIG. 6A is an explanatory diagram showing scenario information;
(B) is an explanatory view showing scenario information converted based on the ID correspondence table.

FIG. 7 is an MSC of the program of the embodiment.

FIG. 8 is an explanatory diagram showing a combination of objects at a source program level.

FIG. 9 is a flowchart showing a START function process.

FIG. 10 is a flowchart showing an END function process.

FIG. 11 is an explanatory diagram showing a recording example of an execution history.

FIG. 12 is an explanatory diagram showing a design of an object-oriented program.

FIG. 13 is an explanatory diagram showing a hierarchical structure in a design concept of a scenario.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 10 ... Execution history recording device 11 ... Device main body 11a ... ID correspondence table creation block 11b ... Probe embedding block 11c ... Compile block 11d ... Scenario information conversion block 11e ... Execution history collection block 11f ... Monitor / external output block 12 ... Monitor 13 ... Keyboard 20 ... Hard disk device 21 ... Source program 22 ... Object information 23 ... Scenario information 90 ... Server 91 ... Device body 92 ... Monitor

Claims (13)

[Claims] An execution means for executing a process based on an object-oriented program composed of objects subdivided for each unit function, and a history of message transmission and reception between the objects caused by the execution of the process by the execution means. An execution history recording device comprising: a program that is created based on a scenario showing a procedure for transmitting and receiving a message between the objects, wherein the scenario has a hierarchical structure based on a design concept. Has the premise that a sub-scenario is included in the lower hierarchy of the scenario, based on the sub-scenario information that is information for specifying the message transmission / reception corresponding to the sub-scenario, Judge the message transmission / reception corresponding to the sub-scenario, and Said message transmission and reception of history corresponding to O in a format that can be distinguished from other history, execution history recording unit of a program, characterized in that it is configured to record the history of the message transmission and reception. 2. The execution history recording apparatus according to claim 1, wherein the history recording unit records the history corresponding to the sub-scenario together with the other histories in a format in which the history corresponding to the sub-scenario can be specified. An execution history recording device for a program, wherein 3. The execution history recording apparatus according to claim 2, wherein the history recording means is configured to record information for associating a history corresponding to the sub-scenario with the sub-scenario. Execution history recording device of the program to be executed. 4. The execution history recording device according to claim 1, wherein the history recording means is configured to separately record a history corresponding to the sub-scenario and the other history. An execution history recording device for a program. 5. The execution history recording device according to claim 1, wherein the history recording means is configured to record only the other history. 6. The execution history recording device according to claim 1, wherein the sub-scenario information is information for specifying a method related to start / end of the message transmission / reception corresponding to the sub-scenario. The history recording unit is configured to determine the start / end of the message transmission / reception corresponding to the sub-scenario depending on whether the executed method is the method specified in the sub-scenario information. A program execution history recording device, characterized in that: 7. The execution history recording apparatus according to claim 6, wherein a computer system functions as said history recording means by executing a process based on said program, and wherein a method of each of said objects is It has a recording step which is a processing step as a history recording means or a processing step for calling the processing as the history recording means, and the recording step provided for the method of each object includes a method for specifying the method. An execution history recording device for a program, wherein information is recorded. 8. The execution history recording apparatus according to claim 7, further comprising recording step inserting means for automatically inserting said recording step into said created program. Program execution history recording device. 9. The execution history recording apparatus according to claim 5, wherein the information for specifying the method is an identification number assigned based on a predetermined correspondence. Execution history recording device of the program to be executed. 10. The execution history recording device according to claim 9, further comprising: a correspondence relationship creating means for creating a correspondence relationship between each method and an identification number from the list information of each object and a method of the object. An execution history recording device for a program, comprising: 11. The execution history recording apparatus according to claim 1, wherein the message transmission and reception between the objects is realized by a function call method. Each time a message is sent or received,
In the method started by sending and receiving the message,
It is configured to record information for identifying an object corresponding to the method, and to delete the information sequentially from the last recorded information every time there is a callback from the method of the object. An execution history recording device for a program. 12. The execution history recording apparatus according to claim 1, wherein the message transmission and reception between the objects is realized by a function call method. An execution history recording device for a program, wherein the recording of the history is terminated when the number of times of message transmission / reception is equal to the number of callbacks from a method activated by the message transmission / reception. 13. A computer-readable recording medium in which a program for causing a computer system to function as each means of the execution history recording device according to claim 1 is recorded.