TITLE OF THE INVENTION

A modification management apparatus, a modification management method and a modification management program

TECHNICAL FIELD

This invention relates in general to a modification management apparatus, a modification management method and a modification management program. More specifically, this invention relates to updating software and keeping consistencies among designs and programs.

BACKGROUND ART

In software development, especially in agile software development, changes in requirements or specifications can happen frequently. When changes happen, we need to maintain the consistencies among functional specifications, designs, implementation, test specifications and test programs.

The consistency among designs, implementation and test specifications and programs are generally maintained by hands. As a consequence, we need to update the designs and the code in programs, recompile and re-execute the updated programs every time when changes happen. Therefore, every time changes are made it adds up additional cost and slowdown the development cycle. This problem is an obstacle for software development.

Advances in technology have made it possible to reduce the cost for updating while keeping consistencies of software for computing systems to some extent. A system for generating test specifications and test codes from an inputted design definition is disclosed in the patent literature 01. Another relevant system is disclosed in the patent literature 02. This system aims to set values for the attributes of an object at once in a lump with relatively less code. The patent literature 03 discloses a system which generates the scripts from a) definition including data types, data names etc. and b) standard scenarios or standard scripts. Patent literature 04 discloses a program design management system. In this system the metadata includes configuration information of files and is modified by the designers during design processes. The system reflects the changes in the metadata to the files corresponding to it. Other relevant systems are disclosed in the patent literature 05 - 08.

CITATION LIST

[Patent , literature 01] Japanese Patent Application Laid-Open No.2007-066204 [Patent literature 02] Japanese Patent Application Laid-Open No.004-252708 ^>

[Patent literature 03] Japanese Patent Application Laid-Opeh No.2002-366387

[Patent literature 04] Japanese Patent Application Laid-Open No.2006-79212

[Patent literature 05] Japanese Patent Application Laid-Open No.2004-220330

[Patent literature 06] Japanese Patent Application Laid-Open No.2006-099743

[Patent literature 07] Japanese Patent Application Laid-Open No.2007-011467

[Patent literature 08] Japanese Patent Application Laid-Open No.2011-128940

DISCLOSURE OF THE INVENTION TECHNICAL PROBLEM

When changes happen in the requirements or specifications of a system, we need to make sure that the changes are properly reflected to its design and implementation. Moreover, when testing is of concern, we need to maintain the consistencies among specifications, designs, implementation, test specifications and test programs.

The problem is that maintaining the consistency among designs, implementation, test specifications and test programs are inefficiently done by hands of designers, developers and testers, who are possibly different persons. The technologies disclosed in the patent literatures 01 - 08 do not keep the consistency when some modifications are done to one of designs and implementation.

The objective of the invention is to provide a modification management apparatus, a modification management method and a modification management program to solve the problem above.

MEANS FOR SOLVING THE PROBLEM

In accordance with this invention, the above problems have been solved by a modification management apparatus comprising:

a design model storage means which stores a design model which describes structure of objects in a modeling language, ,

a program storage means which stores an application program which describes said objects in a programming language, a metadata storage means which stores a metadata which describes said structure of said objects, and

a manipulation means which extracts a change in said structure from modifications made in one of said application program and said design model, updates the metadata according to said change in said structure, and reflects said change in said structure to the other one of said application program and said design model according to said updated metadata.

In accordance with this invention, the above problems have been solved by a modification management method comprising:

memorizing a design model which describes structure of objects in a modeling language,

memorizing an application program which describes said objects in a programming language,

memorizing a metadata which describes said structure of said objects, extracting a change in said structure from modifications made in one. of said application program and said design model,

updating the metadata according to said change in said structure, and reflecting said change in said structure to the other one of said application program and said design model according to said updated metadata.

In accordance with this invention, the above problems have been solved by a modification management program which causes a computer to perform a process comprising:

memorizing a design model which describes structure of objects in a modeling language,

memorizing an application program which describes said objects in a programming language,

memorizing a metadata which describes said structure of said objects, extracting a change in said structure from modifications made in one of said application program and said design model,

updating the metadata according to said change in said structure, and reflecting said change in said structure to the other one of said application program and said design model according to said updated metadata.

ADVANTAGEOUS EFFECTS OF INVENTION

The effect of this invention is that the cost and effort for maintaining consistency among design and implementation are reduced. BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a simplified block diagram illustrating a modification management apparatus.

Fig. 2 is a simplified block diagram illustrating a test control and execution module. -

Fig. 3 is a simplified block diagram illustrating a test component.

