JPH08314752A - Object-oriented system development support device - Google Patents

Abstract

(57) [Abstract] [Purpose] The user can easily understand the behavior of the system when the object-oriented system is actually operated, that is, the behavior of the object. [Structure] This development support device is a development environment for an object-oriented system, and when an object-oriented system is actually started, the behavior of objects such as message exchange (exchange) between objects and object creation and deletion ( Behavior recognition unit 1 for recognizing behavior), a storage unit 2 for storing the behavior of the object recognized by the object behavior recognition unit 1 in a file F, and a behavior of the object stored in the file F by the storage unit for reading and outputting. Output means 3 for

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a development support device for an object-oriented system using object-oriented technology.

[0002]

2. Description of the Related Art Conventionally, in developing an object-oriented system, there have been tools for constructing an object model diagram, an event trace diagram, a data flow diagram, etc. necessary for system development. Also, as a tool that supports the implementation of the system, there was a tool that writes the definition of a class from an object model diagram to a file.

However, a tool for constructing an object model diagram, an event trace diagram, a data flow diagram, etc. is a tool for supporting the phase before the implementation of the system, that is, analysis and design, and the object model diagram. Tools such as writing class definitions from .. to a file support static data and pre-execution development stages of the system, and both tools provide debugging for system development, that is, an object-oriented system. It is not designed to debug (dynamic check) the temporal flow between objects when it is run in.

Conventionally, there is no effective debug tool for developing an object-oriented system. This is because in an object-oriented system, unlike the conventional waterfall, where the processing flows in one direction, the processing can be progressed by exchanging messages between objects, and the processing can be returned again. As a result, it is difficult to see where the current processing is being performed and what kind of data is being processed, and it is difficult to understand how the processing is progressing. On the other hand, in the object-oriented system, by using the class hierarchy peculiar to the object-oriented system, the inheritance function can be used to perform programming by the difference, but on the other hand,
What is described in the upper class does not need to be described in the lower class, so just looking at the lower class definition does not mean that all the attributes and methods of the class are understood. Due to. Therefore, for example, a technique for debugging an object-oriented system in the form of utilizing the C language debugging environment for the C ++ language debugging has not been established at present.

[0005]

SUMMARY OF THE INVENTION The present invention is directed to the development of an object-oriented system in which the user can easily understand the behavior of the system when the object-oriented system is actually operated, that is, the behavior of the object. The purpose is to provide a support device.

[0006]

In order to achieve the above object, the inventions according to claim 1 to claim 9
In an object-oriented system development environment, when an object-oriented system is actually started, an object behavior recognition means and an object behavior recognition means for recognizing behaviors of objects such as message exchange between objects and generation and deletion of objects The storage unit stores the behavior of the object recognized by the file in a file, and the output unit reads and outputs the behavior of the object stored in the file by the storage unit. As a result, the user can easily understand the behavior of the system when the object-oriented system is actually operated, that is, the behavior of the object.

In particular, according to the third aspect of the invention, since the object behavior recognition means focuses on a specific object and recognizes only the behavior related to the specific object, only necessary data can be handled in a concentrated manner. It is possible to omit unnecessary data.

In the invention according to claim 6, further,
The object behavior recognizing means and the data recognizing means have a second embedding means for embedding them in a file before the execution of the object-oriented system. The second embedding means analyzes the source program, Object behavior recognition means can be embedded by automatically recognizing behavioral points such as object creation and deletion, and message transmission. As a result, the user does not need to set the object behavior recognition means in this object-oriented system by himself, and the working efficiency of the user can be significantly improved.

Further, in the invention according to claim 7, the output means is adapted to visualize and display the contents stored in the file. For example, when presenting the behavior of the system to the user. , Display objects as squares or circles, and send and receive messages (exchange)
When presenting to the user, the user can visually and easily grasp the behavior of the system by displaying a link between the objects.

Further, in the invention according to claim 8, when the output means visualizes and displays the contents stored in the file, the output means successively responds to the operation of the system in response to the user's request. Display the operating status of the system. This makes it possible to present the behavior of the system to the user over time, and also to present the behavior of the system to the user by going back in time (that is, tracing the behavior of the system by going back in time). .

According to the ninth aspect of the invention, the behavior of the object is visualized and displayed simultaneously with the execution of the system. This allows the user to easily understand the behavior of the system in real time.

