JP2006293437A - Program code generation device and generation method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To generate a program code which can use a dynamic memory management unit included in an embedded OS in a program code generation device. <P>SOLUTION: The program code generation method equipped with a generation process to generate a program code from a design drawing is equipped with; a process (step S704) which analyzes information in the design drawing and extracts description about generation and deletion of each object included in program code to be generated; and a process which determines a life cycle of each object (step S705) based on extracted description. The generation process is characterized by deciding a memory area in which each object is arranged when this program code is read into the memory and executed based on the life cycle determined according to the above process (step S705), in generating the program code based on the above design drawing. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an information processing technique in a program code generation device that automatically generates a program code from a software design drawing.

  2. Description of the Related Art In recent years, model driven architecture (Model Drive Architecture technology (hereinafter referred to as MDA technology)) has become widespread and adopted as software design technology.

  In general, according to the MDA technology, program codes for various platforms are automatically generated from software design drawing information input by an operator, or input software design drawing information is operated on an MDA-dedicated tool for verification. Is possible.

  For describing software design drawing information, for example, languages such as UML (Unified Modeling Language) and SDL (Specification & Description Language) which are model notation languages of object-oriented technology are generally used.

  Here, in the case of a program code generated by an existing program code generation device, the size may increase depending on a rule for converting design drawing information into a program code. For this reason, in a device in which the generated program code is executed, a lot of RAM may be required for execution. In an environment where the memory capacity is severely limited such as an embedded system, the introduction of MDA technology is hesitant. There are many cases. For this reason, it is desired to generate a program code with a small RAM capacity required at the time of execution.

  On the other hand, various proposals have been made so far for reducing the memory capacity required for executing the program code. For example, as techniques for performing optimization at the stage of a design drawing, “Object-oriented optimization code generation apparatus and method” disclosed in Japanese Patent Laid-Open No. 11-237980 and “Optimization software generation” disclosed in Japanese Patent Application Laid-Open No. 2004-118865 are disclosed. Method ". According to this publication, a program that can be applied to an embedded system without increasing the required memory capacity by eliminating the function of a virtual function using object-oriented function exclusion means, or eliminating the function of dynamic generation of instances. The code can be optimized.

  Further, as a technology for reducing the RAM capacity in software development for embedded systems, “Program conversion device” disclosed in Japanese Patent Laid-Open No. 2000-40005 and “Memory allocation method and object class” disclosed in Japanese Patent Laid-Open No. 2001-184214 are disclosed. Design method ". According to the publication, reduction of RAM capacity is realized by arranging instance variables and objects designated in the program code as const on the ROM.

Furthermore, “Program generation device” disclosed in Japanese Patent Application Laid-Open No. 2002-91762 discloses a technique related to address conversion when a ROM data address is rearranged in a RAM.
Japanese Patent Laid-Open No. 11-237980 JP 2004-118865 A JP 2000-40005 A JP 2001-184214 A JP 2002-91762 A

  However, none of the techniques disclosed in Patent Documents 1 to 5 considers an executable model of the MDA technique. Therefore, a proposal of a technique applicable to the MDA technique is desired.

  Here, the program code that can be generated by the current MDA tool is often an application on a general-purpose OS, and has a poor track record in the area of software for embedded systems. In particular, with regard to the method of using the memory area, program code that assumes variable-length memory management is mostly generated, and modifications for embedding the program code generated by the MDA tool may be left up to the developer. Many.

  In general, in the case of application development performed on a general-purpose OS, the memory area is secured and released using malloc and free in the C language and new and delete in the C ++ language. In addition, the securing and releasing of the memory area can be performed dynamically, and when the memory area is requested, the size can be designated.

  However, these variable length memory allocations are cumbersome to manage and generally slow in execution speed and take time. In particular, when there is no free area of the requested size in the memory area, the execution time further increases. In addition, when the system is operated for a long time, fragmentation occurs, and there is a high possibility that the stable operation of the system cannot be guaranteed.

  For these reasons, dynamic variable-length memory management is rarely used in software development in embedded systems. Instead, an embedded system OS (hereinafter referred to as an embedded OS) has a memory management mechanism that secures a memory area in the RAM with a fixed length and secures or releases the area in a variable length or a fixed length. There are many cases.

  For example, in the μITRON specification known for an embedded OS, a memory management function called a fixed-length memory pool or a variable-length memory pool is installed in order to realize dynamic memory management by software. Since the management mechanism is simple, the execution speed is fast, and there is an advantage that fragmentation does not occur particularly in a fixed-length memory pool. Since these memory management mechanisms are also effective in terms of execution speed and stability guarantee, they are often used not only for embedded system software but also for applications on general-purpose OSs.

  For this reason, it is desirable to generate a program code that can use the memory management function as a program code for an embedded system by using an MDA tool.

  However, since the design drawing is independent of the platform in the MDA technology, a program code using a memory management mechanism represented by a fixed-length and variable-length memory pool is not generated, and the memory pool area and its size are not generated. At present, the part to be specified is set by the developer himself after correcting the generated code after generating the program code.

  The present invention has been made in view of the above problems, and uses a dynamic memory management mechanism possessed by an OS of an embedded system in a program code generation apparatus that generates a program code from a software design drawing using MDA technology. The aim is to generate possible program code.