Fig. 4 depicts a metadata record.

Fig. 5 is a simplified block diagram illustrating a metadata manipulation module and the metadata it maintains.

Fig. 6 depicts a design model of class Account shown in UML class diagram.

Fig. 7 illustrates the flow of operations of a testing system

Fig. 8 illustrates a flow of operation of the metadata manipulation module when some changes happened in a source.

Fig. 9 is a simplified block diagram illustrating a modification management apparatus in the second embodiment.

MOST PREFERRED MODE TO CARRY OUT THE INVENTION

While the invention is susceptible to various modifications and alternative forms, a specific embodiment thereof has been shown by way of example in the drawings and will be described herein by detail. It should be understood, however, that it is not intended to limit the invention to the particular form disclosed, but on contrary, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the accompanying claims.

Referring to Fig.1, a simplified block diagram of a testing system 100 is depicted. The testing system 100 in Fig. 1 is an example of a modification management apparatus 300 of this invention. The testing system 100 is connected to a design model input module 102 and a test results reporting module 112. The design model input module 102 may be a terminal device. The test results reporting module 112 may be a display device.

The testing system 100 includes a metadata manipulation module 106, a test control and 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 manipulation module 106 and the test control and execution module 110 function when a processor of the testing system 100, which is a computer, reads and executes a program stored in the memory. The equivalent functions can be realized by hardware units such as integrated circuits. The design model storage unit 200, the program storage unit 201, the test component storage unit 202 and the metadata storage unit 203 may be memory devices like hardware disk drives or IC memories.

Also shown in Fig.l is an entity of a system under test (SUT) 114, which is the target to be tested by the testing system 100, a design model 120, which expresses the structure aspects and behavioral aspects of the system under test, and test component 116, which is a component that communicates with the system under test 114 or external entities to realize a test behavior. They are stored in the design model storage unit 200, the program storage unit 201 and the test component storage unit 202 respectively.

For example, the system under test 114 may be software, like an application program, describing the structure and behavior of the objects in an application system using an object oriented languages like C++ or JAVA language and running on a personal computer with graphical user interfaces. Another example of the system under test 114 is a client- server program running on one or more computers connected by a network or a communication channel. A further example of the system under test 114 is a control program running on a microprocessor of a mobile device such as a mobile phone or a tablet computer. The apparatuses, systems and methods for practicing the present invention function equally well with any type of the system under test 114, and the illustrative embodiments herein are not intended to limit the claimed invention in any way.

The test component 116, shown in Fig. 3, defines test sequences and operating conditions of a test and may comprises of one or more software modules that is capable of interacting with the system under test 114 by initializing the condition in which the system under test 114 operates, defining the sequences of operations to be performed to verify proper behavior of the system under test 114, and/or providing input to the system under test 114 . For example, to verify a proper behavior of a scenario withdrawing money from a bank account using an ATM (Automatic Telling Machine), the test components 116 may comprise of a software module that setups the account to be withdrawn, ΡΓΝ code and card database for authentication, the sequences of withdrawal operations to be performed by the banking system, and the input of the withdrawal to the ATM.

The test components 116 may be created manually, by entering the program code into a text editor capable of editing source code, or generated automatically in part from prototype and then modified as desired with a text editor. For example, the test components 116 may be modified in order to setup multiple operating conditions for the system under test 114 so that the operating conditions may vary from scenario to scenario.

The design models 120 may be described with modeling languages which are capable of expressing the structural aspects and/or behavioral aspects of the system under test 114. The design models 120 may describe the structural aspects and behavioral aspects of the objects in the system under test 114. For examples, the design models 120 may include UML (Unified Modeling Language) class diagrams, object diagrams, state transition diagrams, sequence diagrams, and use case diagrams. Alternatively, the design models 120 may be described by JML (Java Modeling Language), or any other type of modeling languages.

An example of the design model of "Account" class of the objects in a banking application is depicted by the UML class diagram in Fig. 9. As shown in the Fig. 9, the name of the class is "Account". In the second part, the attributes (aka. member variables) of the class are listed in separate lines, where each line shows a pair of an attribute name and an attribute type. In the third part, the methods of the class are listed in separate lines, where each line shows a pair of a method name with a parameter list in parentheses and a type of a return value.