[0012]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram of an embodiment of an object-oriented system development support apparatus according to the present invention. Referring to FIG. 1, this development support device is a development environment for an object-oriented system, and when an object-oriented system is actually started, a message is exchanged between the objects.
An object behavior recognition means 1 for recognizing the behavior (behavior) of the object such as (interaction) and generation or deletion of the object; a storage means 2 for saving the behavior of the object recognized by the object behavior recognition means 1 in a file F; The output means 3 reads and outputs the behavior of the object stored in the file F by the storage means.

When the object behavior recognition means 1 recognizes the exchange of messages between the objects, the storage means 2 stores the recognized messages in a file in the order in which the exchanges are made between the objects, and outputs them. The means 3 is also adapted to output a message saved in a file.

Further, the object behavior recognition means 1 can be constructed so as to focus on a specific object and recognize only the behavior related to the specific object. When it is configured so that a specific object of interest can be designated, only necessary data can be handled centrally.

The development support apparatus further has a data recognition means 4 for recognizing the data in the message exchanged between the messages, and the storage means 2 further has the data recognition means for recognizing the data in the message. Is also stored in the file F, and the output means 3 further outputs the data in the message stored in the file F.

Further, the development support apparatus of the present embodiment includes the first embedding means 6 for embedding the storage means 2 in a predetermined portion of the object-oriented system before executing the object-oriented system, the object behavior recognition means 1, and And / or the data recognizing means 4 and the second embedding means 7 for embedding the data recognizing means 4 in a predetermined position of the object oriented system before the execution of the object oriented system.

That is, as the behavior (behavior) of objects during system execution, the object behavior recognizing means 1 having a function of recognizing the exchange of messages between objects, the generation and deletion of objects, etc., is the second embedding means 7 It is designed to be used by embedding it in a predetermined behavior part of an object. Further, the data recognizing means 4 having the function of recognizing the data in the messages exchanged between the messages is also the second embedding means 7.
Is used by being embedded in a place where messages are exchanged between objects.

More specifically, the first and second embedding means 6 and 7 automatically recognize the location of object behavior such as object generation and deletion, message transmission, etc. by analyzing the source program. Then, the data recognizing means 4 and the object behavior recognizing means 1 are embedded, and it is not necessary for the user to teach the location of the behavior of the object, and a function of automatically embedding them is provided.

Further, the output means 3 is adapted to visualize the contents stored in the file F and display them, for example. More specifically, the output unit 3 reads, for example, the file F in which the behavior of the object is written,
For example, the behavior of the system is displayed to the user. For example, objects are displayed in squares or circles, and links are displayed between objects when exchanging messages, so that the behavior of the system can be output in a form that the user can easily visually understand. There is.

As the output means 3, when the contents stored in the file F are visualized and displayed, for example, further, according to the user's request, in accordance with the operation of the system,
It may have a function of sequentially displaying the operating status of the system. This makes it possible to present the user with the behavior of the system over time, and trace the behavior of the system backwards in time.

The output means 3 may have a function of visualizing and displaying the behavior of the object simultaneously with the execution of the system. When the output means 3 has a function of visualizing the behavior of the object to the user during debugging while displaying the behavior of the object, the source program being debugged and the behavior of the visualized object are simultaneously advanced and displayed. It becomes possible.

Next, an example of the processing operation of the development support apparatus of this embodiment will be described. FIG. 2 is a flowchart showing an example of the processing operation of the development support device of this embodiment.

In the processing operation example of FIG. 2, first, step S
In 1, the source program is specified and the file structure of the development system is checked. As a result, the range of analysis of the source program performed by the development support device in the next step S2 and subsequent steps is limited.

Next, in step S2, the source program is analyzed. Specifically, in this step S2, recognition processing of user-defined classes and data types is performed as analysis processing of the source program. That is, in order for the development support environment to understand the behavior of objects,
Performs recognition processing of class definition and learns what attributes and methods the class has. In addition, since it is necessary to understand the status of message exchange (method invocation) between objects, the data type of the attribute of the class, the return value of the method, and the argument type of the method can be user-defined types. recognize.

Further, in the analysis processing of step S2, processing for generating and deleting objects in the program, calling methods, and recognizing the behavior of other objects is performed. At the same time, the first and second embedding units 6 and 7 perform a process of embedding a procedure for writing out the behavior of the object at a predetermined behavior. By performing this procedure, when the system is executed in step S3, behaviors such as object creation, deletion, and message exchange are saved in a file, and the dynamic data value at this time is also written in the file. It is possible to put out.

