JP2006139472A - Model drive development device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a model drive development device automatically generating only a file corresponding to a change of a part of a model to efficiently perform regeneration, in model drive development. <P>SOLUTION: In this model drive development device, by dividing the model and a conversion rule used for the automatic generation into a plurality of model elements and conversion rule elements that are basics of conversion in the automatic generation, and imparting a version to each the element, only a program element corresponding to the change is automatically generated as the result of version comparison and selection of the program element when only the model element of a part of the model, or a part of the conversion rule elements are updated, so that the regeneration can be efficiently performed. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to an efficient automatic generation method based on model, conversion rule, and source file version management in a method for automatically generating a source file by model driven development.

  In recent years, model-driven development ("Model Driven Architecture (MDA)") that automatically generates source code for programs to be developed using standardized modeling techniques such as UML (Unified Modeling Language) A software development method called “Same” is also drawing attention.

  According to this model-driven development, the function of the application is modeled, and based on this, the source code of the program is automatically generated using a dedicated tool such as a generator. Conversion rules used for automatic generation are set in advance in the generator.

  FIG. 14 conceptually illustrates a conventional model-driven development method. In this method, the entire model 330 and the entire change rule modeling the target application are managed in one version. A program source file is created from the model 330 using a generator 340. The source file 1 (351) is generated by the generator 340 using the conversion rule 1 based on the information of the element 3 and the element 22 of the model 330. The same applies to the other source file 2 (352) and source file 3 (353).

  Therefore, it is necessary to regenerate all program elements regardless of which model element or conversion rule is changed. For example, even if only the element 22 is changed, the entire model 330 is changed in version, and the entire model 330 is used to regenerate all the source files. Even when the conversion rules of the generator 340 are partially changed, the version of the entire generator 340 is changed, so that all source files are regenerated.

An example of a version management system related to a conventional program and document information, which is a field different from model-driven development, is described in Patent Document 1. In Patent Document 1, one source code change affects other document files. In Patent Documents 2 and 3, when the version is updated and updated by changing one difference information of one source program, the version of the application program is upgraded as a whole.
JP 2002-182908 A ([0010] to [0029] [0045], FIG. 1, FIG. 9, FIG. 15, FIG. 15) Japanese Laid-Open Patent Publication No. 2000-200185 ([0013] to [0019] [0023] [0024], FIG. 1, FIG. 6, FIG. 7) JP-A-11-327878 ([0014] [0026] [0033], FIG. 1, FIG. 5, FIG. 8)

  In the conventional model-driven development, simple automatic generation regenerates the entire source file from the entire model even if a part of the model or conversion rule is changed. In this case, when the model is large, regeneration is time-consuming and inefficient. Even if a part of the model or conversion rule is changed, the version of all source files that are all products is changed.

  Therefore, the present invention can efficiently regenerate a program without regenerating all the source files of the program even when only a part of the elements of the model or conversion rule in model driven development is updated. The challenge is to make it.

  In addition, when there is substantially no change in the model element or the product element, the version is not changed, and only the essential difference of the product can be quickly understood.

  The model-driven development device of the present invention is a model-driven development device that generates a source file of the program from a model of a program to be developed using a model-driven development method according to a predetermined conversion rule. Dividing into a plurality of model elements that are basic units, assigning a version to each model element, dividing the conversion rule into a plurality of conversion rule elements associated with the model element, and each of the conversion rules When a model is given a version, and the model and / or the change rule is changed, only the model element to be changed and / or only the change rule element, a control means for updating the version, a plurality of the model elements, Model storage means for storing the version, a plurality of the divided conversion rule elements and their bars A conversion rule storage means for storing an application, a plurality of generated source files of program elements, a version of the model element when the program element is generated, and a version of the conversion rule element are stored in association with each other The program storage means compares the version of the model element with the version of the model element when the corresponding program element is generated, and the conversion rule when the program element corresponding to the version of the conversion rule element is generated Version comparison means for comparing the version of the element and outputting the result; and from the version comparison means, the version of the model element and the version of the model element when the corresponding program element is generated do not match, or the conversion Before matching rule element version When receiving a result that the version of the conversion rule element does not match when the program element is generated, the program element is generated using the model element and the conversion rule element, and the version of the model element and the version of the conversion rule element And a program generation means for writing in the program storage means.

  The model-driven development apparatus is the model-driven development apparatus described above, wherein the model elements are entities, controls, or boundaries.

  According to the model-driven development apparatus of the present invention, the model is divided into model elements, and a version is assigned to each element. A conversion rule is divided into conversion rule elements, and a version is assigned to each element. If configured, if some model element in the model is changed or if some conversion rule element in the conversion rule is changed, version comparison will only automatically generate a new version of that element Therefore, unnecessary regeneration of program elements can be prevented.

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

  The model-driven development device divides a model in model-driven development into elements that are basic units for conversion at the time of automatic generation, and gives a version to each element. This version changes only when each element is changed. If other elements are changed but the elements are not changed, the version is the same as before. A version is also assigned to the conversion rule used for automatic generation. The conversion rule is also divided and a version is assigned to each conversion rule element.

  The automatically generated program elements store all corresponding model elements and conversion rule element versions. If the version of the conversion rule element or model element is the same as the previous generation, the program element is not automatically generated. Thereby, when only a part of the model elements of the model is updated, only the program element corresponding to the change is automatically generated, and the regeneration can be efficiently performed.