In order to achieve the above object, a program code generation device according to the present invention comprises the following arrangement. That is,
A program code generation device comprising a generation means for generating a program code from a design drawing described in a model notation language in object-oriented programming,
Extracting means for analyzing the information of the design drawing and extracting a description relating to generation and deletion of each object included in the generated program code;
Determination means for determining a cycle from generation to deletion of each object based on the description extracted by the extraction means,
The generation means generates a program code based on the design drawing. A memory area in which each object is arranged when the program code is read into a memory and executed is determined based on the cycle determined by the determination means. It is characterized by determining.

  According to the present invention, in a program code generation apparatus that generates a program code from a software design drawing using MDA technology, it is possible to generate a program code that can use a dynamic memory management mechanism of an embedded system OS. It becomes possible.

  First, an outline of an embodiment of the present invention will be described. In general, in the MDA technique, the generation or deletion of an object can be clarified by analyzing a design drawing. Therefore, in the program code generation device according to the following embodiment, the generation location and deletion location of an object are clarified by analysis of the design drawing, and further, the life cycle of each object is grasped, so that it is necessary for object generation. It was configured to be able to determine how to secure the memory area, that is, whether to allocate statically or dynamically. As a result, it has become possible to generate a program code that can use the dynamic memory management mechanism possessed by the OS of the embedded system. Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings as necessary.

<Configuration of program code generator>
FIG. 1 is a diagram showing an overall configuration of a program code generation device according to an embodiment of the present invention. In FIG. 1, reference numeral 1 denotes a CPU, which accesses and controls each of 3 to 10 devices described below via a bus 2.

  A read-only memory (ROM) 3 is accessible from the CPU 1 via the bus 2 and stores a processing program 3a and a parameter 3b used by the processing program 3a.

  Reference numeral 4 denotes a readable / writable memory (RAM). On the RAM 4, design drawing information, platform information, object generation / deletion location information, object life cycle information, program code, created / changed by the processing program 3a, Areas (4a, 4b, 4c, 4d, 4e, 4f, 4g in order) for storing the library and the executable format are secured.

  Reference numeral 5 denotes an input interface that receives an input made via an input device such as a keyboard, button, mouse, or dial shown in 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, which inputs / outputs data to / from an external storage device such as HD, FD, CD-ROM, MD, and CF shown at 10.

  In the present embodiment, it is assumed that the processing program 3a and the parameter 3b are on the ROM 3, and the storage area (4a to 4g) for each data to be processed is on the RAM 4. Can be arranged on the external storage device 10 and can be loaded from the external storage device 10 onto the RAM 4 and used as necessary. It can also be arranged on the cache memory of the CPU 1.

