JP2007079838A - Program code generator, program code generating method, and program therefor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To output a most suitable implementation method automatically about the relation in a design drawing of software. <P>SOLUTION: A program code generating method etc. provides a design drawing analysis process for analyzing design drawing which is platform non-dependent, executable, and is object-oriented; an instance arrangement process which establishes a program code generation rule to the relation of one to multi based on the design drawing information; an instance arrangement information update process which updates instance access information that shows how many times data accesses occur; and a program code generation process which generates program codes based on the instance arrangement information. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a program code generation device or the like that automatically generates a program code from a design drawing of software.

  As a software design technology in recent years, Model Driven Architecture technology (hereinafter referred to as MDA technology) has become widespread and has been adopted. This is a technology that can automatically generate program codes for various platforms from software design drawing information, and can operate and verify the input software design drawing information on a dedicated MDA tool. Typical examples of information include UML (Unified Modeling Language) and SDL (Specification & Description Language), which are model notation languages of object-oriented technology.

  However, the program code generated from the existing program generation device has a problem that the size of the generated code is large and requires a lot of RAM for execution depending on the rules for converting the design drawing into the program code. is there. For this reason, in areas where memory capacity is severely limited, such as embedded systems, there are many cases where the introduction of MDA technology is hesitant.

  Techniques for performing optimization at the design drawing stage are disclosed in Patent Document 1 (Japanese Patent Laid-Open No. 11-237980) and Patent Document 2 (Japanese Patent Laid-Open No. 2004-118865). These technologies are code that can be applied to an embedded control system without increasing the required memory capacity by eliminating the function of a virtual function using the object-oriented function exclusion means or eliminating the function of dynamic generation of instances. It is possible to perform optimization. Further, techniques for reducing the RAM capacity in software development for embedded systems are disclosed in Patent Document 3 (Japanese Patent Laid-Open No. 2000-40005) and Patent Document 4 (Japanese Patent Laid-Open No. 2001-184214). These technologies attempt to reduce the RAM capacity by placing instance variables and objects designated by const in the program code on the ROM. The technique described in Patent Document 5 (Japanese Patent Application Laid-Open No. 2002-91762) relates to address conversion when rearranging addresses to ROM data in the RAM, and analyzes the data in the design drawing. There is no mention of where to place it above. The optimization described in these proposals is a device limited at the time of generating the program code, and does not consider the executable model of the MDA technique.

  In an object-oriented program, one function is realized by instances in which instances of a class cooperate with each other. When an instance is generated, another instance that works on the instance secures a memory area as an area for holding the association, and realizes a cooperative operation between the instances. If the relationship between instances is a one-to-one relationship, it is sufficient that there is one area that refers to the instance itself. However, when the relationship between instances is one-to-many or many-to-many, it is necessary to secure a container for holding a plurality of instances in the memory area. A container that holds a plurality of instances is realized by an array type, a LIST type, a MAP type, or the like.

  In the case of a one-to-many relationship, the relationship between instances changes dynamically, so it is necessary to dynamically secure the container area. The container area can maintain an association with a plurality of instances by continuously having a reference to another instance associated with the instance and a reference to the next container. For example, if there is a one-to-many relationship between class X and class Y, and instance (x1) of class X realizes instance (y1, y2, y3) of class Y with a LIST type container, instance x1 becomes , Y1 to y3 are related as a list-type container that can be traced. When data exchange occurs between the class X and the class Y, the key search is performed for the instance of the class Y from the LIST type container of the instance x1, and the specific instance is cooperated with a plurality of associated instances. It becomes possible to operate.

Japanese Patent Laid-Open No. 11-237980 JP 2004-118865 A JP 2000-40005 A JP 2001-184214 A JP 2002-91762 A

  There are various container mounting methods depending on memory usage and search costs. In general, when an implementation method that suppresses the cost of search is selected, the memory usage increases. In other words, the container implementation method has a trade-off relationship between search costs and memory consumption. Therefore, it is necessary to generate a program code by an optimal mounting method in terms of memory consumption and search cost. However, when the MDA technology is used, the container mounting method is not changed according to the characteristics of the program, and no consideration is given to the memory consumption and the cost for searching for instances.

  The present invention is optimal from the access frequency and access pattern to the instance of the program code that implements the container that is the holding method of the instance, from the access status to the instance that is the actual execution result and the model information that is the design drawing. The correct program code. As a result, the designer can automatically output an optimum mounting method for the relation in the design drawing of the software.

  To achieve the above object, the present invention provides a design drawing analysis process for analyzing a design drawing that is platform-independent, executable, and object-oriented, and a one-to-many method based on the design drawing information. An instance placement step for defining a program code generation rule for the association, an instance placement information update step for updating instance access information indicating how many times data access has occurred, and a program code based on the instance placement information A program code generation method characterized by comprising a program code generation step.

  According to the present invention, there is provided a program code generation device for generating a program code in accordance with instance arrangement information for one-to-many and many-to-many related classes when automatically generating a program code from a software design drawing. be able to.

  Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.