In this way, in steps S1 and S2, preprocessing for executing the system is performed, and thereafter, the system is executed in step S3. When the system is executed, the object behaves in various ways. The history of this behavior depends on the procedure of writing out the behavior of the object embedded in step S2 to a file.
That is, the object behavior recognizing means 1 (further, the data recognizing means 4) and the saving means 2 write the data into a file, and the actual data concerning the behavior of the object is saved in the file in time series.

After executing the system in this way, in step S4, the output means 3 is activated, and in step S3, the contents are read from the file in which the history of the behavior of the object is stored, and the object is communicated with the user. The behavior of is displayed sequentially or collectively, for example.

As described above, in the development support apparatus of this embodiment, the user can easily understand the behavior of the system when the object-oriented system is actually operated, that is, the behavior of the object and the like. , It is possible to debug (dynamic check) the temporal flow between objects when the object-oriented system is actually operated, and it is possible to perform debugging work easily and efficiently.

In the processing example of FIG. 2, the behavior of the object is output (displayed) after the system is executed, but the behavior of the object can be output (displayed) in real time as the system is executed. Is.

FIG. 3 is a flow chart showing an example of processing for displaying the behavior of an object in real time, similar to the execution of the system. In the processing example of FIG. 3, in steps S11 and S12, similarly to steps S1 and S2 of FIG. 2, the source program is designated, the program is analyzed, and the class definition and type defined by the user are recognized.
Embed a procedure that shows the behavior of the object.

Next, in step S13, the system is started. At this time, unlike the processing example of FIG. 2, the processing example of FIG. 3 outputs at this point in order to display the behavior of the object as the system is executed. The means 3 is activated. Then, a procedure indicating the behavior of the object with the execution of the system, that is, the object behavior recognition means 1
(Furthermore, the data recognition means 4) and the storage means 2 are activated,
The behavior of the object is sequentially displayed by the output means 3.

In step S2 of FIG. 2, the behavior of the object is saved in the file when the procedure indicating the behavior of the object is embedded, but in step S12 of FIG. 3, the behavior of the object is displayed in real time. Therefore, it is possible to provide a class or function for managing the behavior of the object in this system and use a procedure for notifying this class of the behavior of the object. Of course, step S1
In 2 as well, similar to step S2 of FIG. 2, the behavior of the object is stored in a file, the output means 3 is started in another process, and the output means 3 is made to check the file at any time. , You may display the behavior of the object. Furthermore, it can be realized by notifying the behavior of the object to the development support device which is another process using a method such as interprocess communication.

In the processing examples of FIGS. 2 and 3, the source program analysis processing in steps S2 and S12 is
Specifically, it can be performed as follows.

That is, the analysis of the source program is roughly divided into two processes, that is, the recognition of each definition and the recognition of the behavior of each object, as described above. The reason for recognizing each definition is that since the object is based on the class defined by the user (the creator of the source program), in order to recognize the behavior of the object,
First, we need to check the defined classes. That is, it is necessary to know what attributes and methods the class has. It is also used in the program because a new data type defined by the user other than the system-defined one may be used for the attribute of the class, the argument of the method, and the return value. Check all variables and all data types.

The procedure for recognizing each definition can be roughly classified into a data type table creating procedure, a class table creating procedure, and a variable table creating procedure. After these steps, in order to recognize the behavior of the object, the program code corresponding to the prepared behavior is embedded in a predetermined place.

Of the procedures for recognizing each definition, in the procedure for creating a data type table, the data types defined by the user are checked in addition to the data types prepared in advance in C ++, as shown in FIG. A new data type table. The data type defined by the user is searched for and extracted from the keyword in the program. The keyword is typede, which is a reserved word for users to use when defining types.
Reserved word used to declare f or definition #define
Or a class declaration, such as class, and the name of a data type can be extracted as a keyword according to their syntax.

Further, in the procedure of creating the class table, the attributes and methods inside the class are extracted. That is, the class is also a kind of user-defined data type, and therefore, the class is also extracted in the procedure of creating the data type table, but in the procedure of creating the class table, the attributes and methods inside the class are extracted. That is, as described above, the class definition part is extracted by searching for the class that is a C ++ reserved word, and the attribute name and type of the class, the method name and the Check the return value type and create a class table as shown in FIG.

In the procedure for creating the variable table, the source program is sequentially checked, and the used variables are used as global variables and their types, functions and variables declared in the functions and their types, methods and methods. The declared variables and their types are extracted separately and a variable table as shown in FIG. 6 is created. The variable declaration part can be extracted according to the syntax of the variable declaration by searching the data type name extracted in the creation of the data type table in the program.