<Outline of processing by processing program 3a>
FIG. 2 shows an outline of processing by the processing program 3a, and the relationship between the configuration requirements of the processing program 3a and the data stored in the storage areas indicated by 4a to 4g in FIG. It shows whether there is.

  Reference numeral 200 denotes a GUI input processing unit that handles data input via the input interface 5 in FIG. 1, and the user can input and edit data and give instructions to each processing unit using this GUI input processing unit. ing. In the case of the program code generation device according to the present embodiment, the GUI input processing unit operates as a function of the automatic generation device activation unit 200.

  A design drawing input unit 201 reads an executable design drawing from the external storage device 10 and performs syntax analysis. The processing program 3a can interpret the executable design drawing and generate design drawing information. To do.

  Reference numeral 202 denotes a platform information input unit that reads platform data such as an OS, CPU, programming language, and framework on which an executable file operates from the external storage device 10 and performs syntax analysis. The processing program 3a generates platform information. enable.

  Reference numeral 203 denotes design drawing information generated by the design drawing input unit 201 and interpretable by the processing program 3a. Reference numeral 204 denotes platform information generated by the platform information input unit 202 and interpretable by the processing program 3a.

  Reference numeral 205 denotes an object generation / deletion part extraction unit that extracts a generation part and a deletion part of an object by analyzing the design drawing information 203, and extracts a description about generation and deletion of the object from the design drawing information 203. It is possible for the processing program 3a to interpret the timing when the system is initialized or after the system is operated. Reference numeral 206 denotes object generation / deletion location information generated by the object generation / deletion location extraction unit 205.

  Reference numeral 207 denotes an object life cycle determination unit that determines the life cycle of the object from the object generation / deletion point information 206 generated by the object generation / deletion point extraction unit 205. The object life cycle is synchronized with the end of activation of the system. It is possible for the processing program 3a to determine whether the life cycle is a short life cycle in which generation and deletion are repeated while the system is operating, or a life cycle in which generation and deletion are performed within a block scope within a function.

  Reference numeral 208 denotes object life cycle information generated by the object life cycle determination unit 207, which has life cycle information of the determined object, and additionally has information on the object data size, and the object that generates and deletes the object. is there.

  Reference numeral 209 denotes a program code generation unit that automatically generates a program code from the design drawing information 203, platform information 204, and object life cycle information 208, and uses a dynamic memory management mechanism that is generally used in an embedded OS. It is possible to generate a program code capable of selecting and designating a memory area in which the data is arranged.

  Reference numeral 210 denotes a program code generated from the program code generation unit 209. Reference numeral 211 denotes a library referenced from the program code. A code compiler 212 compiles and links the program code 210 generated using the program code 210 and the library 211.

  213 is a program execution format generated by the code compiler 212. A program execution format that can select and specify a memory area for placing an object using a dynamic memory management mechanism generally used in an embedded OS. Format.