The test control and execution module 110 provides interface between test components 116 and system under test 114 and perform the tests as defined by test components 116. In a preferred embodiment, the test control and execution module 110 logically includes a test control 122 and a test execution 124 as shown in Fig. 2. The test control 122 may ^" provide the control for testing operations such as the creation of objects defined in test components 116, the start and termination of a test. The test execution 124 may be realized by at least an interpreter or virtual machine which actually executes program code to realize test behavior specified by the test components 116. The test execution 124 should be capable of dynamic class loading and dynamic object binding in order to support dynamic updates due to the changes in metadata described later.

The design model input module 102 may be an interface capable of receiving input which describe the design models 120 of the system under test 114 and providing output data to be stored in the design model storage unit 200. In a preferred embodiment, the design model input module 102 is a computer terminal with a keyboard, a pointing device, a display, and a graphical user interface which can be used to input or edit the design models 120.

The test result reporting module 112 may be a physical display terminal or an interface capable of providing visual and/or audio output, and/or data output to a storage device or memory. In a preferred embodiment, the test reporting module 112 is a computer terminal with graphical user interface connected to the test control and execution module 110 or may communicate with the test control and execution module 110 via a network or any communication medium.

The metadata storage unit 203 stores metadata as shown in Fig. 4. The metadata is a set of data which provides the specification about the structure of the objects in the system under test 114. The structure of the objects includes the class name of the object, the name and type of the attributes of the class, the name and return type of the methods of the class, and the name and type of the arguments of the methods of the class. For example, a record of metadata written in XML shown in Fig. 4 provides the specification of a class with attributes and methods of the class specified by the design model in Fig. 9. The above description, example, and elements in Fig. 4 and Fig. 9 are merely illustrative and not intended to limit the claimed invention in anyway.

The metadata manipulation module 106, shown in Fig.l and further details shown in Fig. 5, is a module capable of (a) creating the metadata 126 of each object in the design from the design models 120; (b) creating the metadata 128 from each object of the system under test 114; (c) creating the metadata 130 from each object of the test components 116. Hereafter the design models 120, system under test 114 and the test components 116 each is referred to a system entity. The metadata manipulation module 106 is further capable of (d) detecting the modification made to at least one of the system entities, which is referred as the first system entity hereafter; (e) updating the metadata of the first system entity, according to the modification; (f) maintaining consistency among the metadata 126 of in the design models 120, the metadata 128 of the corresponding objects in the system under test 114, and the metadata 130 of the corresponding objects in the test components 116 by applying the updates made to the metadata of the first system entity to the metadata of the other two system entities which are the second and third system entity; and (g) reflecting the changes made to the metadata of the second and third system entities to the second and third system entities respectively.

For example, in the process (d) above, the metadata manipulation module 106 detects the modification to the design models 120; in (e), updates the metadata 126 according to the modification; in (f) changes the metadata 128 and 130 to maintain the consistency among metadata 126, 128, 130; and in (g), reflects the changes made to metadata 128 to the system under test 114, and the changes made to metadata 130 to the test components 116.

In the process (a), (b), and (c), the metadata manipulation module 106 may use grammatical rules of the language in which the system entity is written to extract metadata from the system entity. For example, the metadata manipulation module 106 uses the grammatical rules of the C++ language to extract attribute name and type from the system under test 114 and the test components 116 when they are written in C++ language.

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

In the process (e), the metadata manipulation module 106 may receive the data of the modification made to the first system entity from the text editor program. Then, it may use grammatical rules of the language in which the first system entity is written to determine where and how the modification must be made to the metadata of the first system entity. For example, when the first system entity is the design model 120 written in UML, the metadata manipulation module 106 detects the type of an attribute is changed in the design model 120 using the rules of UML syntax and semantics to changes the type of attribute in metadata 126.

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

In the process (g), the metadata manipulation module 106 refers the updated version of metadata of the second system entity, detects discrepancies between the metadata and the second system entity using grammatical rules of the language in which the second system entity is written, and modify the second system entity according to the metadata. For example, when the second system entity is the SUT 114 written in C++ language, the metadata manipulation module 106 detects discrepancy between the type of an attribute in metadata 128 and the definition of the variable corresponding to the attribute in the program code of the SUT 114 using the grammatical rules of the C++ language and changes the type of the variable in the definition in the SUT 114 according to the metadata 128: The metadata manipulation module 106 processes the third system entity similarly.

The inconsistency among them may be caused by the modification to the design models 120, and/or modification of the program code of the system under test 114 or program code of the test components 116.