(First embodiment)
FIG. 1 is an overall configuration diagram showing a first embodiment of the present invention. Reference numeral 1 denotes a CPU which accesses and controls 3 to 10 devices described below via a bus denoted by 2. Reference numeral 3 denotes a read-only memory (ROM) that can be accessed from the CPU 1 via the bus 2. In this embodiment, a processing program 3a for explaining the operation in detail and a parameter 3b used by the processing program are stored. Reference numeral 4 denotes a readable / writable memory (RAM). On the RAM 4, areas 4a, 4b, 4c, 4d, 4e, 4f, 4g and 4h are secured. In these areas 4a to 4h, design drawing information, platform-dependent information, program code, instance arrangement information, library, program execution format, instance access information, and instance arrangement information are stored, respectively. These design drawing information, platform-dependent information, program code, instance arrangement information, library, program execution format, instance access information, and instance arrangement information are created / changed by the processing program 3. An input interface 5 receives an input made via an input device such as a keyboard, a mouse, a button, or a dial indicated by 6. Reference numeral 7 denotes an output interface which displays / outputs data to a display medium such as a CRT or LCD shown in 8 and an output device such as a printer or plotter. Reference numeral 9 denotes an external storage device interface for inputting / outputting data to / from an external storage device such as HD, FD, CD-ROM, MD, CF shown in 10.

  In the present embodiment, it is assumed that the processing program 3a and the parameter 3b are on the ROM 3, and that the storage area (4a to 4h) for each data to be processed is on the RAM. However, all of these can be arranged on an external storage device, and can be loaded from an external storage device onto a RAM and used as necessary. Similarly, it can be arranged on the cache memory of the CPU.

  FIG. 2 is a data flow diagram showing the configuration requirements of the processing program indicated by 3a in FIG. 1 and the relationship between the configuration requirements and the data stored in the storage areas indicated by 4a to 4f in FIG. It is.

  Reference numeral 201 denotes a GUI input processing unit that handles data input via the input interface 5 in FIG. 1. The user can input and edit data and instruct each processing unit by the GUI input processing unit 201. ing. In the program code generation device according to the present embodiment, the automatic generation device activation unit 202 is used.

  203 is a design drawing information input for reading design drawings stored in the external storage device 10, which are platform-independent, executable, and object-oriented, and generate design drawing information 206. Part.

  Reference numeral 204 denotes a platform-dependent information input unit. The platform-dependent information input unit 204 reads information including the OS, CPU, memory amount, programming language, and usage framework stored in the external storage device 10 and generates platform-dependent information 207.

  Reference numeral 205 denotes an instance arrangement information update unit that updates the instance arrangement information 208 for determining the collection type in the instance implementation code.

  Reference numeral 209 denotes a program generation unit that generates a program code 210 from the design drawing information 206, platform-dependent information 207, and instance arrangement information 208. The program generation unit 209 generates a program code using the instance arrangement information 208 selected by the instance arrangement information input unit. Examples of the program code that can be generated by the program generation unit 209 include a program code that determines the collection type of the instance, a program code that includes a code that can output an access log to the instance, and the like.

  Reference numeral 211 denotes a library referenced from the program code 210.

  A code compiler / linker 212 compiles and links the program code 210 and the library 211.

  Reference numeral 213 denotes a program execution format generated by the code compiler / linker 212.

  Reference numeral 214 denotes an execution unit that executes the program execution format 213. When the program execution format 213 is the program execution format 213 to which a code capable of outputting an access log to the instance is added, the program execution log 215 is output during the program operation here.

  Reference numeral 215 denotes a program execution log that is output when the program execution unit 214 executes the program. The log 215 outputs when and what class instance has been accessed.

  An execution log analysis unit 216 analyzes an access log to the instance using the program execution log 215.

  Reference numeral 217 denotes instance access information calculated by the execution log analysis unit 216.

  The processing procedure according to the flowchart in the following description is not limited to an example, and any combination of procedures, a plurality of processings, and processing can be subdivided as long as the result of the present invention is satisfied. . In addition, each process can be cut out individually to function as a single function element and used in combination with a process other than the process shown.

  The operation of the embodiment of the present invention will be described below with reference to the drawings and flowcharts.

  FIG. 3 is a flowchart showing a processing procedure of the entire system of the present embodiment. The activation of this system is instructed by an operator from an input unit such as the GUI input processing unit 201 (step S101).

  In step S102, the design drawing information input unit 203 reads the design drawing and generates design drawing information 206 converted into a data format that can be processed by the program generation unit 209.

  In step S103, the platform-dependent information input unit 204 generates platform-dependent information 207 converted into a data format that can be processed by the program generation unit 209.

  In step S <b> 104, the program generation unit 209 generates a program code 210 using the design drawing information 206 and the platform-dependent information 207. Here, only when there is an instruction from the operator, a program code specifying an instance holding method is generated using the instance arrangement information 208. Furthermore, if there is an instruction from the operator, a program code for generating a program execution log 215 that outputs when and which instance is accessed is added to the generated program code 210. The program code generation routine will be described in detail next.

  In step S105, the compiler / linker 212 compiles and links the program code 210 and the library 211 to generate a program execution format 213.

  In step S106, the program execution unit 214 executes the program execution format 213. If the program execution format 214 is the execution format of the program code 210 with the log output function added, the program execution log 215 is output at this step.

  In step S <b> 107, the execution log analysis unit 216 determines whether a program code for generating a program execution log is added and there is a program execution log 215. If there is a program execution log, the process proceeds to step S108. If there is no program execution log in step S107, the process proceeds to step S109.

  In step S108, the execution log analysis unit 216 performs a process of analyzing the program execution log 215, and performs a process of generating instance access information 217.

  In step S109, the instance arrangement information update unit 208 determines whether or not the instance access information exists and the instance arrangement information is updated. When updating the instance arrangement information, the process proceeds to step S110. If the instance arrangement information is not updated in step S109, the process proceeds to step S111, and this sequence ends.

  In step S110, the instance arrangement information update unit 208 performs a process of updating the instance arrangement information. The instance arrangement information update routine will be described in detail next.

  In this embodiment, the GUI input processing unit 201 activates the program generation unit 209, the compiler / linker 212, the program execution unit 214, and the execution log analysis unit 216 by an operator, but this method is not used.

  FIG. 4 is a flowchart explaining the flow of the program code generation routine S104 of FIG. When the program code generation routine is called, in step S202, processing for repeating steps S203 to S211 is performed for all classes until program code generation is completed. If the program code generation has not been completed for all classes, the process proceeds to step S203.

  In step S203, with respect to generation of program codes for all associations existing in the class, processing is repeated from step S204 to step S210 until program code generation is completed. If program code generation has not been completed for all relationships, the process proceeds to step S204.

  In step S204, a process is performed to determine whether the relationship is a one-to-many relationship or a one-to-one relationship in the design drawing information 206.

  In step S204, if there is a one-to-one relationship, the process proceeds to step S208. If there is a one-to-many relationship, the process proceeds to step S205.

  In step S205, processing for determining whether to automatically generate a program code for the collection based on the instance arrangement information 208 is performed. If the program code is generated using the instance arrangement information 208 in step S205, the process proceeds to step S206. If the instance arrangement information 208 is not used, the process proceeds to step S207.

  In step S206, a process for generating a program code for the association between instances with the type described in the instance arrangement information is performed.

  In step S207, a program code is generated for the association between instances in the list structure.

  In step S208, since there is a one-to-one relationship between instances, a process for generating directly referenced program code is performed.

  In step S209, processing for determining whether or not to add a log to the program code is performed. When adding a log in step S209, the process proceeds to step S210. If no log is added in step S209, the process proceeds to step S211.

  In step S210, processing for adding a program code for log output to the program code is performed.

  When program code generation is completed for all associations in step S211, the process proceeds to step S212.

  When the program code generation is completed for all classes in step S212, the process proceeds to step S213 and this sequence is terminated.

  FIG. 5A is an image diagram showing a part of a certain design drawing. In FIG. 5A, 301 indicates a class whose class name is AAA. Reference numeral 302 denotes a class whose class name is BBB. 303 indicates that the class AAA and the class BBB are in a one-to-many relationship, and the relationship from the class AAA to the class BBB is A1.

  FIG. 5B is a table showing characteristics related to containers for implementing cooperation between classes. Key search is a form in which a specific instance is searched based on a key from a plurality of instances associated with a certain instance and then accessed. An Enum is a form for accessing all of a plurality of instances related to a certain instance. In the MAP type, an instance and its key are registered, so that the cost for key search is low. In the case of the LIST type and the array type, there is a difference between whether the container structure is simple or complicated, but since all instances are scanned until the target instance is found, the cost for key search is high. Become. In the case of the Enum format, the memory consumption varies depending on whether the container structure is simple or complex, but the cost of the Enum is not different between the MAP type, the array type, and the LIST type.

  FIG. 6 is a flowchart illustrating in detail the flow of the instance arrangement information update routine S110 of FIG. As shown in the table of FIG. 5B, when there is a key search in the access format, the HASH type with a low key search cost (processing order) is effective. For this reason, when a certain number of instances or more are associated (collection), the HASH type is selected in consideration of the key search cost. The cost for key search is the same between the LIST type and the array type, but the array type or the LIST type is selected depending on the access frequency of the Enum format because of the complexity of the structure.

  When the instance arrangement information update routine is called, in step S302, processing for repeating steps S303 to S315 is performed for all classes until the update of the instance arrangement information 208 to the instance arrangement information 208 is completed. If the update of the instance arrangement information 208 has not been completed for all classes, the process proceeds to step S303.

  In step S303, for the update of the instance arrangement information 208 related to the one-to-many relationship existing in the class, the process of repeating steps S304 to S314 is performed until the update is completed. If the update of all the instance arrangement information 208 has not been completed, the process proceeds to step S304.

  In step S304, the instance access information regarding the target association is read to determine whether there is a key search. If there is a key search in step S304, the process proceeds to step S305. If there is no key search, the process proceeds to step S309.

  In step S305, the instance access information regarding the target association is read, and the total number of instances in the collection is acquired.

  In step S306, a process for acquiring a threshold value for determining a container that implements a previously set association is performed.

  In step S307, the total number of instances of the collection acquired in step S305 is compared with the threshold acquired in step S306. If the total number of instances in the collection is larger than the threshold value in step S307, the process proceeds to step S308. If the total number of instances in the collection is smaller than the threshold value in step S307, the process proceeds to step S309.

  In step S308, a process for setting the instance arrangement information regarding the target association to the HASH type is performed.

  In step S309, the instance access information is read for the target association, and processing for determining whether there is an Enum format is performed. If there is an Enum format in step S309, the process proceeds to step S311. If there is no Enum format, the process proceeds to step S310.

  In step S310, a process for setting the instance arrangement information 208 for the relevant association to the LIST type is performed.

  In step S311, the instance access information regarding the relevant association is read, and processing for obtaining the access frequency in the Enum format is performed.

  In step S312, a process for acquiring a threshold value for determining a container that implements a previously set association is performed.

  In step 313, the total number acquired in step S311 is compared with the threshold acquired in step S312. If the total number is larger than the threshold value in step S313, the process proceeds to step S314. If the total number is smaller than the threshold value in step S313, the process proceeds to step S310.

  In step S314, a process for setting the instance arrangement information 208 for the target association to an array type is performed.

  When the update of the instance arrangement information 208 is completed for all associations in step S315, the process proceeds to step S316.

  When the instance arrangement information 208 is completed for all classes in step S316, the process proceeds to step S317, and this sequence is terminated.

  FIG. 7 is obtained by inputting the design drawing of FIG. 5A and generating the program code according to the flowchart of FIG. 4, compiling and linking the program code, and actually executing the resulting program execution format. It is the image figure which showed an example of the log. In FIG. 7, 401 indicates a log when an access to an instance held by the association A1 occurs in the association A1 of the class AAA. Reference numerals 402 to 404 indicate logs for acquiring a specific instance. 402 indicates that the association A1 was searched with the key “name”, and the instance held by the association was checked four times, and as a result, the target instance could be obtained. ing. 403 and 404 are the same as 402. Reference numeral 405 denotes a log indicating that processing has occurred for all instances held by the association.

  FIG. 8 is an image diagram showing instance access information 217 obtained as a result of analyzing the log of FIG. 501 in FIG. 8 indicates the following items. That is, a process for searching whether or not there is an association A1 in the class AAA and an instance with the key “name” exists for the association A1, and four accesses are made to acquire the target instance. It shows what happened to the association A1. Reference numeral 502 indicates that consecutive accesses have occurred for all four instances held by the association. Further, it is indicated that the access to the specific instance has occurred three times and the continuous access to all the instances has occurred once.

  When the flowchart shown in FIG. 4 is executed, the instance access information of FIG. 8 is analyzed and the instance arrangement information is updated. When the threshold value for key search is 3, the instance arrangement information 208 is set to MAP type because the total number of instances is 4 in the instance access information 217. When the threshold for key retrieval is 4 and the access frequency of the Enum format is 1, the LIST type is set. If the threshold value for key search is 4 and the access frequency of the Enum format is 0, the array type is set. As described above, the instance arrangement information 208 is updated from the instance access information 217 by executing the flowchart shown in FIG.

  FIG. 9 is an example of a program code generated using “MAP”. In FIG. 9, reference numeral 601 denotes a class constructor. For example, program code for generating an association (MAP) between classes is generated in the constructor. 602 is a program code for acquiring a specific instance for an instance held in the association between classes. For example, when using MAP, a specific instance is acquired from the MAP by giving a key to an argument. I can do it. Reference numeral 603 denotes program code for newly adding an instance to the association between classes. For example, when registering in the MAP, an instance and a key for searching the instance are registered at the same time. MAP is known to have a high search speed instead of a large memory consumption, and by generating a MAP as a program code for the association, the cost of searching for a specific instance can be reduced. Is possible.

  FIG. 10 is an example of a program code generated using “LIST”. In FIG. 10, reference numeral 701 denotes a class constructor. For example, a program code for generating an association (LIST) between classes is generated in the constructor. Reference numeral 702 denotes program code for obtaining a specific instance for the instance held in the association between classes. For example, when LIST is used, it is realized by executing a loop until an instance matching the key appears for all instances by a while statement or the like. Reference numeral 703 denotes program code for newly adding an instance to the association between classes. For example, when registering in the LIST, the instance is registered. The LIST type is known to have a higher search cost than the MAP instead of the MAP type, but the memory consumption is reduced by generating the LIST type as a program code for the association. The amount can be reduced.

  In this embodiment, program code generation related to a container of another instance related to an instance is changed based on the total number of instances or the total number accessed as a threshold, but the threshold is not a number but a ratio. However, similar actions and effects can be obtained.