When the data is extracted in this way,
Information for debugging is embedded in the program based on the extracted data. First, the source program is checked in order, the part of the behavior of the object is searched, and the debugging program code corresponding to that behavior is embedded in that part in advance.

Typical behaviors of an object include generation of an object, deletion of an object, invocation of a method possessed by an object, and assignment of a value to an attribute possessed by an object, and debugging corresponding thereto. Embedding program code for
explain.

First, the embedding of the debug program code corresponding to the generation of the object will be described.
In C ++, object creation is a reserved word ne
Since this is performed using w, it is possible to detect this reserved word new in the program and search for the generation location of the object.

When the object generation location is searched in this way, a debug program code as shown in FIG. 7 can be embedded in the object generation location. The debug program code shown in FIG. 7 includes a code for displaying count, which is a serial number for the behavior of all objects, as information for object generation, and a CREATE,
Code for displaying the name of the generated class (class name) and the variable VA in which the generated object is stored
Code to display the name (variable name) of RIABLE and WHER that shows where the object was created
It is composed of E, a code for displaying the generation part thereof, and a code for displaying the name of the generation part. In the object-oriented system, there are cases where an object is generated in a function and cases where it is in a method. Therefore, the function name or the method name is used as the code for displaying the name of the generation point. .

Next, the embedding of the debug program code corresponding to the deletion of the object will be described.
In C ++, object deletion is a reserved word de
Since this is performed using the letter, it is possible to detect the reserved word delete in the program and search for the deletion location of the object.

When the deletion location of the object is searched in this way, a debugging program code as shown in FIG. 8 can be embedded in the deletion location of the object. The debug program code shown in FIG. 8 is a code for displaying a count, which is a serial number for the behavior of all objects, as information for deleting the object, and a DELET indicating the deletion of the object.
E, code to display the name of the deleted class (class name), code to display the name of the variable VARIABLE that stored the deleted object (variable name), and where the object was deleted W showing Taka
It is composed of a code for displaying HERE and its deleted part, and a code for displaying the name of the deleted part. In the object-oriented system, the deleted part may be inside the function or the method. Therefore, the function name or the method name is used as the code for displaying the name of the deleted part.

Next, the embedding of the debugging program code corresponding to the method call of the object will be described. In C ++, since the method call of the object is represented by "->" or ".", This word can be detected in the program and the location of the method call of the object can be searched.
However, not all "->" or "." Are method calls, so check the variables on the left side of "->" or "." In the variable table, and check that the type is a class type. You need to make sure that it exists, and check the right part of the class table to make sure it is a method.

A program code for debugging as shown in FIG. 9 can be embedded in the call location of the method of the object. The debug program code in FIG. 9 is a code for displaying a count, which is a serial number for the behavior of all objects, as information on the method invocation of the object, and a METHO indicating the method invocation of the object.
D, the code for displaying the name of the method (method name), the FROM that indicates where the method of the object was called from, the code for displaying the call location of the method, and the name of the call location of the method Code for displaying, the code for displaying the class name (callee class name) indicating which method of which class has been called, and the code for displaying the number of arguments of the called method, It is composed of code for displaying the value of the argument of the called method. In an object-oriented system, there are cases where the method is called within a function and cases where it is inside a method. Therefore, the function name or method name is used as the code for displaying the name of the method called. Used.

Next, the embedding of the debugging program code corresponding to the assignment of the value to the attribute of the object will be described. In C ++, the attributes that an object has are that the attributes within the class are as they are, and the attributes outside the class are represented by "->" or ".". You can search for the place to assign the value to the attribute of. However, "-
Not all ">" or "." Are the place to assign the value, so check the variables on the left side of "->" or "." In the variable table to confirm that the type is a class type. Also, it is necessary to check the right part in the class table to confirm that it is an attribute name.

When the location of the value assigned to the attribute of the object is searched in this way, a debugging program code as shown in FIG. 10 may be embedded in the location of the value assigned to the attribute of the object. it can. The debug program code in FIG. 10 includes a code for displaying a count, which is a serial number for the behavior of all objects, as information for assigning values to attributes of objects, and a value assignment to attributes of objects. ATTRIBUTE to show, a code to display the name of the attribute (attribute name), WHERE to show where to substitute the value, code to display the place to substitute the value,
The code to display the name of the place where the value is assigned, the code to display the class name (callee class name) that indicates which class has the value assigned to the attribute, and what value is assigned Name of variable VARIABLE to indicate
And a code for displaying (variable name). In an object-oriented system, there are cases where the value assignment to the attribute is inside the function and cases where it is inside the method. Therefore, the code for displaying the name of the value assignment to the attribute is as follows: Function or method names are used.