[Embodiment 1]
FIG. 1 shows a model-driven development method according to Embodiment 1 of the present invention. The model 30 includes a plurality of model elements. One version is provided for each model element.

  The model 30 includes a model element 1, a model element 2, a model element 3, a model element 21, and a model element 22. Model 30 is version 1.1. Model element 1, model element 2, and model element 3 belong directly to the model, and the versions are version 1.2, version 1.1, and version 1.1, respectively. The model element 21 and the model element 22 belong to the model element 2, and the versions are version 1.1 and version 2.1, respectively.

  The model drive development device 40 includes a control unit 41 and a generator 42.

  The control means 41 controls the model 30 when the model 30 is stored in the model drive development device 40. The control means 41 divides the model 30 into model elements and assigns versions. When the model element is changed, the version of the corresponding model element is updated.

  The model 30 and each element thereof may be given from another PC or may be updated by another PC. Therefore, the model drive development apparatus 40 using the control means that does not have the function of dividing, versioning, and updating the model 30 can also be configured.

  The generator 42 includes a plurality of conversion rule elements and generates respective source files. The model element and the conversion rule element to be used are connected by a line and an arrow. One version is also provided for each conversion rule element of the generator 42. The generator 42 includes a conversion rule element 1 (43), a conversion rule element 2 (44), and a conversion rule element 3 (45), and the versions are version 1.1, version 2.1, and version 1.1, respectively. , Source file 1 (51), source file 2 (52), and source file 3 (53) are generated.

  Thereby, for example, when the version of only the model element 22 is changed, only the source file 1 (51) is regenerated using the conversion rule element 1 (41). When only the conversion rule element 2 (42) of the generator 42 is changed, only the source file 2 (52) is regenerated using the model element 2 and the model element 21.

  Next, FIG. 2 shows a functional configuration diagram of Embodiment 1 of the present invention. The computer 100 becomes the model drive development device 40. The computer 100 constitutes the control means 41 and the generator 42 shown in FIG.

  The computer 100 operated by program control includes a model storage unit 110, a conversion rule storage unit 120, a program storage unit 130, a conversion rule element version acquisition unit 140, a model element version acquisition unit 150, and a program element version acquisition unit. 160, a version comparison unit 170, a model element acquisition unit 180, a conversion rule element acquisition unit 190, a program generation unit 200, and a host control unit 230.

  FIG. 3 is a hardware configuration diagram of the computer 100. A CPU (Central Processing Unit) 250 includes a conversion rule element version acquisition unit 140, a model element version acquisition unit 150, a program element version acquisition unit 160, a control of the version comparison unit 170, a model element acquisition unit 180, and a conversion. The rule element acquisition unit 190, the program generation unit 200, and the host control unit 230 perform control functions. The volatile memory 260 performs the temporary storage function of the version comparison unit 170 and the temporary storage function of the program generation unit 200. The hard disk 270 performs the functions of the model storage unit 110, the conversion rule storage unit 120, and the program storage unit 130. A bus 280 connects the CPU 250, the volatile memory 260, and the nonvolatile memory 270.

  Each part of the functional configuration diagram will be described. The model storage means 110 stores the model 30 in a format in which a version number can be assigned for each model element constituting the model 30. The model 30 includes three types of model elements, that is, an entity 31, a control 32, and a boundary 33, which will be described later.

  The conversion rule storage unit 120 stores the conversion rule in a format in which a version number can be assigned for each conversion rule element.

  The program storage unit 130 stores the program generated by the program generation unit 200 in a format in which a version number can be assigned to each program element file. The program elements include a DB (Database) source file 35, an EJB (Enterprise Java (registered trademark) Beans) source file 36, and a JSP (Java (registered trademark) Server Pages) source file 37, which will be described later.

  The program element corresponds to the source file in FIG.

  The conversion rule element version acquisition unit 140 acquires the version number of the conversion rule element from the conversion rule storage unit 120 and sends it to the version comparison unit 170. The model element version acquisition unit 150 acquires the version number of the model element from the model storage unit 110 and sends it to the version comparison unit 170.

  The program element version acquisition unit 160 searches and acquires the version of the program element corresponding to the conversion rule element and the model element from the program storage unit 130, and sends it to the version comparison unit 170. That is, the conversion rule element version and the model element version at the time of generating the program element corresponding to the corresponding program element are acquired from the program storage unit 130 and sent to the version comparison unit 170. Here, the version of the program element refers to a conversion rule element version and a model element version when generating a program element corresponding to the program element.

  The version comparison means 170 compares whether the version of the program element corresponding to the conversion rule element and the model element matches the version of the conversion rule element and the version of the model element. That is, it is compared whether or not the conversion rule element version and the model element version at the time of generating the program element of the corresponding program element match the version of the designated conversion rule element and the version of the model element. The comparison result true is returned only when they all match. In other cases, the comparison result false is returned.

