JP6011712B2 - Correction management device, correction management method, and correction management program - Google Patents

Description

  The present invention generally relates to a correction management apparatus, a correction management method, and a correction management program. More specifically, the present invention relates to software updates and maintaining consistency between designs and programs.

  Changes in requirements or specifications often occur in software development, particularly in agile software development. As changes occur, consistency between functional specifications, design documents, implementations, test specifications, and test programs must be maintained.

  Typically, consistency between design documents, implementations, test specifications, and programs is maintained manually. As a result, each time a change occurs, it is necessary to update the design document and code in the program, recompile the updated program, and re-execute. As a result, each change adds additional costs and slows down the development cycle. This problem is an obstacle for software development.

  Advances in technology have enabled the cost of updating to be reduced while maintaining the integrity of the computing system software to some extent. Patent Document 1 discloses a system for generating a test specification and a test code from an input design definition. Patent Document 2 discloses another related system. The purpose of these systems is to set the values for the attributes of an object all at once with relatively few codes. Patent Document 3 discloses a system that generates a script from a) a definition including a data type and a data name, and b) a standard scenario or a standard script. Patent Document 4 discloses a program design management system. In this system, the metadata includes file configuration information and is modified by the designer during the design process. The system reflects changes in the metadata for the corresponding file. Other related systems are disclosed in Patent Documents 5 to 8.

Japanese Patent Laid-Open No. 2007-066204 JP 2004-252708 A JP 2002-366387 A JP 2006-79212 A JP 2004-220330 A JP 2006-099743 A JP 2007-011467 A JP 2011-128940 A

  When changes occur to system requirements or specifications, it is necessary to ensure that the changes are properly reflected in the design and implementation. Furthermore, if it is involved in testing, it is necessary to maintain consistency between the specification, design, implementation, test specification, and test program.

  The problem is that maintaining consistency between design documents, implementations, test specifications, and test programs is done inefficiently by the manual operation of possibly separate designers, developers, and testers. is there. If some changes are made to one of the design document and the implementation, the techniques disclosed in Patent Documents 1 to 8 cannot maintain consistency.

  An object of the present invention is to provide a correction management apparatus, a correction management method, and a correction management program that solve the above-described problems.

According to the present invention, the above problem is
Design model storage means for storing a design model describing the structure of an object in a modeling language;
Program storage means for storing an application program describing an object in a programming language;
Metadata storage means for storing metadata describing the structure of the object;
Extract changes in the structure from modifications made to one of the application program and the design model, update the metadata according to the change in the structure, and to the other of the application program and the design model according to the updated metadata This is solved by a correction management device comprising an operating means for reflecting changes in the structure.

According to the present invention, the above problem is
Store the design model that describes the structure of the object in the modeling language,
Store application programs that describe objects in programming languages;
Store metadata describing the structure of the object,
Extract changes in the structure from modifications made to one of the application program and the design model, update the metadata according to the change in the structure, and to the other of the application program and the design model according to the updated metadata And a modification management method comprising reflecting changes in the structure.

According to the present invention, the above problem is
Store the design model that describes the structure of the object in the modeling language,
Store application programs that describe objects in programming languages;
Store metadata describing the structure of the object,
Extract changes in the structure from modifications made to one of the application program and the design model, update the metadata according to the change in the structure, and to the other of the application program and the design model according to the updated metadata This is solved by a correction management program that causes a computer to execute a process that reflects a change in the structure.

  The present invention has an effect of reducing the cost and burden for maintaining the consistency between the design document and the implementation.