<Description of design drawings>
Next, an executable design drawing will be described. A drawing that defines the overall structure of an executable design drawing is generally called a domain diagram. A specific example will be described with reference to FIG. FIG. 3 is an example of a domain diagram showing a system that receives an input from an operator, turns on a light, and designates a time to turn off the light. Reference numeral 301 denotes a controller domain that controls a system that blinks light, 302 denotes a UI domain that receives an operation from an operator, 303 denotes a light domain that controls light, and 304 denotes a timer domain that provides a time service.

  The connection between domains is called “association”, and is represented by a dotted line with an arrow in FIG. 3, which indicates that there is an event transmission / reception that is communication between domains. The association 305 is indicated by a dotted line with arrows in both directions in order to perform bidirectional event communication between the Controller domain 301 and the Timer domain 304. The association 306 is indicated by a dotted line with an arrow only on the Light domain 303 side in order to perform one-way event communication between the Controller domain 301 and the Light domain 303.

  In an executable design drawing, a design drawing showing a static structure of an object to be processed is called a class diagram. A specific example will be described with reference to FIG. FIG. 4 is an example of a class diagram of the Controller domain 301 that controls the system that blinks light in the domain diagram shown in FIG.

  In FIG. 4, 401 indicates the name of the class. Here, “Controller” is the name of the class. Reference numeral 402 represents that the Controller class has a string type instance variable “name”. Reference numeral 403 indicates that the Controller class has a method “getName” and receives three events “evOn”, “evOff”, and “alarm”. In this way, the contents of processing are written in the method, and the communication object between classes is written in the event.

  In an executable design drawing, the dynamic behavior of a class is represented by a diagram or table that represents a state transition. A specific example will be described with reference to FIG. FIG. 5 is an example of expressing the dynamic behavior of the class using the state transition diagram, and is an example of the state transition diagram of the Controller class in FIG.

  In FIG. 5, reference numeral 501 represents an initial state, and represents a state that is entered when an instance of the Controller class is generated. The initial state 501 does not stay in that state, and immediately transitions to the next state 502. Reference numeral 502 denotes a state named “Off”, and remains in this state after an instance of the Controller class is generated.

  Reference numeral 503 denotes a transition from state to state. When an evOn event is issued in the off state 502, a specific action evOn () is executed, and the state 504 is transitioned to. When an alarm event is issued in the On state 504, 505 executes a specific action alarm () and transitions to the On state 504 again. In general, an action can be described in the state transition diagram, but the example of the state transition diagram shown in FIG. 5 shows a case where it is defined and used in another file.

  In a design drawing that is platform-independent, executable, and object-oriented, the description of the processing procedure in each class state is generally called an “action”. In the present embodiment, the case where the description of the action is provided in a separate file will be described as an example, but it may be entered in a state transition diagram or the like.

  Next, FIG. 6 shows an example of an action description in a design drawing that is platform-independent, executable, and object-oriented.

  In FIG. 6, reference numeral 601 denotes an example of an action executed when the system shown in the domain diagram of FIG. 3 is initialized. Instances of the Controller class, UI class, and Light class necessary for the system are respectively created by new.

  The instance created here is registered by registerLink in order to register it as a variable that can be manipulated by the entire system. Reference numeral 602 denotes an example in which an action evOn for transitioning from the Off state 502 to the On state 504 is described in the state transition diagram of the Controller class shown in FIG.

  In the evOn action 602, an instance of the class Timer is newly generated in this action, and is registered as a variable that can be manipulated in the instance of the Controller class that executes this action. Further, in the evOn action 602, the only instance of the Light class that has already been registered as operable by the entire system is obtained by queryLink, and an event “lightOn” for turning on the light is transmitted by sendEvent.

  Reference numeral 603 denotes an example in which an action evOff for transitioning from the On state 504 to the Off state 502 is described in the state transition diagram of the Controller class shown in FIG. In the evOff action 603, a single instance of the Light class that has already been registered as operable in the entire system is obtained by queryLink, and an event “lightOff” for turning off the light is transmitted by sendEvent.

  Further, in the evOff action 603, the instance of the Timer class registered as a variable that can be manipulated in the instance of the Controller class by the evOn action 602 is obtained by queryLink, and the timer instance is deleted. In addition, in the evOff action 603, the only instance ui of the UI class that has already been registered as operable in the entire system is obtained by queryLink, and an event stop that notifies that the light has been turned off is transmitted by sendEvent.

  In the example of the action shown in FIG. 6, the variable name at the time of generation is used to identify the instance. However, another method using information for identifying the instance, for example, an identification number that can be specified in the system But it is feasible.

  In the example of the action shown in FIG. 6, whether the generated class instance is an instance that can be used in the entire system, an instance that can be used in a specific instance, or only in an action description block. Whether the instance can be used is described by an action by the user, but information specifying the use range of these variables can be obtained from the domain diagram shown in FIG. 4 or the class diagram shown in FIG. Needless to say, this is not the case.

<Details of processing in program code generation device>
Details of processing in the program code generation device according to the embodiment of the present invention will be described below with reference to the drawings and flowcharts.

  FIG. 7 is a flowchart showing a processing procedure of the entire program code generation device according to the present embodiment. First, in step S <b> 701, an executable design drawing stored in the external storage device 10 or the like is read, and the design drawing information 203 is generated by the design drawing input unit 201.

  In step S702, it is determined whether there is platform information input. If it is determined that platform information is input, the process branches to step S703 to generate platform information 204. On the other hand, if it is determined in step S702 that there is no input of platform information, the process branches to step S704. Platform information input depends on the platform on which the generated program code is executed, such as whether to map tasks and threads to which domain or class, whether execution speed is prioritized, or memory capacity is prioritized Information.

  In step S704, the design drawing information 203 is analyzed to extract an object generation / deletion point, and object generation / deletion point information 206 is generated. In step S705, the life cycle of the object is determined from the object generation / deletion location information 206 extracted in step S704, and object life cycle information 208 is generated.

  In step S706, the program code 210 is generated using the design drawing information 203, the platform information 204, and the object life cycle information 208. In step S707, the code compiler 212 compiles and links the program code 210 and the library 211 to generate a program execution format 213.