The model element acquisition unit 180 acquires model element information from the model storage unit 110.
The conversion rule element acquisition unit 190 acquires conversion rule element information from the conversion rule storage unit 120.

  The program generation unit 200 passes the conversion rule element acquired from the conversion rule element acquisition unit 190 and the model element input to the conversion rule element to the version comparison unit, and calculates whether the corresponding program element and version match, If they do not match, a corresponding program element is generated using the model element acquired from the model element acquisition unit 180 and the conversion rule element already acquired, and after adding version information of the model element and the conversion rule element, the program storage Store in means 130. If they match, no program element is generated.

  The upper control unit 230 performs control as an upper control unit of the version comparison unit 170 and the program generation unit 200. When the model is stored in the model storage unit, the upper control unit 230 divides the model into model elements and assigns a version to each model element. Change model elements and update versions. When conversion rules are stored in the conversion rule storage unit 120, the conversion rules are divided into conversion rule elements, and a version is assigned to each conversion rule element. Change conversion rule elements and update versions.

  The model and the conversion rule are divided into model elements, each model element is given a version and divided into conversion rule elements, and each conversion rule element is given a version from an external PC or the like In some cases. In some cases, data updated by another PC is written.

  FIG. 4 shows program elements on the program storage unit 130. A conversion rule element version and a model element version at the time of generating a program element corresponding to the program element are stored. As a result, the version of the conversion rule element and model element used for generation can be traced from the program element, which can be effectively utilized for failure investigation.

  FIG. 5 shows an example of a model 30 composed of model elements. In this example, as described above, the model 30 includes three types of model elements that are objects by model-driven modeling. In other words, an entity 31 that is a group of information and corresponds to a table definition in the database, a control 32 that performs arithmetic operations and processing to control programs, and the outside world and the computer world such as screen and form printing. Boundary 33, which is input / output information for connecting. The entity attribute is information that becomes an entity element, the control operation is a part that executes processing for another class, that is, the entity and the boundary, and the boundary attribute is information that becomes a boundary element. .

 There are any number of entities 31, controls 32, and boundaries 33. The control 32 refers to the entity 31, and the boundary 33 refers to any number of controls 32.

  FIG. 6A shows conversion of three types of model elements of the model 30 into three types of program elements, that is, a DB source file 35, an EJB source file 36, and a JSP source file 37, using three conversion rule elements indicated by arrows. FIG. 6B shows a correspondence table of model elements, program elements, and conversion rule elements. These will be described together.

  In FIG. 6A, the entity 31 is converted into a DB source file 35 by the conversion rule element 1. The control 32 refers to the entity 31 and is converted into an EJB source file 36 by the conversion rule element 2. The boundary 33 is converted into a JSP source file 37 by the conversion rule element 3 with reference to the control 32.

  Here, the source file which is the converted program element will be described.

  The DB source file 35 is a source file as a database corresponding to the entity 31. The EJB source file 36 is a source file that is an extension of a Java (registered trademark) component specification Java (registered trademark) corresponding to the control 32 and the entity 31 so that it can be used on the server side. Software components that support EJB can be shared from various Java (registered trademark) programs. The JSP source file 37 is a source file of a Web application execution environment using Java (registered trademark) corresponding to the boundary 33 and the control 32, and a file in which the Java (registered trademark) code is embedded in an HTML sentence is stored on the Web server side. Execute and return the result to the web browser.

  Next, the correspondence table of FIG. Conversion of model elements and program elements and conversion rule elements for performing the conversion are shown for each number.

  Next, the conversion rule element will be described. Examples will be described later with reference to FIGS.

  The conversion rule element 1 generates one database, that is, a table of the DB 35 for each entity 31. The attribute of the entity 31 is converted into a column of the DB source file 35. For example, an input item is converted into a database item.

  The conversion rule element 2 creates one EJB source file 36 for each control 32. The operation of the control 32 is converted into an EJB method. The EJB method is a portion for executing processing for manipulating information that becomes an EJB attribute, that is, an EJB element. Further, an SQL (Structured query language) statement for acquiring the DB source file 35 corresponding to the entity 31 referred to by the control 32 is generated. For example, an SQL statement for listening to an input operation or a DB to be used is provided in the EJB.

  The conversion rule element 3 generates one JSP source file 37 for each of the boundaries 33. The attribute of the boundary 33 is converted to the INPUT of the JSP source file 37. The JSP INPUT is an input area arranged in the JSP. Java (registered trademark) Beans, which is a component specification of Java (registered trademark), is generated on the JSP source file 37 for the control 32 referred to by the boundary 33. For example, an input screen item is a JSP input item. Also, an input operation is generated in the JSP as Java (registered trademark) Beans.

  Here, as shown in FIG. 6A, the program element DB source file 35 depends on the model element entity 31 and the conversion rule element 1, and the program element EJB source file 36 contains the model element entity 31 and the control. 32 and the conversion rule element 2, the program source JSP source file 37 depends on the model element control 32 and the boundary 33 and the conversion rule element 3.

  By using the technique of the present invention, the regen range of program elements is limited. That is, as can be seen from FIG. 6A, it is not necessary to generate the JSP source file 37 when only the entity 31 is changed, and it is not necessary to generate the EJB source file 36 when only the control 32 is changed. Yes, when only the boundary 33 is changed, the generation of the DB source file 35 and the EJB source file 36 becomes unnecessary. When only the conversion rule element 1 is changed, the generation of the EJB source file 36 and the JSP source file 37 is not necessary. When only the conversion rule element 2 is changed, the DB source file 35 and the JSP source file 37 are not generated. Generation is unnecessary, and when only the conversion rule element 3 is changed, generation of the DB source file 35 and the EJB source file 36 is unnecessary. In either case, the version of the conversion rule element or model element used at the time of generation can be acquired for each program element that is always generated.

  FIG. 7 shows and describes a sales management model which is an embodiment corresponding to FIG. FIG. 7A is an example of conversion, and FIG. 7B is a correspondence table. The conversion rule elements of the correspondence table are the same as those described above.

  In FIG. 7A, the model 30 is the sales management model 60, and the data input on the sales input screen 63 that is the entity 31 is stored in the sales DB 61 that is the boundary 33 under the control of the input control 62 that is the control 32. And save it. This is converted by a conversion rule.

  As a result, the sales DB 61 is converted by the conversion rule element 1 into the URI_TABLE 65 that is the DB source file 35. The input control 62 refers to the sales DB 61 and is converted by the conversion rule element 2 into the URIBean 66 that is the EJB source file 36. The sales input screen 63 refers to the input control 62, and the URI. Converted to JSP67.

  The correspondence table in FIG. 7B shows a specific example of model elements and program elements. The entity of the model element is “sales DB”, the control is “input control”, and the boundary is “sales input screen”. The DB of the program elements, that is, the database table is “URIAGE_TABLE”, the EJB is “UriageBean”, and the JSP is “Uriage.JSP”.

  FIG. 8 is a detailed example of conversion by the conversion rule element 1. In FIG. 8A, a database table “URIAGE_TABLE” is created for the sales DB 61, and “Date DATETIME” in which the attributes, the date, the customer, the product name, the unit price, the number, and the price of the sales DB 61 are the columns of the URIAGE_TABLE 65, respectively. , “Cust NUMBER (5)”, “Item VARCHAR (20)”, “Price NUMBER (10)”, “Num NUMBER (5)”, “Sum NUMBER (20)”. FIG. 8B shows a correspondence table of only the conversion rule element 1 in the correspondence table of FIG.

  FIG. 9 is a detailed example of conversion by the conversion rule element 2. In FIG. 9A, “UriageBean” that is an EJB is created for the input control 62, and “input” that is an operation of the input control 62 is converted into a method of the UreaBean, and the sales DB 61 that the input control 62 refers to. The SQL statement for acquiring the DB corresponding to is created in the method. FIG. 9B shows a correspondence table of only the conversion rule element 2 in the correspondence table of FIG.

  FIG. 10 is a detailed example of conversion by the conversion rule element 3. 10A, “Uriage.JSP” is created for the sales input screen 63, and the attributes of the sales input screen 63 such as date, customer, product name, unit price, quantity, and price are converted by the conversion rule element 3, respectively. Urage. The input control 62 referred to by the sales input screen 63 is converted to the URI. It is generated as Java (registered trademark) Beans on JSP. As a result, the input on the sales input screen 63 by the input control 62 is URIage. Enter JSP. FIG. 10B shows a correspondence table of only the conversion rule element 3 in the correspondence table of FIG.

  Next, the operation of Embodiment 1 of the present invention will be described in detail with reference to the flowcharts of FIGS. 11 and 12.

  First, the flowchart of FIG. 11 will be described. The operation of comparing whether the versions of steps A3 and A4 in the figure match is shown in detail in the flowchart of FIG.

  First, the conversion rule element acquisition unit 190 acquires a conversion rule element from the conversion rule storage unit 120 (step A1). Next, the model element acquisition unit 180 acquires a model element corresponding to the conversion rule element from the model storage unit 110 (step A2).

  The program generation unit 200 acquires the conversion rules and model elements and sends them to the version comparison unit 170. The version comparison means 170 compares the version of the conversion rule and the model element with the version of the corresponding program element (step A3, details are shown in FIG. 8). If the versions match, neither the model element nor the conversion rule element has been updated, and the process proceeds to step A9 (step A4).

 If the versions do not match, the model element or conversion rule element has been updated, so that the corresponding program element is continuously generated by the program generation means 200. The model element information is converted based on the acquired conversion rule element conversion rule to generate a program element (step A5). Next, the version of the model element used for the conversion is written in the program element (step A6). Further, the version of the conversion rule used for conversion is also written in the program element (step A7). Finally, the program element is stored in the program storage means 130 (step A8). Then, it is checked whether the processed model element is the last model element (step A9). If it is not the last, it returns to step A2. If it is the last, it is checked whether the conversion rule element used for the process is the last (step A10). If it is not the last, it returns to step A1. If it is the last, it ends.

  Next, version comparison of A3 and A4 will be described using the flowchart of FIG.

  First, the version comparison unit 170 searches and acquires the program element corresponding to the conversion rule element and the model element from the program storage unit 130 via the program element version acquisition unit 160 (step B1). . It is checked whether the corresponding program element exists (step B2). If there is not, it is a case where a conversion rule element or a model element is added, and the result is “version does not match”, and the result is returned to the upper control means. There is no corresponding program element, and a new program element is created (step B7). If it exists, the version comparison unit 170 acquires the version of the conversion rule element associated with the program element generation from the program storage unit 130 via the program element version acquisition unit 160 (step B3). This version is compared with the version of the current conversion rule element (step B4). If the versions do not match, the result “version does not match” is returned to the upper control means (step B7). If they match, the version comparison unit 170 acquires the version of the associated model element at the time of generating the program element from the program element storage unit 130 via the program element version acquisition unit 160 (step B5). There may be multiple model elements, but in that case, acquire all of them. The version comparison means 170 compares these versions with the version of the current model element (step B6). If the versions do not match, the result “version does not match” is returned to the upper control means (step B7). If they match, the result “version matches” is returned to the upper control means (step B8).