As described above, in this embodiment, in the source program, the location of the behavior of the object can be automatically searched, and the predetermined debugging program code can be automatically embedded in the searched location. It should be noted that such retrieval and embedding processing is performed, for example, for each object generation location, object deletion location, object method invocation location, and object attribute assignment location as described above. Although it may be carried out in a separate routine, each of these retrieval and embedding processes can be executed in one pass in one routine.

In the above example, the embedding of the object behavior recognizing means 1 into the source program has been specifically described, but the embedding processing of the data recognizing means 4 and the storing means 2 into the source program is similarly performed. Can be done automatically.

In this way, the source program is analyzed, and the user-defined class definitions (attributes and methods) and user-defined data types (types) are extracted,
It is possible to recognize the call location of the message in the program and the data and data type at that time, automatically recognize the behavior of other objects, and automatically embed the predetermined debug program code in the location where the behavior is performed. it can.

Now, assuming that a source program (sample program) as shown in FIG. 11 is specified, how the behavior of the object is processed by the development support apparatus of this embodiment using this sample program is described. The processing of FIG. 2 will be specifically described as an example.

In the process of step S1 of FIG. 2, when a source program as shown in FIG. 11 is given,
The file name is test. Designate as being cc. Next, the source program in step S2
In the (test.cc) analysis process, first, a file in which the history of the object is written is declared at the beginning of the file. Further, the main function is searched for from the source program, and a function for opening a file for saving this history is inserted at the beginning of the main function. Also, a function for closing this file is inserted at the end of the main function. Next, the file is sequentially analyzed to recognize the classes and data types defined in the file. Figure 11
In the case of the source program of
classB and classA are defined, and there is no user-defined data type. Also, in the class definition, cl
assB has the method methodB, and cl
assA has the attribute ptr and the method methodA, and the argument of methodB is c, char, and c
The type of attribute ptr of classA is a pointer to classB, and the arguments of methodA are a and b.
It is recognized that both are integers. In addition, variable types such as the variables a and b being class class A and class B are also recognized in the main function. In this way, the data type table, class table, and variable table as shown in FIGS. 4, 5, and 6 are created, and the source program is sequentially analyzed again based on these information, and the object behaves. Embed a procedure that detects a location and writes out the behavior of the object. That is, the debugging program code as shown in FIG. 7, FIG. 8, FIG. 9 or FIG. 10 is embedded.

In the sample program of FIG. 11, the part P
1, P2, P3, P4, P5 and P6 are detected as the behavioral parts of the object.