<Flow of processing in the object generation / deletion location extraction unit>
FIG. 8 is a flowchart showing the flow of processing in the object generation / deletion location extraction unit 205 shown in FIG. The object generation / deletion location extraction unit 205 analyzes the design drawing information 203 to extract an object generation location and a deletion location. Based on the extracted description, the processing program 3a can interpret the timing when the system is initialized or after the system is operated.

  In step S801, the list for managing the generation / deletion location of the object used when executing the process is cleared. In step S802, an action description is read from the design drawing information 203. Hereinafter, the processing from step S802 to step S811 is performed for all action descriptions read from the design drawing information 203.

  In step S803, it is determined whether the action description read from the design drawing information 203 is an object generation action. If it is a generation action, the process branches to step S804, and if it is not a generation action, the process branches to step S807.

  In step S804, it is determined whether or not the object deletion information for the target object is already registered in the list. If it is determined that the object deletion information is registered, the process branches to step S806 and is determined not to be registered. If so, the process branches to step S805.

  In step S805, object generation information is newly registered in the list. On the other hand, in step S806, object generation information is added to the object deletion information already registered in the list in the process in the case where there is deletion information of the object in the list.

  If the object is an instance that is a class entity, the object generation information includes a list of the class name, instance name, generated instance name, and generated action name of the generated object. In the case of an object generated when the system is activated, an identifier representing the system, for example, “system” is described in the list in the generated instance name.

  If the object is a communication object such as an event that is sent and received between instances of the class, the side that sends the communication object becomes the object generation action, and the communication is the class name, instance name, and identifier of the generated communication object. The object name or communication object ID is listed.

  Next, in step S807, it is determined whether the action description read from the design drawing information 203 is an object delete action. If it is a delete action, the process branches to step S808, and if it is not a delete action, the process branches to step S811.

  In step S808, it is determined whether or not the object generation information for the target object is already registered in the list. If it is determined that the object generation information is registered, the process branches to step S810 and is determined not to be registered. If so, the process branches to step S809.

  In step S809, object deletion information is newly registered in the list. On the other hand, in step S810, object deletion information is added to the object generation information already registered in the list.

  Step S811 indicates that the processing from step S802 is repeated for all the action descriptions read from the design drawing information 203.

<Example of object creation / deletion location information>
FIG. 9 is a diagram showing an example of the object generation / deletion location information 206 generated by the object generation / deletion location extraction unit 205 based on the action description shown in FIG. From the action description shown in FIG. 6, an object generation location using new is extracted from action 601 executed at the time of system initialization.

  Similarly, an object generation location using new is extracted from the evOn action 602 that transitions from the Off state 502 to the On state 504. Furthermore, the deletion part of the object using delete is extracted from the evOff action 603 that makes a transition from the On state 504 to the Off state 502. As a result of analyzing all the design drawing information 203 including all action descriptions in this manner, if there is no deleted part of the object using delete, “-” is described in the entry of the table of FIG.

<Flow of processing in the object life cycle determination unit>
FIG. 10 is a flowchart showing a processing flow in the object life cycle determination unit 207, and shows a processing procedure for generating the object life cycle information 208 from the object generation / deletion location information 206 shown as an example in FIG.

  In step S1001, the object described in the object generation / deletion location information 206 shown as an example in FIG. 9 is read. Hereinafter, the processing from step S1001 to step S1014 is performed for all objects read from the object generation / deletion location information 206.

  In step S1002, it is determined whether the object generation action and the information of the generated object are described in the table of the object generation / deletion location information 206 shown as an example in FIG. 9, and if it is described, it is described in step S1003. If not, the process branches to step S1004.

  In step S1003, it is determined whether the object deletion action and the information of the deleted object are described. If they are described, the process branches to step S1005, and if not described, the process branches to step S1006.

  In step S1005, if both the object generation information and the deletion information are described in step S1003, it is determined whether the generated object is the same as the deleted object. If they are the same, the process branches to step S1009, and if they are different, the process branches to step S1010.

  On the other hand, in step S1006, it is determined whether or not the generated object is “system” representing system initialization processing. If it is a system, the process branches to step S1008, and if it is not a system, the process branches to step S1007.

  In step S1007, it is determined that the description of the action for deleting the object has been forgotten, and the operator is notified of the deletion forgetting warning.

  On the other hand, in step S1008, it is determined that the life cycle is the same as the system, and the life cycle “system” is described in the object life cycle information.

  In step S1009, it is determined whether the generated object is the same as the deleted object. If they are the same, the process branches to step S1011. If they are different, the process branches to step S1010.

  In step S1010, it is determined that the life cycle is generated and deleted after the system is operated, and “short” is described in the object life cycle information.

  In step S1011, instead of describing the action of creating and deleting the object, the operator is notified of a warning that it can be substituted as a local variable of the function of the action.

  On the other hand, in step S1004, it is determined whether the delete action of the object and the information of the deleted object are described. If they are described, the process branches to step S1013, and if not described, the process branches to step S1012.

  In step S1012, the operator is notified of a processing error indicating that the object generation / deletion location extraction list is invalid.

  In step S1013, it is determined that the action description itself is illegal, and the operator is notified of an action description error.

  In step S1014, the process is repeated for all the objects described in the object generation / deletion location information 206 shown as an example in FIG.

  An example of the object life cycle information 208 generated by the object life cycle determination unit 207 is shown in FIG. In FIG. 11, a part describing the life cycle of the object is added to the object generation / deletion location information 206 shown in FIG. 9, but only the object identification information and life cycle information that can be specified in the system are shown. You may make it describe.

  In this way, the object life cycle determination unit 207 determines from the object life cycle information 208 that “system” is the same as the system shown in the process of step S1008 in FIG. 10 as the life cycle, or is shown in step S1010 of FIG. It is determined whether or not “short” is generated and deleted after the system is activated. In addition, at the same time as describing the life cycle information, the object deletion forgetting warning shown in step S1007 of FIG. 10, the local variable substitution warning shown in step S1011, the processing error shown in step S1012, and the action shown in step S1013 Notify the operator of the description error.