For example, the metadata in Fig.4 illustrates metadata 126 of the class Account in the design model 120. Given an implementation as program code of the class Account in the system under test 114, the metadata manipulation module 106 maintains the dependency relation from the metadata 128 of the implementation of class Account to the metadata 126 of the design model 120 of class Account/ That is, each implemented method of class Account in the system under test 114 has a relation to the corresponding entity of method's metadata 126 of the class' design model 120. Also, given an instance object of Account, called "bob Account", in the test components 116, the metadata manipulation module 106 maintains dependency relation from the instance object "bobAccount" to the metadata 126 of the design model 120 of the class Account.

The changes which the metadata manipulation module 106 detects include any changes that happen in the design models 120 according to the change in design, the system under test 114 according to the modification of program code of the system under test 114, and the test components 116 according to the modification of program code of the test components 116.

The metadata manipulation module 106 may poll for the changes of the design models 120, the test components 116 and the system under test 114. In addition, for any changes made to the system under test 114 and/or the test components 116, the metadata manipulation module 106 may notify the test control and executable module 110,. so that the module 110 can update the runtime objects and re-execute the tests.

To summarize the operation of the testing system 100, a user creates design models 120 using the design model input module 102. The user then implements the system under test 114 and creates test components 116 as designed. The metadata manipulation module 106 then generates the metadata 126, 128, 130 from the design models 120, test components 116, and system under test 114. When each of the above preparation has been completed, not necessarily in the above order, the testing system 100 is ready to test the system under test 114. -

In the first test, the test control and execution module 110 reads the test components 116, and execute the tests, as specified by the test components 116. The test components 116 execute the steps by interacting with the system under test 114, for example, calling APIs that the system under test 114 provides. The test result of each behavior script is recorded for reporting by the result reporting module 112.

Fig. 7 is a flowchart describing operations of an automated test process of the present invention. Those who skilled in the art will recognize that a test process may be performed requiring manual intervention for handling changes, stopping and starting the tests or may be performed in a totally automated process in accordance with the present invention. In addition, the present invention allows a hybrid approach incorporating both manual processes and fully automated processes to handle changes that happen in the design models 120. In essence, the present invention defines the relation of design models 120 and metadata 126, dependency relation of metadata 128 and objects in the implementation of system under test 114, and dependency relation of metadata 130 and objects in the implementation of test components 116, and utilizes metadata 126, 128, and 130 as a mean for reflecting changes. Those skilled in the art will recognize that the present invention pertains to provision of the automated testing processes as well as the automated processes combined with known manual procedures where fully automated processes are not available.

The changes to the design model 120 that the testing system 100 can handle include the changes in name and return type of a method, the changes of data name and type of arguments in methods' signatures, the changes in name and type of the class attributes, the change in name of a class, adding a new method, adding a new attribute, and removing an existing attribute and method. The changes to the SUT 114 and test components 116 that testing system 100 can handle include the structural changes in the program code such as those described above.

The automated test process starts at Operation 200 where design models 120 are created. This can be done by the design model input module 102 Operation 204 implements the system under test 114 as designed and then operation 206 creates the test components 116 for testing the system behavior.

Then in operation 208 metadata 126 of the design models 120, the system under test 114, and test components 116 is generated by metadata manipulation module 106. The generation of metadata 126, 128 and 130 may be realized by a transformer, a software component that functions like a compiler which is able to transforms between the representation of a source to the XML description of metadata 126, 128 and 130 and vice versa. The representation of the source may be (a) the input format of the design models 120; (b) the program source code of the SUT 114; or (c) the program source code of the test components 116. We may have a transformer for each of these three representations to transform between (a) design models 120 to the metadata of the design models 126; (b) SUT 114 to the metadata of the SUT 128; and (c) test components 116 to the metadata of the test components 130.

Next, automated testing is initiated in operation 210 where the test control and execution module 110 determines if there exists any untested test component 116. If so, operation 212 reads an untested test component 116 for testing, and operation 214 executes the test for the test component 116. Operation 216 next records the test results. Testing process then continues by looping back to operation 210 to check if there is any untested test component 116 exists. Testing process finishes when all test components 116 are tested, and operation 218 produces the report of the test results. Fig. 8 depicts a process flow of the metadata manipulation module 106 where some changes are made to a source. The term source here may refer to the design models 120 or the SUT 114 or the test components 116 (cf.Fig.5). In the beginning before changes happen, the metadata of the design models 126, the metadata of the SUT 130 and the metadata of the test components 128 are in the same or equivalent state where they describe the identical structure of the objects.