(Second Embodiment)
Next, a second embodiment of the present invention will be described. In the second embodiment, in addition to the first embodiment, in the update of the instance arrangement information (step S110 in FIG. 3), the instance arrangement information update unit 205 considers the priority of the access information of the instance access information. The instance arrangement information 208 is updated. FIG. 11 shows a flowchart for updating the instance arrangement information.

  FIG. 11 is a flowchart for updating the instance arrangement information 208 according to the second embodiment. As shown in the table of FIG. 5B, when there is a key search in the access format, the HASH type with a low key search cost (processing order) is effective. However, since the cost for key search is low and the memory consumption is high, there is a case where the effect is not so great even if the HASH type is selected when the key search is not performed so much. In such a case, it is calculated based on the frequency of the key search format and the frequency of the Enum format whether the LIST format is better than the HASH format.

  In step S402, processing for obtaining points allocated according to the priority of using each type is performed. For example, when the program code for implementing the association is the LIST type or the MAP type, if the memory consumption is to be suppressed rather than the search speed, the LIST type point is set higher than the MAP type.

  In step S403, for all classes, the process of repeating steps S404 to S410 is performed until the update of the instance arrangement information 208 from the instance access information 217 is completed. If the update of the instance arrangement information 208 has not been completed for all classes, the process proceeds to step S404.

  In step S404, with respect to the update of the instance arrangement information 208 relating to the one-to-many relationship existing in the class, the process of repeating steps S405 to S409 is performed until the update is completed. If the update of all the instance arrangement information 208 has not been completed, the process proceeds to step S405.

  In step S405, the number of accesses in the Enum format is acquired from the instance access information 217, and the number of points of each type is calculated from the number of accesses and the number of points acquired in step S402.

  In step S406, the process of repeating step S407 is performed until all keys are completed for the key search format. If all the keys are not completed, the process proceeds to step S407.

  In step S407, the number of accesses of a specific instance is acquired from the instance access information 217, and the number of points of each type is calculated from the number of accesses and the number of points acquired in step S402.

  When all the keys are completed in step S408, the process proceeds to step S409.

  In step S409, processing for setting instance arrangement information is performed from the number of points of each type obtained from steps S405 and S407.

  When the program code generation is completed for all associations in step S410, the process proceeds to step S411.

  When program code generation is completed for all classes in step S411, the process proceeds to step S412 and this sequence is terminated.

  FIG. 12 is an image diagram showing instance access information 217 similar to that of the first embodiment. 801 in FIG. 12 indicates the following items. That is, a process for searching whether or not there is an association A1 in the class AAA and an instance with the key “name” exists for the association A1, and four accesses are made to acquire the target instance. It shows what happened to the association A1. In step 802, a process for searching whether or not there is an association A1 in the class AAA and an instance with the key “name” exists for the association A1, and two accesses are performed to obtain the target instance. Has occurred for association A1. In 803, there is a process for searching whether or not there is an association A1 in the class AAA, and an instance with the key “type” exists for the association A1, and the access is performed 50 times to acquire the target instance. Has occurred for association A1. Reference numeral 804 denotes that continuous access has occurred for the total number of instances 100 held by the association. Further, it is shown that the same access has occurred 10 times in total.

  When the flowchart shown in FIG. 11 is executed, the instance access information in FIG. 12 is analyzed, and the instance arrangement information is updated. For example, when it is desired to reduce the memory consumption rather than the cost for the search, the LIST type point is set higher, such as 2 for the LIST type and 1 for the MAP type. In the case of FIG. 12, with respect to continuous access to all instances, access to all instances occurs 10 times, so the LIST type points are 20 points. Similarly, MAP type points are 10 points. In the case of FIG. 12, when accessing a specific instance using name as a key, it exists twice, so the LIST type point is 0 and the MAP type point is 2. Further, when accessing a specific instance using type as a key, since it exists once, the LIST type point is 0 and the MAP type point is 1. As a result, in the instance access information as shown in FIG. That is, since the LIST type point is set to 2 and the MAP type point is set to 1, LIST type 20 points, MAP type 12 points (key is name), and 11 points (key is type). Accordingly, the final instance arrangement information is set as LIST, and when the program code is finally generated, the LIST type is generated.

  In addition, when it is desired to suppress the search cost rather than the memory consumption search, the MAP type point is set to a high value such that the LIST type point is 1 and the MAP type point is 2. In the case of FIG. 12, since access to all instances occurs 10 times for continuous access to all instances, the LIST type points are 10 points. Similarly, MAP type points are 20 points. In the case of FIG. 12, when accessing a specific instance using name as a key, it exists twice, so the LIST type point is 0 and the MAP type point is 4. In addition, when accessing a specific instance using type as a key, since it exists once, the LIST type point is 0, and the MAP type point is 2. As a result, in the instance access information as shown in FIG. That is, since the LIST type point is set to 1 and the MAP type point is set to 2, the LIST type point is 10 points, the MAP type point is 22 points (key is name), and 21 points (key is type). Accordingly, the final instance arrangement information is set as a MAP type having a key as a name. When a program code is finally generated, a MAP type having a key as a name is generated.

  In the present embodiment, points are set, but the same actions and effects can be obtained even if a method for setting other priorities is used instead of points.

  As described above, when updating the instance arrangement information, by applying points to the instance access information, it is possible to trade off the memory consumption and the cost of search and It becomes possible to determine the mounting method.

  As described above, according to these embodiments, when the program code is automatically generated from the design drawing of the software, the program that generates the program code according to the instance arrangement information for the one-to-many and many-to-many related classes. A code generation device can be provided.

  Also, these program code generation devices can generate a program code that can log the access status of an instance held by a certain instance in order to update the instance arrangement information. Then, it is possible to extract instance access information 217 for determining a container mounting method from the log. Furthermore, it is possible to update the optimum program code as the instance arrangement information for the container holding the instance based on the instance access information. Furthermore, these program code generation devices can generate program code with reduced memory consumption in consideration of instance search costs by updating the instance arrangement information from the instance access information for the container implementation.

  The embodiment of the present invention can be realized by, for example, a computer executing a program. Also, means for supplying a program to a computer, for example, a computer-readable recording medium such as a CD-ROM recording such a program, or a transmission medium such as the Internet for transmitting such a program is also applied as an embodiment of the present invention. Can do. The above program can also be applied as an embodiment of the present invention. The above program, recording medium, transmission medium, and program product are included in the scope of the present invention.