<Description of generated program code>
FIG. 12 is a diagram illustrating an example of a program code generated by the program code generation device according to the present embodiment. FIG. 12 shows an example of program code for generating objects classified as life cycles “system” and “short” based on the object life cycle information 208 shown in FIG. In addition, the case where the new action which produces the instance of a class is produced | generated among the actions shown in FIG. 6 is shown. The generated program code can use a μITRON-specific dynamic memory management mechanism and a fixed-size memory pool, which are known for embedded OSs.

  In FIG. 12, an object is generated in the life cycle “system” after the system is started and is not deleted while the system is running. Therefore, the life cycle “system” is defined as an array, and the function alloc_systemSpan on the program code generated from the action new is the array It is implemented as a function getAddrFromObjTable that returns the address of.

  In FIG. 12, since the life cycle “short” is an object that is repeatedly generated and deleted while the system is operating, a memory area of the object is secured from the fixed-sized memory pool allocated for each size. The function alloc_shortSpan on the program code generated from the action new is implemented as a service call get_mpf of μITRON that secures a memory area from a fixed-sized memory pool allocated for each size.

  In the example of the program code shown in FIG. 12, an example of using a function that returns the address of a statically secured array or a fixed-length memory pool of μITRON specifications is shown, but the present invention is not limited to this method. In the example of the program code shown in FIG. 12, the object determined as the life cycle “short” is secured from the prepared memory pool for each size. However, the present invention is not particularly limited to this, and FIG. It is also possible to prepare a separate memory pool by using other information such as classes and instances obtained from the object life cycle information shown as an example, and secure a memory area therefrom.

  As is clear from the above description, according to the program code generation device according to the present embodiment, by analyzing the design drawing and determining the life cycle of the object, the object itself and the memory area used by the object are determined. It is possible to determine when the reservation should be made.

  Thereby, for example, it is possible to classify whether to secure by a static array or to use a dynamic memory management mechanism. As a result, it is possible to generate program code that can use the dynamic memory management mechanism of the embedded OS. When using a dynamic memory management mechanism, in addition to the conventional method of securing from a fixed-sized memory pool prepared for each usage size, a memory pool may be allocated exclusively for objects that use memory areas. A dedicated memory pool can be allocated to a specific size of a specific instance, and memory areas can be used in various forms.

  Further, since the memory management mechanism to be used is a memory management mechanism that has been conventionally installed in an embedded OS, there is no concern about the execution speed or fragmentation, and it can be used in embedded software.