[Embodiment 2]
Next, the structure of Embodiment 2 of this invention is demonstrated in detail with reference to drawings.

FIG. 13 shows the configuration of the second embodiment. The configuration of the second embodiment of the present invention is a configuration in which a model editing unit 210 and a conversion rule editing unit 220 are added to the configuration of the first embodiment.
In the first embodiment, among the functions performed by the host control unit 230, model editing and change rule editing are performed by the model editing unit 210 and the conversion rule editing unit 220.
The description of the configuration and operation shown in Embodiment 1 is omitted.

  The computer 100 includes a model editing unit 210 and a conversion rule editing unit 220.

  The model editing unit 210 reads the model from the model storage unit 110, adds an element, deletes an element, changes the content of the element, and writes back to the model storage unit 110. At that time, the version information of the changed model element is updated so that the previous model element can be distinguished from the version.

  The conversion rule editing unit 220 reads the conversion rule from the conversion rule storage unit 120, adds the conversion rule, deletes the conversion rule, changes the content of the conversion rule, and writes it back to the conversion rule storage unit 120. At that time, the version information of the changed conversion rule element is updated so that the previous conversion rule element can be distinguished from the version.

  The host control unit 230 controls the model editing unit 210 and the conversion rule editing unit 220.

  Next, the effect of Embodiment 2 of this invention is demonstrated.