1 is a configuration block diagram of a program code generation device according to a first embodiment of the present invention. It is a data flow figure of the program code generation device concerning a 1st embodiment of the present invention. It is a flowchart figure of the whole system in the 1st Embodiment of this invention. It is a flowchart figure regarding the program code generation routine in the 1st Embodiment of this invention. It is an image figure showing a part of a certain design drawing. It is a figure which shows the table | surface showing the characteristic regarding the container which implements cooperation between classes. It is a flowchart figure regarding the update routine of the instance arrangement | positioning information in the 1st Embodiment of this invention. It is an image figure which shows the log output by the log output program code in the 1st Embodiment of this invention. It is an image figure which shows the instance access information obtained as a result of analyzing the log in the 1st Embodiment of this invention. It is the image figure which showed the example which mounted the container by MAP type in the program code produced | generated by the program code production | generation apparatus in the 1st Embodiment of this invention. It is the image figure which showed the example which mounted the container by LIST type in the program code produced | generated by the program code production | generation apparatus in the 1st Embodiment of this invention. It is a flowchart figure regarding the update routine of the instance arrangement | positioning information in the 2nd Embodiment of this invention. It is an image figure which shows the instance access information obtained as a result of analyzing the log in the 2nd Embodiment of this invention.

Explanation of symbols