It is a simplified block diagram illustrating a modification management device. FIG. 3 is a simplified block diagram illustrating a test control / execution module. It is a simplified block diagram illustrating a test part. It is a figure showing a metadata record. FIG. 4 is a simplified block diagram illustrating a metadata manipulation module and metadata that maintains it. It is a figure showing the design model of the account class (class Account) shown in a UML class diagram. It is a figure which shows the flow of operation | movement of a test system. It is a figure which shows the flow of operation | movement of a metadata operation module when some change arises in a source code. FIG. 6 is a simplified block diagram illustrating a correction management device according to a second embodiment.

  While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein by way of detailed description. However, it is not intended to limit the invention to the particular forms disclosed, but on the contrary, the invention is within the spirit and scope of the invention as defined by the appended claims. It should be understood that all equivalents and alternatives are intended to be covered.

  Referring to FIG. 1, a simplified block diagram of a test system 100 is represented. The test system 100 of FIG. 1 is an example of the correction management apparatus 300 of the present invention. The test system 100 is connected to a design model input module 102 and a test result report module 112. The design model input module 102 may be a terminal device. The test result reporting module 112 may be a display device.

  The test system 100 includes a metadata operation module 106, a test control / execution module 110, a design model storage unit 200, a program storage unit 201, a test component storage unit 202, and a metadata storage unit 203.

  The metadata operation module 106 and the test control / execution module 110 function when a processor of the test system 100 that is a computer reads and executes a program stored in the memory. The equivalent function can be realized by a hardware unit such as an integrated circuit. The design model storage unit 200, the program storage unit 201, the test part storage unit 202, and the metadata storage unit 203 may be a memory device such as a hardware disk drive or an IC memory.

  Also shown in FIG. 1 are components of the system under test (SUT) 114. The test target system 114 is a target to be tested by the test system 100, the design model 120, and the test component 116. The design model 120 represents the structural and behavioral aspects of the system under test. The test component 116 is a component that communicates with the test target system 114 or an external component that realizes a behavioral aspect of the test. The test target system 114, the test target system 114, and the test component 116 include a design model storage unit 200, a program storage They are stored in the device 201 and the test part storage device 202, respectively.

  For example, the test target system 114 may be software such as an application program. The test target system 114 describes the structure and behavior of objects in the application system using an object-oriented language such as C ++ or JAVA (registered trademark) language, and operates on a personal computer through a graphical user interface. Another example of the system under test 114 is a client / server program that runs on one or more computers connected by a network or communication channel. A further example of the system under test 114 is a control program that runs on the microprocessor of a mobile device such as a mobile phone or tablet computer. The devices, systems, and methods for practicing the invention work equally well with any type of system under test 114, and the exemplary embodiments herein provide for the claimed invention in some way. It is not intended to be limiting.

  The test component 116 shown in FIG. 3 defines a test sequence and test operating conditions. The test component 116 may be composed of one or more software modules. The one or more software modules define a sequence of operations that are performed to initialize conditions under which the system under test 114 operates, confirm proper behavior of the system under test 114, and / or By providing input to 114, it is possible to interact with the system under test 114. For example, the test component 116 may be comprised of a software module in order to verify the proper behavior of a scenario for withdrawing cash from a bank account using an ATM (Automated Teller Machine). The software module sets the withdrawal account, the PIN code and card database for authentication, the sequence of withdrawal operations performed by the banking system, and the deposit withdrawal input to the ATM.

  The test part 116 may be generated manually by entering the program code into a text editor that can edit the source code. Alternatively, the test part 116 may be partially automatically generated from the prototype and then modified as required by a text editor. For example, the test component 116 may be modified to set a plurality of operating conditions for the system under test 114 such that the operating conditions change from scenario to scenario.

The design model 120 may be described by a modeling language that can represent structural and / or behavioral aspects of the system under test 114. The design model 120 may describe the structural and behavioral aspects of the objects in the system under test 114. For example, the design model 120 may include a UML (Unified Modeling Language) class diagram, an object diagram, a state transition diagram, a sequence diagram, and a use case diagram. Alternatively, the design model 120 may be described by JML (Java Modeling Language), or other type of modeling language. Examples of "account (Account)" class design model objects in banking applications are represented by the UML class diagram in Figure 4. As shown in FIG. 4 , the name of the class is “Account”. In the second part, class attributes (aka member variables) are listed in separate lines. Each line indicates a pair of attribute name and attribute type. In the third part, the methods of the class are listed on separate lines. Each line shows a method name and return type pair with a parameter list in parentheses.

  The test control / execution module 110 provides an interface between the test component 116 and the system under test 114 and performs tests as defined by the test component 116. In the preferred embodiment, test control / execution module 110 logically includes test control 122 and test execution 124, as shown in FIG. Test control 122 may provide control over test operations such as creating objects defined in test component 116, starting and ending tests. Test execution 124 may be implemented by at least an interpreter or virtual machine that actually executes program code to implement the test behavior specified by test component 116. Test run 124 should have dynamic class loading and dynamic object binding capabilities to support dynamic updates due to changes in the metadata described below.

  The design model input module 102 is an interface that can receive input describing the design model 120 of the system under test 114 and can provide output data stored in the design model storage unit 200. Also good. In a preferred embodiment, the design model input module 102 is a computer terminal having a keyboard, pointing device, display, and graphical user interface that can be used to enter or edit the design model 120.

  The test result reporting module 112 may be a physical display terminal or interface that can provide video and / or audio output and / or data output to a storage device or memory. In the preferred embodiment, the test report module 112 is a computer terminal having a graphical user interface connected to the test control / execution module 110. Alternatively, the test report module 112 may communicate with the test control / execution module 110 via a network or some communication medium.