<Other embodiments>
Note that the present invention can be applied to a system including a plurality of devices (for example, a host computer, an interface device, a reader, and a printer), and a device (for example, a copying machine and a facsimile device) including a single device. You may apply to.

  Another object of the present invention is to supply a storage medium storing software program codes for implementing the functions of the above-described embodiments to a system or apparatus, and the computer (or CPU or MPU) of the system or apparatus stores the storage medium. Needless to say, this can also be achieved by reading and executing the program code stored in the.

  In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the storage medium storing the program code constitutes the present invention.

  As a storage medium for supplying the program code, for example, a floppy (registered trademark) disk, hard disk, optical disk, magneto-optical disk, CD-ROM, CD-R, magnetic tape, nonvolatile memory card, ROM, or the like is used. be able to.

  Further, by executing the program code read by the computer, not only the functions of the above-described embodiments are realized, but also an OS (operating system) operating on the computer based on the instruction of the program code. It goes without saying that a case where the function of the above-described embodiment is realized by performing part or all of the actual processing and the processing is included.

  Further, after the program code read from the storage medium is written into a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. It goes without saying that the CPU or the like provided in the board or the function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments are realized by the processing.

It is a figure which shows the whole structure of the program code production | generation apparatus concerning one Embodiment of this invention. It is a figure which shows the outline | summary of the process in the processing program 3a of a program code generation apparatus. It is a figure which shows an example of a domain diagram among design drawing information. It is a figure which shows an example of a class diagram among design drawing information. It is a figure which shows an example of a state transition diagram among design drawing information. It is a figure explaining the action description contained in design drawing information. It is the flowchart which showed the process sequence of the whole program code generation apparatus concerning one Embodiment of this invention. It is a flowchart which shows the flow of a process in an object production | generation deletion location extraction part. It is a figure which shows an example of the object production | generation deletion location information extracted in the object production | generation deletion location extraction part. It is a flowchart which shows the flow of the process in an object life cycle determination part. It is a figure which shows an example of the object life cycle information produced | generated in the object life cycle determination part. It is a figure which shows an example of the program code produced | generated in the program code production | generation apparatus concerning one Embodiment of this invention.

Explanation of symbols

1: CPU
2: Bus 3: ROM
4: RAM
4a: Design drawing information 4b: Platform information 4c: Object generation / deletion location information 4d: Object life cycle information 4e: Program code 4f: Library 4g: Executable 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)

Claims (9)

A program code generation device comprising a generation means for generating a program code from a design drawing described in a model notation language in object-oriented programming,
Extracting means for analyzing the information of the design drawing and extracting a description relating to generation and deletion of each object included in the generated program code;
Determination means for determining a cycle from generation to deletion of each object based on the description extracted by the extraction means,
The generation means generates a program code based on the design drawing. A memory area in which each object is arranged when the program code is read into a memory and executed is determined based on the cycle determined by the determination means. A program code generation device characterized in that the determination is performed. 2. The program code generation apparatus according to claim 1, wherein the description related to generation and deletion of each object is a description related to generation and deletion of an instance of a predetermined class. 2. The program code generation apparatus according to claim 1, wherein the description related to generation and deletion of each object is a description related to generation and deletion of a communication object transmitted and received between instances of each class. The determination unit is configured such that a cycle from generation to deletion of each object is equal to a cycle from start to end when the program code is executed, or each object that is repeated during execution of the program code. 2. The program code generation device according to claim 1, wherein it is determined whether the cycle is equal to a cycle from generation to deletion. 2. The program code generation apparatus according to claim 1, wherein the determination unit determines the cycle for an object to be generated and deleted within a block scope within a function. Notification means for notifying the operator of the cycle determined by the determination means;
A designation unit for designating a memory area in which each object is arranged when the program code is read into a memory and executed based on an instruction of an operator;
The generation unit determines a memory area where each object is arranged when the program code is read into the memory and executed when generating the program code based on the design drawing based on the designation by the designation unit. The program code generation device according to claim 1. A program code generation method comprising a generation step of generating a program code from a design drawing described in a model notation language in object-oriented programming,
An extraction step of analyzing the information of the design drawing and extracting a description relating to generation and deletion of each object included in the generated program code;
A determination step of determining a cycle from generation to deletion of each object based on the description extracted by the extraction step,
In the generation process of the program code based on the design drawing, a memory area in which each object is arranged when the program code is read into the memory and executed is determined based on the cycle determined by the determination process. A program code generation method characterized by: A storage medium storing a control program for realizing the program code generation method according to claim 8 by a computer. A control program for realizing the program code generation method according to claim 8 by a computer.

Images