In the second embodiment of the present invention, since the model is edited by the model editing unit 210, the version of each element is automatically updated. Therefore, the trouble of version update work when the model is changed Can be given and an accurate version can be given.
In the second embodiment, the version of each element is automatically updated by editing the conversion rule with the conversion rule editing unit 220. Therefore, the version update operation when the conversion rule is changed You can save the time and give an accurate version.

  The present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the spirit of the present invention.

  The present invention can be applied to fields such as automatic generation in model-driven development. It can also be applied to applications such as automatically generating maintenance documents from hardware and middleware models.

It is the method of model drive development of Embodiment 1 of this invention. It is a block diagram of Embodiment 1 of this invention. It is a hardware block diagram of Embodiment 1 of this invention. It is a program element on the program storage means of the present invention. It is an example of the model comprised from the model element of this invention. (A) It is an example which converts the model of this invention into a program element by a conversion rule element. (B) A correspondence table of model elements, program elements, and conversion rule elements of the present invention. (A) An embodiment in which the model of the present invention is converted into a program element by a conversion rule element. (B) It is an Example of the correspondence table of the model element of this invention, a program element, and a conversion rule element. (A) It is the Example which converts the entity of this invention by the conversion rule element 1. FIG. (B) It is an Example of the correspondence table of the entity and program element of this invention. (A) It is an embodiment in which the control of the present invention is converted by the conversion rule element 2. (B) It is an Example of the correspondence table of the control of this invention and a program element. (A) An embodiment in which the boundary of the present invention is converted by the conversion rule element 3. (B) An example of a correspondence table between the boundary and program elements of the present invention. It is a flowchart of operation | movement of Embodiment 1 of this invention. It is a flowchart of the operation | movement of the version comparison of Embodiment 1 of this invention. It is a block diagram of Embodiment 2 of this invention. This is a conventional model-driven development method.