The metadata storage unit 203 stores metadata as shown in FIG. The metadata is a set of data that provides specifications regarding the structure of objects in the system under test 114. The structure of an object includes the class name of the object, the name and type of the class attribute, the name and return type of the class method, and the name and type of the argument of the class method. For example, the record of metadata described in the XML shown in FIG. 4 provides a class specification with attributes and methods of the class specified by the design model of FIG. The above description, examples, and components of FIGS. 4 and 6 are merely exemplary and are not intended to limit the claimed invention in any way.

  The metadata manipulation module 106 shown in FIG. 1 and shown in more detail in FIG. 5 is a module that can generate metadata 126, 128, 130. That is, the metadata operation module 106 generates (a) metadata 126 of each object in the design document from the design model 120, (b) generates metadata 128 from each object of the test target system 114, (c ) Metadata 130 is generated from each object of the test part 116. Hereinafter, each of the design model 120, the test target system 114, and the test part 116 refers to a system component. The metadata operation module 106 further has the ability to perform the following processes (d) to (g). (D) detecting a modification made to at least one of the system components, hereinafter referred to as the first system component. (E) Updating the metadata of the first system component according to the modification. (F) By applying the updates made to the metadata of the first system component to the metadata of the other two system components that are the second and third system components, Maintaining consistency between the metadata 126 in the design model 120, the corresponding object metadata 128 in the system under test 114, and the corresponding object metadata 130 in the test part 116. (G) Reflecting changes made to the metadata of the second and third system components to the second and third system components, respectively.

  For example, in the above process (d), the metadata operation module 106 detects a modification to the design model 120. In process (e), the metadata manipulation module 106 updates the metadata 126 according to the modification. In process (f), the metadata manipulation module 106 modifies the metadata 128 and 130 to maintain consistency between the metadata 126, 128, 130. In the process (g), the metadata operation module 106 reflects changes made to the metadata 128 and changes made to the metadata 130 to the test part 116 in the test target system 114.

  In processes (a), (b), and (c), the metadata manipulation module 106 may use the syntax rules of the language in which the system component is described in order to extract metadata from the system component. . For example, when the test target system 114 and the test part 116 are described in the C ++ language, the metadata operation module 106 uses the C ++ language syntax rule to extract the attribute name and the attribute type from the test target system 114 and the test part 116. Is used.

  In process (d), the metadata manipulation module 106 may receive a notification from a text editor program that modifies system components.

  In process (e), the metadata manipulation module 106 may receive data of modifications made to the first system component from the text editor program. Thereafter, the syntax rules of the language in which the first system component is described may be used to determine where and how modifications to the metadata of the first system component must be made. The metadata manipulation module 106 uses UML syntax rules and semantic rules to change the type of attribute in the metadata 126 and detects that the type of attribute is changed in the design model 120.

  In process (f), the metadata manipulation module 106 updates the metadata of the second and third system components so that the metadata 126, 128, and 130 describe the same structure for each corresponding object. . For example, the corresponding method has the same name and the same return type in each metadata 126, 128, and 130.

  In the process (g), the metadata operation module 106 refers to the updated version of the metadata of the second system component, and uses the syntax rules of the language in which the second system component is described, Detect inconsistencies between the two system components. Then, the metadata operation module 106 modifies the second system component according to the metadata. For example, if the second system component is the SUT 114 written in the C ++ language, the metadata manipulation module 106 uses the C ++ language syntax rules to determine the type of attribute in the metadata 128 and the program code of the SUT 114. Detects discrepancies between definitions of variables corresponding to attributes in Then, the metadata operation module 106 changes the type of the variable in the definition in the SUT 114 according to the metadata 128. The metadata operation module 106 processes the third system component in the same manner.

  Inconsistencies between them can be caused by modifications to the design model 120 and / or by modification of the program code of the system under test 114 or the program code of the test part 116.

  For example, the metadata of FIG. 4 illustrates the account 126 metadata 126 in the design model 120. In the case of an implementation of the account class in the system under test 114 as program code, the metadata manipulation module 106 maintains a dependency from the account class implementation metadata 128 to the account class design model 120 metadata 126. . That is, each implemented method of the account class in the system under test 114 has a relationship with a corresponding component of the method metadata 126 of the class design model 120. Further, in the case of an account (Account) instance object called “bobAccount” in the test component 116, the metadata operation module 106 determines the dependency relationship from the instance object “bobAccount” to the metadata 126 of the account class design model 120. maintain.

  Changes detected by the metadata manipulation module 106 include any changes that occur in the design model 120, the system under test 114, and the test component 116. That is, changes that occur in the design model 120 in accordance with changes in the design document, changes that occur in the test target system 114 in accordance with modification of the program code of the test target system 114, and in the test part 116 in accordance with correction of the program code of the test part 116. Includes changes that occur.

  The metadata manipulation module 106 may poll for changes in the design model 120, the test part 116, and the test target system 114. Further, the metadata manipulation module 106 may notify the test control / execution module 110 regarding any changes made to the system under test 114 and / or the test component 116. As a result, module 110 can update the runtime object and re-run the test.

  To summarize the operation of the test system 100, the user uses the design model input module 102 to generate a design model 120. Thereafter, the user mounts the test target system 114 and generates the test component 116 as designed. Thereafter, the metadata operation module 106 generates metadata 126, 128, and 130 from the design model 120, the test part 116, and the test target system 114. When each of the above pre-processing is completed, the test system 100 is ready to test the test target system 114, although not necessarily in the above order.

  In the first test, the test control / execution module 110 reads the test part 116 and executes the test as specified by the test part 116. The test component 116 interacts with the test target system 114 to call, for example, an API provided by the test target system 114 and execute the steps. The test result of each action script is recorded for reporting by the test result reporting module 112.

  FIG. 7 is a flowchart describing the operation of the automated test process of the present invention. Those skilled in the art will recognize that the test process may be performed with manual intervention to handle changes, interrupt and start the test, or may be performed in a fully automated process according to the present invention. You will recognize the good. Furthermore, the present invention allows a hybrid approach that incorporates both manual and fully automated processes to handle changes that occur within the design model 120. In essence, the present invention relates to the relationship between the design model 120 and the metadata 126, the dependency between the metadata 128 and objects in the implementation of the system under the test 114, and the metadata 130 in the implementation of the test component 116. Define dependencies with objects. Further, the present invention utilizes metadata 126, 128, 130 as a means for reflecting changes. One skilled in the art will recognize that the present invention is suitable for providing an automated test process as well as an automated process in combination with known manual procedures when a fully automated process is not effective.

  Changes to the design model 120 that the test system 100 can handle include: method name and return type changes, data name and argument type changes in method signatures, class attribute names and type changes, class attributes Includes renaming, adding new methods, adding new attributes, and removing existing attributes and methods. Changes to the SUT 114 and test component 116 that the test system 100 can handle include structural changes in the program code as described above.

  The automated test process begins at operation 200 where a design model 120 is generated. This can be done by the design model input module 102. In operation 204, the system under test 114 is implemented as designed, and then in operation 206, a test component 116 for testing system behavior is generated.

  Thereafter, in operation 208, the metadata 126 of the design model 120, the test target system 114, and the test part 116 is generated by the metadata manipulation module 106. The generation of the metadata 126, 128, and 130 may be realized by a transformer that is a software component. The transformer functions like a compiler that can convert between XML descriptions of the metadata 126, 128, and 130 from the representation of the source code (and vice versa). The representation of the source code may be (a) the input format of the design model 120, (b) the program source code of the SUT 114, or (c) the program source code of the test part 116. Each of these three representations may have a transformer. Each transformer is (a) from design model 120 to design model 126 metadata, (b) from SUT 114 to SUT 128 metadata, and (c) from test part 116 to test part 130 metadata. Respectively.

  Next, an automatic test process is initiated at operation 210 where the test control / execution module 110 determines whether there are any untested test components 116. If so, operation 212 reads an untested test component 116 for testing, and operation 214 performs a test of test component 116. In operation 216, the test result is then recorded. The test process then continues by looping back to operation 210, which checks for the presence of untested test components 116. If all of the test components 116 have been tested, the test process ends and operation 218 creates a test result report.

  FIG. 8 shows the processing flow of the metadata manipulation module 106 when some changes are made to the source code. The term “source code” herein may refer to design model 120 or SUT 114 or test component 116 (see FIG. 5). Initially before the change occurs, the metadata of the design model 126, the metadata of the SUT 130, and the metadata of the test part 128 are the same or equivalent to the state in which they describe the same structure of the object.

  In operation 300, a change in the source code is detected. This can be achieved by binding an observer, which is a software component that observes and automatically notifies some state change for each of the source code. The observer notifies the metadata operation module when some state change 106 occurs in the source code, and provides the content before (β) and after (α) of the change. The contents of changes β and α will be used by subsequent operations that modify the metadata. Once a change is detected, operation 302 instructs the test control / execution module 110 to pause execution by instructing the virtual machine to execute to pause.