1: CPU
2: Bus 3: ROM
4: RAM
4a: Design drawing information 4b: Platform-dependent information 4c: Program code 4d: Instance arrangement information 4e: Library 4f: Program execution format 5: Input interface 6: Keyboard, button, mouse, dial 7: Output interface 8a: CRT, LCD
8b: printer, plotter 9: external storage device interface 10: HD, FD, CD-ROM, MD, CF,... (File)
201: GUI input processing unit 202: Automatic generation device activation unit 203: Design drawing information input unit 204: Platform dependent information input unit 205: Instance arrangement information update unit 206: Design drawing information 207: Platform dependent information 208: Instance arrangement information 209 : Program generation unit 210: Program code 211: Library 212: Compiler / linker 213: Program execution format 214: Program execution unit 215: Program execution log 216: Execution log analysis unit 217: Instance access information 301: Class name is AAA Class 302: Class name is BBB Class 303: Association between class AAA and class BBB

Claims (9)

A design drawing analysis means for analyzing a design drawing that is platform independent, executable, and object oriented;
Instance arrangement information defining program code generation rules for one-to-many associations based on the design drawing information;
Instance placement information update means for updating instance access information indicating how many times data access has occurred;
Program code generating means for generating a program code based on the instance arrangement information;
A program code generation device comprising:   2. The program code generation device according to claim 1, wherein the instance arrangement information update unit updates the instance access information based on the instance access information and a threshold value set in advance. The instance access information is
A first class described in the design drawing;
A second class different from the first class described in the design drawing;
An association between the first class and the second class;
A first instance that is an entity of a first class of the design drawing;
A second instance that is an entity of a second class of the design drawing;
An access type to the first instance and the second instance;
The program code generation device according to claim 2, comprising:   4. The program code generation device according to claim 3, wherein the access format is a key search format for accessing only a specific instance of the second instance.   4. The program code generation device according to claim 3, wherein the access format is an Enum format that makes full access to the second instance related to the first instance.   The program code generation device according to claim 3, wherein the threshold value defines the total number of instances.   The program code generation device according to claim 3, wherein the threshold defines a frequency of accessing an instance. A design drawing analysis process for analyzing a platform independent, executable and object oriented design drawing;
An instance placement step for defining a program code generation rule for a one-to-many relationship based on the design drawing information;
An instance placement information update step for updating instance access information indicating how many times data access has occurred;
A program code generation step of generating a program code based on the instance arrangement information;
A program code generation method comprising: On the computer,
A design drawing analysis procedure for analyzing a platform independent, executable and object oriented design drawing;
An instance arrangement procedure for defining a program code generation rule for a one-to-many relationship based on the design drawing information;
Instance placement information update procedure for updating instance access information indicating how many times data access has occurred,
A program code generation procedure for generating a program code based on the instance arrangement information;
A program characterized by having executed.

Images