That is, the sample program (tes
t. Looking at (cc) from top to bottom, first, class
It is detected that methodB is called in method A of method A (portion P1 in FIG. 11). Therefore, a procedure for writing the method call information to a file, that is, a debugging program code as shown in FIG. 9 is embedded here.

Next, the part generating classA in new is detected (part P2 in FIG. 11). Therefore, a procedure for writing the information of object generation to a file, that is, a debugging program code as shown in FIG. 7 is embedded here.

Next, the portion generating class B is detected (portion P3 in FIG. 11), and the debugging program code as shown in FIG. 7 is also embedded in this portion P3 in the same manner as in the portion P2.

Next, a method call portion from within the program is detected (portion P4 in FIG. 11), and this portion P is detected.
Also for 4, the method from within method A
A procedure for writing information similar to the call of odB to a file, that is, a debugging program code as shown in FIG. 9 is embedded.

Finally, the portions where the objects a and b are deleted are detected (portions P5 and P6 in FIG. 11),
A procedure for writing the information of object deletion into a file, that is, a debugging program code as shown in FIG. 8 is embedded in these portions P5 and P6.

Thus, the analysis of the source program (sample program) is completed. 12 to 14
11 completes the analysis of the source program of FIG.
FIG. 3 is a diagram showing a procedure necessary for debugging the source program, that is, a state in which a predetermined debug program code is embedded.

In the source programs of FIGS. 12 to 14, all the debug program code portions (embedded) added (embedded) to the source program of FIG. 11 by the development supporting apparatus of this embodiment are #ifde.
It is sandwiched between fOO_TOOL and #endif.

Referring to FIGS. 12-14, FIG.
In the part (Q1), a file for writing out the behavior of the object is defined, and a file pointer for that is declared. Also, for the FILE type necessary for the declaration of this file pointer, <stdio. h> is included. The count variable is a global variable for counting the behavior of the object.

Further, in the portion (Q2) of FIG. 12 (corresponding to the portion P1 of the source program of FIG. 11), classA
A method for saving a call of a method of another class in the method methodA of A, that is, a debugging program code as shown in FIG. 9 is embedded. That is, in the part P1 of the source program in FIG. 11, the method method of classA is
Since it is a call from A, in the debug program code of FIG. 9, the method call location is (FRO
M) and class A, and the function name is (FUNCTION), met
It becomes hodA.

As a result, when part (Q2) of FIG. 12 is executed, first, a counter count of the behavior of the object is output, and then "METHOD" indicating the method call and the method name meth.
odB is output. Next, FROM and TO are output from where and where (of which class) the method was called. Note that "FUNCTION" between them indicates from which function the function was called. In this case, since it is the method methodA, this name me
methodA is output. Next, for the argument, first, the number of arguments “1” is output, and then the value of the argument “a” is output.

Further, FIGS. 13 and 14 are program codes for the main function, and the part (Q3) of FIG.
In (corresponding to the portion P2 of the source program in FIG. 11), a procedure for opening a file for writing the behavior of the object is embedded at the head of the main function called at the beginning of the program. Also, in the part of (Q4),
A procedure for saving the content indicating the generation of an object in a file, that is, a debugging program code as shown in FIG. 7 is embedded. That is, in the portion P2 of the source program of FIG. 11, since the generation is performed within the function called main, the generation location is (WHERE) is FU.
It is NCTION, and the function names are (FUNCTION) and main.

As a result, when the part (Q4) is executed, the object behavior counter counter is first counted.
t is output, and then "CREATE" indicating the generation and the name classA of the generated class are output. next,
The variable name "a" in which the pointer indicating the generated object is stored is output, and then the position where the variable is generated is output. In this case, "FUNCTION" is output because it is generated in the function, but when it is generated in the method of a certain class, the class name is output. Then, the name of the function or the name of the method is output. In this case, the function name main
Is output.

Also, in the portion (Q5) (corresponding to the portion P3 of the source program in FIG. 11), as in the case of (Q4), a procedure for saving the content indicating the generation of an object in a file is embedded, When the part (Q5) is executed, the same output as that of the part (Q4) is made for the class classB.

Further, in the portion (Q6) of FIG. 13 (corresponding to the portion P4 of the source program of FIG. 11), (Q6 of FIG.
The procedure similar to 2) is embedded. However, (Q
Unlike the part 2), in the part (Q6), "FROM" is "F" because the method caller is not an object.
"UNCTION" and the calling function is "ma
In other words, in the portion P4 of the source program of FIG. 11, since it is a method call within a function called main, the method call location is (FROM),
FUNCTION, the function name is (FUNCTION), mai
n.

Further, in the portion (Q7) of FIG. 14 (corresponding to the portion P5 of the source program of FIG. 11), the procedure for writing the contents indicating the deletion of the object, that is, the debugging program code as shown in FIG. It is embedded. When the part (Q7) is executed, first, the counter "count" of the behavior of the object is output, and then "DELETE" indicating the deletion and the name of the class to be deleted ("classA" here) are output. Next, the variable name "a" indicating this object is output, and then
Since the location "WHERE" to be deleted, that is, not in the class but in the function here, "FUNCTION" is output, and then the function name "main" is output.

Further, in the portion (Q8) of FIG. 14 (corresponding to the portion P6 of the source program of FIG. 11), the same procedure as that of (Q7) is embedded.

The portion (Q9) of FIG. 14 is the same as that of FIG.
In the process of responding to the opening of the file in (Q3), the process of writing the behavior of the object is closed.

After the embedding process is performed in this way, the process proceeds to step S3 in FIG. 2 to execute the system.
When the system is executed, the file (OO_TOOL_FILE) is created by the print statement embedded in step S2.
= “OO_tool.file”), the behavior of the object is written out and saved in time series. The stored contents are shown in FIG. That is, FIG. 15 corresponds to FIG.
It is the contents of the file containing the information about the behavior of the object written as a result of compiling the program of FIG. 14 and executing the system.

In FIG. 15, the behaviors of the six objects are written out. P1 'and P2' are object generations, and (Q4) and (Q5) in FIGS.
It corresponds to each. Further, P3 'and P4' are method invocations, and are (Q6) in FIGS.
And (Q2) respectively. Further, P5 'and P6' are deletions of objects, and correspond to (Q7) and (Q8) of FIGS. 12 to 14, respectively.