Thereafter, in operation 304, the source code metadata is modified according to the change. It is assumed that the XML description of the source code metadata by S is represented (see the XML description in FIG. 4A). As described in operation 208, operation 304 can be implemented by converting the contents of the changes β and α to the XML description of the metadata with a corresponding transformer that generates such metadata.
Conversion
β⇒m (β),
α⇒m (α),
Where m (β) and m (α) are XML descriptions of the metadata of β and α, respectively, and then replace the portion of S corresponding to m (β) by m (α) To do.

  For example, a case where a change is made to the design model 120 (source code) is illustrated. The data type of the argument “amount” of the method “credit” is changed from an integer to a string as a result of the modification in the specification. In operation 304, the metadata of the design model 126 is updated. As shown in FIG. 4B, the XML description corresponding to the metadata is changed from <arg type = "Integer" name = "amount"> to <arg type = "String" name = "amount">. This can be done by the metadata operation module 106 to be replaced.

  In operation 306, the metadata of the other two system components that are not the source code is modified. In the same manner, the metadata operation module 106 replaces m (β) with m (α) in the corresponding part in S. Continuing from the previous example, the metadata operation module 106 changes the XML description corresponding to the metadata from <arg type = "Integer" name = "amount"> to <arg type = "String" name = "amount">. Is modified to modify the metadata of the SUT 128 and the metadata of the test part 130.

  In operation 308, the metadata change is reflected on the two system components other than the source code. As described in operation 208, this operation can be accomplished by a corresponding transformer. From the previous example, the SUT 114 transformer converts the new account class from the modified metadata 128. In addition, the transformer of the test part 116 converts a new object instantiated from the new account class in the modified metadata 130.

  Once the change is reflected, operation 310 instructs the virtual machine that has been paused from execution of operation 302 to reload the updated runtime object and resume test execution. Thereby, operation 310 instructs test control / execution module 110 to update the runtime object.

  According to an embodiment of the present invention comprising the metadata manipulation module 106, changes in the design model 120 are reflected in the implementation of the test target system 114 and the test component 116 through conversion of the metadata 126, 128, 130. be able to. Similarly, changes in the implementation of the system under test 114 can be reflected in the design model 120 and the test component 116 through conversion of the metadata 126, 128, 130. This can reduce the cost and effort to maintain consistency between design documents, implementations and test components. In accordance with an embodiment of the present invention comprised of test control / execution module 106, modifications in system under test 114 or test component 116 are validated in the test by dynamic rebinding without manual interruption. Can be. This can reduce time and minimize the considerations needed to control the test process.

  In an improved embodiment of the present invention, only one piece of metadata may be present in the modification management device 200. In this embodiment, the metadata operation module 106 may perform only one of the processes (a), (b), and (c), and does not necessarily perform the process (f).

  In another improved embodiment of the present invention, only two of the system components are present in the modification management device 300. For example, only the design model 120 and the test target system 114 may exist in the correction management apparatus 300.