Explanation of symbols

1 Model Element 2 Model Element 3 Model Element 21 Model Element 22 Model Element 30 Model 31 Entity 32 Control 33 Boundary 35 DB Source File 36 EJB Source File 37 JSP Source File 40 Model Driven Development Device 41 Control Means 42 Generator 43 Conversion Rule Element 1
44 Conversion rule element 2
45 Conversion rule element 3
51 Source file 1
52 Source file 2
53 Source file 3
60 Sales Management Model 61 Sales DB
62 Input Control 63 Sales Input Screen 65 URIAGE_TABLE
66 UriageBean
67 Urage. JSP
100 Computer 110 Model storage means 120 Conversion rule storage means 130 Program storage means 140 Conversion rule element version 150 Model element version acquisition means 160 Program element version acquisition means 170 Version comparison means 180 Model element acquisition means 190 Conversion rule element acquisition means 200 Program generation Means 210 Model editing means 220 Conversion rule editing means 230 Host control means 250 CPU
260 Volatile memory 270 Hard disk 280 Bus 330 Model 340 Generator 351 Source file 1
352 Source file 2
353 Source File 3

Claims (10)

In a model-driven development device that generates a source file of the program according to a predetermined conversion rule from a model of a program to be developed using a model-driven development method,
The model is divided into a plurality of model elements that are basic units of the generation conversion, a version is given to each model element, and the conversion rule is converted into a plurality of conversion rule elements associated with the model element. Control means for dividing and assigning a version to each of the conversion rule elements, and updating the version of only the model element to be changed and / or only the change rule element when the model and / or the change rule is changed When,
The generation is performed using the model element to be changed and the conversion rule element corresponding to the model element and / or the change rule element to be changed and the model element corresponding to the change rule element, and for each of the plurality of model elements Generator means for generating a plurality of source files and attaching each version of the model element and the conversion rule element at the time of generation to the source file;
Have
The generator means, when the source file is updated, when the version of the conversion rule and the model element is different from the version of the conversion rule and the model element at the time of previous generation attached to the source file, A model-driven development device characterized by generating a source file. The generator means includes
Model storage means for storing a plurality of model elements and their versions;
Conversion rule storage means for storing a plurality of the divided conversion rule elements and their versions;
A program storage means for storing a program element that is a plurality of generated source files, a version of the model element when the program element is generated, and a version of the conversion rule element in association with each other;
The version of the model element is compared with the version of the model element when the corresponding program element is generated, and the version of the conversion rule element is compared with the version of the conversion rule element when the corresponding program element is generated. Version comparison means for comparing and outputting the results;
A conversion rule when the version of the model element does not match the version of the model element when the version of the model element is generated from the version comparison means or when the version of the program element corresponding to the version of the conversion rule element is generated When the result of the element version not matching is received, a program element is generated using the model element and the conversion rule element, and the version of the model element and the version of the conversion rule element are added to the program storage means A program generation means for writing to
The model-driven development device according to claim 1, comprising: In a model-driven development device that generates a source file of the program according to a predetermined conversion rule from a model of a program to be developed using a model-driven development method,
The generation is performed using the model element to be changed and the conversion rule element corresponding to the model element and / or the change rule element to be changed and the model element corresponding to the change rule element. Generator means for attaching the version of the model element and the conversion rule element at the time of individual generation to the source file,
The generator means, when the source file is updated, when the version of the conversion rule and the model element is different from the version of the conversion rule and the model element at the time of previous generation attached to the source file, A model-driven development device characterized by generating a source file. The generator means includes
Model storage means for storing a plurality of model elements and their versions;
Conversion rule storage means for storing a plurality of divided conversion rule elements and their versions;
A program storage means for storing a program element that is a plurality of generated source files, a version of the model element when the program element is generated, and a version of the conversion rule element in association with each other;
The version of the model element is compared with the version of the model element when the corresponding program element is generated, and the version of the conversion rule element is compared with the version of the conversion rule element when the corresponding program element is generated. Version comparison means for comparing and outputting the results;
A conversion rule when the version of the model element does not match the version of the model element when the version of the model element is generated from the version comparison means or when the version of the program element corresponding to the version of the conversion rule element is generated When the result of the element version not matching is received, a program element is generated using the model element and the conversion rule element, and the version of the model element and the version of the conversion rule element are added to the program storage means A program generation means for writing to
The model-driven development device according to claim 3, wherein   5. The model-driven development management device according to claim 1, wherein the plurality of model elements include an entity, a control, and a boundary.   Model editing means for editing the model element of the model and updating the version of the model element to be changed, and conversion rule editing for editing the conversion rule element of the conversion rule and updating the version of the conversion rule element to be changed The model drive development device according to claim 3 or 4, further comprising: means. In a model-driven development method for generating a source file of the program according to a conversion rule for a model of a program to be developed using a model-driven development method,
The model is divided into a plurality of model elements that are basic units of the generation conversion, a version is given to each model element, and the conversion rule is converted into a plurality of conversion rule elements associated with the model element. Dividing and assigning a version to each of the conversion rule elements, and when the model and / or the change rule is changed, update only the model element to be changed and / or only the change rule element,
Storing a plurality of said model elements and their versions;
Storing a plurality of the divided conversion rule elements and their versions;
A program element that is a plurality of generated source files, a version of the model element when the program element is generated, and a version of the conversion rule element are stored in association with each other,
The version of the model element is compared with the version of the model element when the corresponding program element is generated, and the version of the conversion rule element is compared with the version of the conversion rule element when the corresponding program element is generated. Compare and
The version of the model element does not match the version of the model element when the corresponding program element is generated, or the version of the conversion rule element does not match the version of the conversion rule element when the corresponding program element is generated A model-driven development method, wherein a program element is generated using the model element and the conversion rule element, and the version of the model element and the version of the conversion rule element are added and stored.   The model-driven development method according to claim 6, wherein the plurality of model elements include an entity, a control, and a boundary. Model-driven development equipment using model-driven development techniques
The model is divided into a plurality of model elements that are basic units of the generation conversion, a version is given to each model element, and the conversion rule is converted into a plurality of conversion rule elements associated with the model element. Control means for dividing and assigning a version to each of the conversion rule elements, and updating the version of only the model element to be changed and / or only the change rule element when the model and / or the change rule is changed ,
Model storage means for storing a plurality of model elements and their versions;
Conversion rule storage means for storing a plurality of divided conversion rule elements and their versions;
Program storage means for storing a plurality of generated program files as program files, the version of the model element when the program element is generated, and the version of the conversion rule element in association with each other,
The version of the model element is compared with the version of the model element when the corresponding program element is generated, and the version of the conversion rule element is compared with the version of the conversion rule element when the corresponding program element is generated. Version comparison means for comparing and outputting the result,
A conversion rule when the version of the model element does not match the version of the model element when the version of the model element is generated from the version comparison means or when the version of the program element corresponding to the version of the conversion rule element is generated When a result of the element versions not matching is received, a program element is generated using the model element and the conversion rule element, and the version of the model element and the version of the conversion rule element are added to the program storage means. Writing program generation means,
Model-driven development program to function as   The model-driven development program according to claim 9, wherein the plurality of model elements include an entity, a control, and a boundary.

Images