When the behavior of the object is stored in the file by the storage means 2 in this way, the process proceeds to step S4 of FIG. 2 and the output means 3 is activated in order to visually see the execution of the system. Thereby, the output means 3
Reads the contents of a file and visually displays the behavior of objects in the system as specified by the user. Here, as the user's designation, 1) the output means automatically advances the behavior of the object in a fixed time, 2) the user sequentially gives instructions, and the behavior of the object is displayed. It can be selected.

The output means 3 which actually displays the behavior of the object based on the file contents (history) of FIG.
16 to 18 show an example of the above situation. That is, FIG. 16 to FIG. 18 are diagrams showing a state in which the development supporting apparatus of the present embodiment reads the file contents of FIG. 15 and displays the behavior of the object.

Referring to FIGS. 16 to 18, first, FIG. 16A is a screen when the output means is started, and nothing is displayed at this time. Next, when the output means 3 is activated, a program box is displayed on the screen as shown in FIG. 16 (b). Here, the program box is displayed when the output means 3 displays the behavior of objects and the behavior between objects, but when an object is created from a function or a method is called instead of an object, This is to secure a display area corresponding to these. In the example of FIG. 16B, only one program box is displayed for convenience, but a plurality of program boxes may be displayed for each function or each module according to the user's request.

Next, on the screen, as shown in FIG. 16 (c),
The process corresponding to P1 ′ in FIG. 15, ie, classA
The process of creating a type object a is displayed. That is, the class type A and the variable name a are displayed in the box on the screen. Next, as shown in FIG. 16D, a process of creating a class B type object b corresponding to P2 ′ in FIG. 15 is displayed on the screen. That is, as in FIG. 16C, the class type B and the variable name b are displayed in the box.

Then, as shown in FIG. 17E, the process corresponding to P3 'in FIG. 15 is displayed on the screen. That is, since the process of P3 'is a call of the method of the object a from the main function, an arrow is displayed in the class A type object a box from the program box. Here, when the operator selects the arrow, it is possible to display information regarding the method such as what data has been passed. Then, on the screen, as shown in FIG. 17 (f), P4 ′ in FIG. 15 is displayed.
The process corresponding to is displayed. That is, in the process of P4 ′, the method of the object of the class B type is called from the method methodA in the same manner as in P3 ′, and therefore an arrow is displayed from the object a to the object b.

When the method processing is completed, the arrow indicating the method call is erased, so that the arrow indicating the method from the object a is erased on the screen as shown in FIG. As shown in 17 (h), the arrow indicating that the method of the object a is called from the program is sequentially erased.

Next, since the object b is deleted on the screen in the process of P5 'in FIG. 15, the screen shown in FIG.
Object b indicating object b, such as 8 (i)
The box is erased. Then, in the same manner as P in FIG.
Since the object a is deleted in the process 6 ′, the object a box is deleted on the screen as shown in FIG. 18 (j), and the process showing the behavior of the series of objects ends.