<Second Preferred Embodiment>
Referring to FIG. 9, a simplified block diagram of a modification management device 300 in the second preferred embodiment is represented. The correction management apparatus 300 includes a design model storage unit 200, a program storage unit 201, a metadata storage unit 203, and a metadata operation unit 106.

  The design model storage device 200 stores a design model 120 that describes the structure of an object in a modeling language. The program storage device 201 stores a test target system. The system under test is an application program that describes objects in a programming language. The metadata storage device 203 stores metadata describing the structure of the object.

  The metadata operation unit 106 extracts a change in the structure from a modification made to one of the application program and the design model 120. Further, the metadata operation unit 106 updates the metadata according to the change in the structure, and reflects the change in the structure to the other of the application program and the design model 120 according to the updated metadata.

  Costs and burdens for maintaining consistency between the design document and the implementation are reduced. This is because a change in the design model 120 can be reflected in the implementation of the test target system 114 through metadata conversion by the metadata operation module 106 (and vice versa).

  The present invention can be used for computer software test automation, but is not particularly limited to agile software development. The present invention can be used to check the consistency between the functional specifications of the test target system and the test specifications.

DESCRIPTION OF SYMBOLS 100 Test system 102 Design model input module 106 Metadata operation module 110 Test control / execution module 112 Test result report module 114 Test target system 116 Test part 120 Design model 122 Test control 124 Test execution 126 Design model metadata 128 Test part metadata Metadata 130 Metadata of test target system 200 Design model storage unit 201 Program storage unit 202 Test part storage device 203 Metadata storage unit 300 Correction management device