Operation 300 detects change in the source. This can be realized by binding an observer, a software component that observes and automatically notifies of any state changes, to each of the sources. The observers are to notify metadata manipulation module 106 of any state changes happen to the sources and also providing the content of changes before ( β ) and after ( a ). The content of changes β and a will be used by subsequent operations in modifying metadata. Once change is detected, operation 302 instructs the test control and execution module 110 to pause its execution by commanding the executing virtual machines to pause.

Then, operation 304 modifies the metadata of the source according to the changes. Let us denote the XML description of the source's metadata by S, cf. the XML description in Fig.4 (a). Operation 304 can be realized by transforming the content of changes β and a to XML description of metadata by the corresponding transformer that generates such metadata as described in the operation 208. The transformations:

β => m( # ),

a => m( a ).

where m( β ) and m( (X ) are XML descriptions of the metadata of β and Oi respectively, then replacing the part in S that corresponds to m( β ) by m( a ).

For example, let us illustrate a case that change is made to design models 120 (the source). The data type of argument "amount" of method "credit" is changed from Integer to String, as a result of a modification in the specification. Operation 304 updates the metadata of the design models 126. This can be done by the metadata manipulation module 106 replacing the corresponding XML description of metadata from <arg type="Integer" name-"amount"> to <arg type="String" name="amoun '> as shown in Fig.4 (b).

Operation 306 modifies the metadata of the other two system entities that are not the source. In the same manner, the metadata manipulation module 106 replaces the part in S that corresponds to m( jS ^' ) by ( ). Let us continue from the previous example, the metadata manipulation module 106 modifies the metadata of SUT 128 and the metadata of test component 130 by replacing the corresponding XML description of metadata from <arg type- 'Integer" name="amount"> to <arg type="String" name="amount"> .

Operation 308 reflects the change of metadata to the two system entities other than the source. This operation can be realized by the corresponding transformer as described in operation 208. From the previous example, the transformer of the SUT 114 transforms the new class Account from the changed metadata 128 and the transformer of the test components 116 transform the new objects that are instantiated from the new class Account in the changed metadata 130.

Once the changes are reflected, operation 310 instructs the test control and execution module 110 to update runtime objects by commanding the virtual machines that have been paused from the execution in operation 302 to reload the updated runtime objects and restart the execution of the test.

With an embodiment of the present invention that comprises of the metadata manipulation module 106, changes in the design models 120 can be reflected to the implementation of the system under test 114 and the test components 116 via the transition of metadata 126, 128 and 130. Similarly changes in the implementation of the system under test 114 can be reflected to the design models 120 and the test components 116 via the transition of metadata 126, 128 and 130. This can cut down the cost and effort for maintaining consistency among the design, the implementation and the test components. With an embodiment of the present invention that comprises of the test control and execution module 106, the modification in the system under test 114 or the test components 116 can become effective in the tests by dynamic rebinding without manual interruption. This can reduce the time and minimize the attention needed for controlling the testing process.

In a modified embodiment of the invention, only one of the metadata may exist in the modification management apparatus 200. In this embodiment, the metadata manipulation module 106 may perform only one process among (a), (b) and (c) and it does not have to perform the process (f).

In another modified embodiment of the invention, only two of the system entities exist in the modification management apparatus 300. For example, only the design models 120 and system under test 114 may exist in the modification management apparatus 300.

<Second Exemplary Embodiment >

Referring to Fig. 9, a simplified block diagram of a modification management apparatus 300 in the second exemplary embodiment is depicted. The modification management apparatus 300 comprises a design model storage unit 200, a program storage unit 201 , a metadata storage unit 203 and a metadata manipulation unit 106. The design model storage unit 200 stores a design model 120 which describes structure of objects in a modeling language. The program storage unit 201 stores an system under test, which is an application program describing the objects in a programming language. The metadata storage unit 203 stores a metadata which describes the structure of the objects.

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

The cost and effort for maintaining consistency among design and implementation are reduced. This is because that with the metadata manipulation module 106, the changes in the design models 120 can be reflected to the implementation of the system under test 114 via the transition of metadata and vice versa.

INDUSTRIAL APPLICABILITY

The invention can be used for automating the testing of computer software, especially but not limited to agile software development. The invention can be used for checking the consistency between the functional specification and the test specification of the system under test.

REFERENCE SIGNS LIST

100 Testing system

102 Design model input module

106 Metadata manipulation module

110 Test control and execution module

112 Test results reporting module

11 System under test

116 Test component

120 Design model

122 Test control

124 Test execution

126 Metadata of design model

128 Metadata of test component

130 Metadata of system under test

200 Design model storage unit

201 Program storage unit 202 Test component storage unit

203 Metadata storage unit .

300 Modification management apparatus