In the above example, a series of screens (see FIG. 16 (a)-
The behavior of the object shown in FIG. 18 (j) is displayed, but this processing is not real-time processing, and all the behavior of the object is stored in the file. Therefore, it is possible to go back to the execution of the process. That is, it is possible to return the series of screens shown in FIGS. 16 (a) to 18 (j) to the original state from the middle, or to return to the state shown in FIG. 16 (a) starting from FIG. .

[0082]

As described above, according to the inventions of claims 1 to 9, when an object-oriented system is actually activated in an object-oriented system development environment, messages are exchanged between the objects. Behavior recognition means for recognizing behavior of objects such as creation and deletion of objects and objects, storage means for storing the behavior of objects recognized by the object behavior recognition means in a file, and objects stored in the file by the storage means With the output means for reading and outputting the behavior of the object-oriented system, the user can easily understand the behavior of the system when the object-oriented system is actually operated, that is, the behavior of the object.

In particular, according to the third aspect of the invention, the object behavior recognition means focuses on a specific object and recognizes only the behavior related to the specific object, so that only necessary data is handled in a concentrated manner. It is possible to omit unnecessary data.

In the invention according to claim 6, further,
The object behavior recognizing means and the data recognizing means have a second embedding means for embedding them in a file before the execution of the object-oriented system. The second embedding means analyzes the source program, Since the object behavior recognition means can be embedded by automatically recognizing the behavioral parts such as object generation and deletion, and message transmission, the user does not need to set the object behavior recognition means in this object-oriented system by himself. The work efficiency of the user can be significantly improved.

In the invention according to claim 7, the output means is adapted to visualize and display the contents stored in the file. For example, when presenting the behavior of the system to the user, , Display objects as squares or circles, and send and receive messages (exchange)
When presenting to the user, the user can visually and easily grasp the behavior of the system by displaying a link between the objects.

Further, in the invention according to the eighth aspect, when the output means visualizes and displays the contents stored in the file, the output means sequentially responds to the operation of the system in response to the user's request. Since the operating status of the system is displayed,
It is also possible to present the behavior of the system to the user over time, or to present the behavior of the system to the user by going back in time (that is, tracing the behavior of the system by going back in time).

According to the invention described in claim 9, the behavior of the object is visualized and displayed simultaneously with the execution of the system, so that the user can easily understand the behavior of the system in real time.

[Brief description of drawings]

FIG. 1 is a configuration diagram of an embodiment of a development support apparatus for an object-oriented system according to the present invention.

FIG. 2 is a flowchart showing an example of a processing operation of the development support device of FIG.

3 is a flowchart showing another example of the processing operation of the development support device of FIG.

FIG. 4 is a diagram showing an example of a data type table.

FIG. 5 is a diagram showing an example of a class table.

FIG. 6 is a diagram showing an example of a variable table.

FIG. 7 is a diagram showing an example of a debug program code corresponding to object generation.

FIG. 8 is a diagram showing an example of a debug program code corresponding to object deletion.

FIG. 9 is a diagram showing an example of a debug program code corresponding to a method call of an object.

FIG. 10 is a diagram showing an example of a debug program code corresponding to assignment of a value to an attribute of an object.

FIG. 11 is a diagram showing an example of a source program (sample program).

12 is a diagram showing a state in which a debugging program code is embedded in the source program of FIG.

13 is a diagram showing a state in which a debug program code is embedded in the source program of FIG.

14 is a diagram showing a state in which a debug program code is embedded in the source program of FIG.

FIG. 15 is a diagram showing the contents of a file containing information on the behavior of an object written as a result of compiling the programs of FIGS. 12 to 14 and executing the system.

FIG. 16 is a diagram showing a state in which the behavior of an object is displayed by reading the file contents of FIG.

FIG. 17 is a diagram showing a state in which the behavior of an object is displayed by reading the file contents of FIG.

FIG. 18 is a diagram showing a state in which the behavior of an object is displayed by reading the file contents of FIG.

[Explanation of symbols]

 1 Object Behavior Recognition Means 2 Storage Means 3 Output Means 4 Data Recognition Means 6 First Embedding Means 7 Second Embedding Means F File

Claims (9)

[Claims] 1. An object behavior recognition means for recognizing the behavior of an object when an object-oriented system is actually started in an object-oriented system development environment, and the behavior of the object recognized by the object behavior recognition means in a file. An apparatus for supporting development of an object-oriented system, comprising: saving means for saving; and output means for reading and outputting the behavior of an object saved in a file by the saving means. 2. The development support apparatus for an object-oriented system according to claim 1, wherein when the object behavior recognition means recognizes message exchange between objects as behavior of the object, the storage means is recognized. A development support device for an object-oriented system, characterized in that messages are stored in a file in the order in which they are exchanged between objects, and the output means also outputs the messages stored in the file. 3. The object-oriented system development support apparatus according to claim 1, wherein the object behavior recognition means focuses on a specific object and recognizes only the behavior related to the specific object. System development support device. 4. The development support apparatus for an object-oriented system according to claim 1, further comprising data recognition means for recognizing data in a message exchanged between messages, and said storage means further for data recognition. The data in the message recognized by the means is also stored in a file, and the output means further outputs the data in the message stored in the file. Development support device. 5. The development support apparatus for an object-oriented system according to claim 1, further comprising a first padding for embedding the storage means in a file before executing the object-oriented system. An apparatus for supporting the development of an object-oriented system, characterized in that it has an embedding means. 6. The development support apparatus for an object-oriented system according to claim 1, further comprising the object behavior recognition means and the data recognition means before execution of the object-oriented system. An object-oriented system development supporting apparatus having a second embedding means for embedding in a file. 7. The development support device for an object-oriented system according to claim 1, wherein the output means visualizes and displays the contents stored in the file. Development support device for object oriented system. 8. The development support apparatus for an object-oriented system according to claim 7, wherein the output means operates the system in response to a user request when visualizing and displaying the contents stored in the file. According to
An object-oriented system development support device characterized by displaying the operating status of the system. 9. The development support apparatus for an object-oriented system according to claim 7, wherein the output means visualizes and displays the behavior of the object at the same time as the system is executed. .