Claims (11)

Design model storage means for storing a design model describing the structure of an object in a modeling language;
Program storage means for storing an application program that describes the object in a programming language;
Metadata storage means for storing metadata describing the structure of the object;
Extracting changes in the structure from modifications made to one of the application program and the design model, updating the metadata in accordance with the changes in the structure, and applying the application program and in accordance with the updated metadata An operating means for reflecting the change in the structure to the other of the design models;
Test part storage means for storing a test part for testing the application program,
The operating means extracts the change in the structure from a modification made in one of the application program, the design model , and the test part, and the operation means extracts the change in the application program, the design model, and the test part. A correction management device that reflects the change in the structure to the other two. The structure of the object includes an attribute name and type, a method, and an argument of the method, and the change in the structure extracted and reflected by the manipulation means is a change in the name and / or the type The correction management device according to claim 1, comprising: The structure of the object includes method attributes and names, and the changes in the structure extracted and reflected by the manipulation means include new attributes and / or addition of new methods and / or The modification management device according to claim 1, comprising removal of existing attributes and / or existing methods. The operation means 1) generates first metadata and second metadata from the design model and the application program, respectively, and stores them in the metadata storage means, and 2a) stores the first metadata. Referring to, extract the change in the structure from the modifications made in the design model, reflect the change to the first metadata and the second metadata, and then the second 2b) reflecting the change in the structure to the application program, or 2b) referring to the second metadata and from the modifications made in the application program The change is extracted, the change is reflected to the first metadata and the second metadata, and then the first metadata is referred to. Modification management apparatus according to any one of claims 1 to 3 to reflect the changes in the structure with respect to the design model. The correction management apparatus according to claim 4 , further comprising: a test control unit that tests the application program using the test component after the operation unit finishes reflecting the change. A change in the structure is extracted from a modification made to one of an application program that describes the object in a programming language and a design model that describes the structure of the object in a modeling language, and the change in the structure Updating metadata describing the structure of the object and reflecting the change in the structure to the other of the application program and the design model according to the updated metadata;
In the reflection, the change in the structure is extracted from a modification made in one of the application program, the design model , and a test part for testing the application program, and the application program, A correction management method for reflecting the change in the structure to the other two of the design model and the test part. The structure of the object, the name and type of attributes, including the method and arguments of the method, the change of the extracted is reflected in the structure, according to claim 6, including changes of the name and / or the type The correction management method described in 1. The structure of the object includes method attributes and names, and the changes in the extracted and reflected structure may include new attributes and / or new method additions and / or existing attributes and / or Alternatively, the correction management method according to claim 6 , comprising removing an existing method. A change in the structure is extracted from a modification made to one of an application program that describes the object in a programming language and a design model that describes the structure of the object in a modeling language, and the change is made according to the change in the structure Updating metadata describing the structure of the object and reflecting the change in the structure to the other of the application program and the design model according to the updated metadata;
In the reflection, the change in the structure is extracted from a modification made in one of the application program, the design model , and a test part for testing the application program, and the application program, A correction management program for causing a computer to execute a process of reflecting the change in the structure for the other two of the design model and the test part.
The structure of the object, the name and type of attributes, including the method and arguments of the method, the change in the structure that is reflected is extracted, according to claim 9, including changes of the name and / or the type Fix management program described in. The structure of the object includes method attributes and names, and the changes in the extracted and reflected structure may include new attributes and / or new method additions and / or existing attributes and / or Alternatively, the correction management program according to claim 9 including removal of an existing method.

Images