JP2003330716A - Reuse support system of object-oriented application - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To manage, for easy reuse, a source code of an existing application developed using an object orientation. <P>SOLUTION: This reuse support system is provided with a classifying means for extracting classes constituting source codes of an inputted existing class, classifying them into an interface class and a mounting class every role of each class for the other class and extracting them, and producing a first corresponding table indicating a corresponding relation between a class name and the method of an extracting origin and the interface class of an extracting destination. The support system also comprises a class name converting means for converting the class names of the class of the extracting origin and the mounting class to the extracted interface class name, and producing a second corresponding table indicating a relation of the mounting class to a required interface class. The support system also comprises a library managing means for classifying the interface class by category and registering and managing it together with a plurality of corresponding mounting classes in a library. <P>COPYRIGHT: (C)2004,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an application reuse support system developed using object orientation.

[0002]

2. Description of the Related Art Application development using object-orientation refers to the structural design of an application that is closer to the real world by dividing the development target not by the functional unit but by the unit of the object (target) that exists there. It is a technology that enables it. The conventional method of developing an object-oriented application employs a development method in which the static type of an object is called a class and is created to generate the source code of the application. Attributes (variables), methods (operations), and interfaces are implemented in the class. An attribute is a variable that indicates another object that can be recognized by an object created from a class, and a method is a function that describes the behavior that an object created from a class can take. An interface is an abstract class that has a role of mediating access to other objects, and the contents of the interface are described as a set of method types.

When designing the source code of an application, the structure between objects is analyzed and classes are designed as interchangeable constituent elements. Also,
By taking the means of inheritance, a class can inherit the attributes and methods of the inheriting class.
Among the application architectures created in this way, reusable ones are called frameworks, and component-level objects are called components. As a component, not only a single class but also a plurality of classes that are combined to perform cooperative operation.

In general, the application development method using the object-oriented technology is characterized by creating a class using an existing library and creating a source code of a portion lacking the function. There is an advantage that the amount of work is reduced because the place to implement the source code is only the newly created part and the lacking part. To create the source code, use an editor such as Notepad of Windows (registered trademark of Microsoft Corporation in the United States), Mi in the United States.
Integrated application development environment equipment such as Microsoft Visual Studio, Rational Rational, etc.
There are reverse engineering devices such as Rose.
The source code created using these devices can be saved once and then reused in class units. The stored source code is managed in folders (directories), packages, or development projects.

[0005]

However, in the above-mentioned method of the prior art, when the source code having weak independence is reused, it is necessary to repeatedly modify the mounted code. Therefore, if the source code of the application to be developed includes low-independence classes, the code configuration becomes useless, and maintenance becomes difficult if reused multiple times. Therefore, it is necessary to reassemble the completed source code so that it can be easily reused later, but the work is not taken into consideration in the above conventional technology. Also, a large amount of source code is saved as a reusable library, but in the reuse development work, the source code necessary to realize an arbitrary function from this large amount of reusable source code. We need a way to select all. However, this function is not taken into consideration in the above-mentioned conventional technique.

An object of the present invention is to provide an object-oriented application reuse support system capable of managing the source code of an existing application developed using object-oriented so as to be easily reused.

[0007]

In order to achieve the above object, the present invention extracts a class which constitutes a source code of an input existing class, and implements an interface class and an implementation for each role with respect to other classes of each class. A class decomposing means for decomposing and extracting into a class and creating a first correspondence table showing a correspondence relationship between the extraction source class name and method and the extraction destination interface class, and based on the first correspondence table, Class name conversion means for converting the class names of the extraction source class and the implementation class into the extracted interface class name, and creating a second correspondence table showing the relationship with the interface class name required by the implementation class. , The interface class is divided into categories and registered with the library along with the corresponding multiple implementation classes for management. Characterized by comprising a re-management unit. Also, based on the input information of the function required for the new application, a class editing means for creating a third correspondence table showing a class name and an interface class name required to realize the function, and the third correspondence. The present invention is characterized by further comprising: an application generating unit that acquires the interface name and the implementation class corresponding to the class name and the interface class name shown in the table from the library managing unit and generates the source code of the new application.

[0008]

BEST MODE FOR CARRYING OUT THE INVENTION An embodiment of the present invention will be described in detail below with reference to the drawings. FIG. 1 is a functional block diagram showing an embodiment of an object-oriented application reuse support system according to the present invention. The system of the present embodiment extracts, from the source code of the class that constitutes the existing application, the part in which the information of the inherited class and the information of the package to be imported is described as basic information, and the attribute and the method part of the acquisition and setting thereof. Is extracted as property information, the remaining code part is divided by deciding the role from the relation with other classes, each role interface class (role IF class: hereinafter abbreviated as role interface) is created, and that is defined as role interface information. Then, the part in which other classes are described is replaced with the role interface class name to make it a class and extracted as an implementation class. Also, the implementation class corresponding to the interface class is managed in the correspondence table, and the interface class of another class required by the class is held in the correspondence table. Then, when the new application is given the required functions, by selecting the required role interface class and implementation class, selecting the required basic information and property information from the objects required for the application, and combining the selected information. , Generate the application source code.

The reuse support system in the embodiment of FIG. 1 comprises a class decomposition device 101 and a class name conversion device 10.
2, library management device 103, application construction class editing device 104, application construction device 10
It is composed of 5. In the conventional object-oriented development, the source code of the application is designed by implementing the class 106, whereas in the present embodiment,
The class 106 is mounted as a combination of a plurality of role IF information 103 and a plurality of mounting class information 108. Therefore, when the source code of the class 106 is changed, the role IF information 107 is replaced and the mounting class information 108 is replaced, so that the modification can be flexibly made. Also,
Disassemble the source code of the existing class, role IF information 1
07 and the implementation class information 108 are extracted and managed, and by combining the extracted information, the source code 114 of the class of the new application can be developed.

The class decomposing device 101 converts the source code of the class 102 from the role of the class to other classes.
Plural role IF information 107 and its implementation class information 108
Divide into and extract. Further, the role IF information 107 in which the method or attribute of the original class is extracted is held in the class name-method name-destination role IF name correspondence table 109. As shown in FIG. 2A, the role IF information 107 holds a role IF name 1071 and a method name 1072 for each method. As shown in FIG. 2B, the mounting class information 108 includes a type code 108 indicating whether the attribute and the method are the attribute or the method.
1, the attribute name / method name 1082, and the source code 1083 which is the contents of the method are held.

The class name conversion device 102, based on the class name-method name-destination role IF name correspondence table 109,
It has a function of converting the class name in the data of the extracted role IF information 107 and the implementation class information 108 into the decomposed role IF information name. Furthermore, the implementation class information 108
Has a function of extracting role IF information required in the source code into the implementation class name-necessary role IF name correspondence table 112.

The library management apparatus 103 has the converted role IF information 110 and the converted mounting class information 111.
And a function for holding the implementation class name-required role IF name correspondence table 112 as a library. The post-conversion implementation class information 111 corresponds to the post-conversion role IF information 110 by the categorization function of the library management device 110.
Is tied to.

Application construction class editing device 10
Reference numeral 4 denotes a new class name which has a function as a user interface of the library management apparatus 103 and describes a combination of a class name to be created and a role IF name implemented by the function necessary for a newly developed application. The role IF name correspondence table 113 is created. The application construction device 105 has a function of reading the new class name-role IF name correspondence table 113, reading the corresponding information from the library management device 103, and generating a class source code.

FIG. 3 is a flow chart showing the outline of the processing. First, the class decomposition device 101 receives the source code of an existing application (step 30).
1), it is decomposed into class units and read (step 302). And for all classes (step 3
03 to step 305), the class decomposition apparatus 101 divides and extracts the role IF information 107 and the implementation class information 108, and creates a class name-method name-destination role IF name correspondence table 109 (step 304). After that, the class name conversion device 102 changes the class names of the role IF information 107 and the implementation class information 108 into the converted role IF information name and the converted implementation class name, and changes the converted role IF information 110 and the converted implementation class 111. Created and changed role I
An implementation class name-necessary role IF name correspondence table 112 showing a correspondence relationship between the F information 110 and the changed implementation class information 111 is created, and these are set as a set, and the library management apparatus 103 is set.
(Steps 306 and 307).

Application construction class editing device 10
4 is a new class name describing a combination of a class name corresponding to the function and a role IF name implemented by the function when the function information of the new application is input by the user-
The role IF name correspondence table 113 is created. The application construction device 105 uses the new class name-role IF name correspondence table 11 created by the application construction class editing device 104.
3 is read, the corresponding converted implementation class information 111 and the converted role IF information 110 are acquired, and the source code of the class that constitutes the new application is generated (step 308).

Description will be made with reference to specific examples shown in FIGS. Here, an example of inputting the source codes of two existing applications is shown. One is an application including a skill class 401 and an engineer class 402 as shown in FIG. 4A, and the other is an application including a member class 411 and a group class 412 as shown in FIG. 4B.
And an application including a file class 413. According to the processing procedure shown in FIG.
By 1, the skill class 401 is decomposed and extracted into the skill class engineer role IF information 403 and the skill class engineer mounting class 404. Other Technician Class 4
02 also has a role IF405 for engineer class skills.
And is decomposed and extracted into an implementation class 406 for engineer class skills. This extracted one corresponds to the role interface information 107 and the mounting class information 108 in FIG.

On the other hand, in the existing application shown in FIG. 4B, the member class 411 is decomposed and extracted into the member class group role IF 414 and the member class group mounting class 415. The group class 412 is the member class 411 and the file class 41.
Since it has a relationship with two classes of No. 3, two role IF information (role IF416 for group class members, implementation class 417 for group class members), two implementation class information (role IF41 for group class files)
8. The implementation class 419) for the group class file is extracted. Since the file class 413 is not actually used by other classes, nothing is extracted. Then, a class name-method name-destination role IF name correspondence table 511 as shown in FIG. 5A is created. Further, as a result of the processing of the class name changing device 102, the class name in the source of the extraction information replaces the role IF information, and the implementation class name-necessary role IF name correspondence table 512 as shown in FIG. 5B.
Is created.

In this way, the library management device 103
The application construction device 105 generates the source code of the application using the data registered in. As an example, assuming that a new engineer member class is created, the engineer class skill role IF and the member class group role IF are implemented in the engineer member class. The application construction class editing device 104 receives it and creates a new class name-role IF name correspondence table 513 as shown in FIG. 5C.

When the mounting class information to be mounted is decided, the necessary role IF information is decided, and by repeating this, the correspondence table 513 for generating the source code of the new application is completed. By using this correspondence table 513, the application construction device 105 generates the source code of all the classes required for the new application.

Detailed processing of the class decomposition device 101 (see FIG. 3).
Step 304) will be described with reference to the flowchart of FIG. In steps 601 to 608, all attributes and methods in one class are identified.
First, a method is extracted from the source code of the class (step 601). Next, other classes and attributes included in the method are analyzed (step 602). Then, it is judged whether or not the analyzed combination of other classes is already created in the method name-destination IF name correspondence table 109 (step 603). If not, a new role IF name is added to the combination. Then, the role IF information is registered (step 604). If you have already registered, do not name it. Next, the method is added to the role IF information 107 of the corresponding class combination (step 605), and further added to the implementation class information 108 of the corresponding class combination (step 606), and the method name-destination IF name correspondence It is added to the table 109 (step 607).

Detailed processing (step 306 in FIG. 3) of the class name conversion device 102 will be described with reference to the flowchart in FIG. For all implementation class information 108 (from step 701 to step 706), all methods are identified (from step 702 to step 705), and the class and method in the process of the identified method are associated with the role interface name and method. It is converted into a name (step 703). The name of the required role IF information found is added to the implementation class-necessary role IF name correspondence table 112 (step 704). Next, the role IF
Regarding the information 107 as well, for all the information (from step 707 to step 711), it is identified by the method unit (from step 708 to step 710), and the class and method in the process of the identified method are assigned the role interface name corresponding to them. Convert to a method name (step 709).

Detailed processing of the library management apparatus 103 (step 307 in FIG. 3) will be described with reference to the flowchart in FIG. The following processing is repeated one by one until there is no extracted information in steps 801 to 809. First, the name and source of the post-conversion role IF information 110 and the post-conversion implementation class information 111 are searched for information that is considered to be most relevant (step 802). If the library management device 103 contains information whose source and name are exactly the same (step 803, step 807), nothing is done. If there is data in which the information sources match and the names are different (step 803, step 607), the name of the extracted information is changed to a name already existing in the library management device 103, and the implementation class name-necessary role IF name correspondence table 112
(Step 808). Library management device 1
03 has the same name, but the contents of the source are different (step 803, step 804), the name of the extracted information is changed so that it does not overlap with other information (step 8).
06), and it is reflected in the implementation class name-required role IF name correspondence table 112 (step 605). If there is no matching name or source (step 803, step 80)
4) Then, it is directly registered in the library management apparatus 103 (step 805). This process is repeated for all the extracted information (from step 801 to step 809), and finally the implementation class name-required role IF name correspondence table 11
2 is additionally registered in the library management device 103.

Detailed processing of the application construction device 105 (step 308 in FIG. 3) will be described with reference to the flowchart in FIG. First, the application construction class editing device 104 creates a new class name-role IF name correspondence table 113, and associates the new class to be developed with the role IF information and the mounting class information in the library management device 103 (step 701). ). After that, when the new class name-role IF name correspondence table 113 is input to the application construction device 105 (step 902), all the classes in the correspondence table 113 are mounted (steps 903 to 908). To implement, first create the source code of the class with the new class name (step 904), read the converted role IF information 110 according to the correspondence table 113, and implement it in the new class (step 90).
5). Next, the converted implementation class information 111 is read, a class is created, and delegation is implemented in the new class (step 906). After that, new class name-role IF name correspondence table 11
According to 3, the role IF name in the source code of the implementation class is linked to the corresponding new class (step 907). When all the classes have been implemented, the source code is output to the output destination (step 909).

FIG. 10 is a class diagram showing a model example of an existing application to which the present invention is applied. Of the classes described in this class diagram, a member class 1001, a customer class 1002, and a reservation class 1 related to book reservations.
Focusing on 003, the book class 1004, and the inventory class 1005, the results of the processing steps of class decomposition, class name change, library management, and new application construction will be described. FIG. 11 shows a member class 1001, a customer class 1002, and a book class 100 related to book reservation.
FIG. 12 is a class diagram describing only 3, a book class 1004, and an inventory class 1005. When the source code of the existing application including the class of this class diagram is input to the class decomposing device 101, the class of FIG.
As shown in, the implementation class 120 of the "book reservation" customer
1. "Book reservation" customer interface class 120
2, decomposed and extracted into a "book reservation" reservation implementation class 1203, a "book reservation" reservation interface class 1204, a "book reservation" book implementation class 1205, and a "book reservation" book interface class 1206. Also, the member class 1001 is "member management" because of the relationship with the group class 1000 as shown in FIG.
It is decomposed and extracted into a group implementation class 1301, a “member management” group interface class 1302, a “member management” member 1303 implementation class 1303, and a “member management” member interface class 1304. The class decomposing device 101, when decomposing a class,
Which role interface class the method of the class was extracted from is recorded in the class name-method name-destination role IF name correspondence table 511.

When the extracted classes shown in FIGS. 12 and 13 are input to the class name changing device 102, using the class name-method name-destination role IF name correspondence table 511,
The related class name of each implementation class is converted into the extracted interface class name. As a result, as shown in FIG. 14, the class before the association destination of each interface class and each implementation class is decomposed is changed to the extracted interface class.

The library management device 103 extracts the extracted interface classes shown in FIG. 14 as a library, classifies them into categories, and manages them. The extracted role interface class 110 is managed by being classified into categories from similar method structures. The extracted implementation class 111 is managed by being classified into categories from the corresponding role interface class.

When extracting the library, the library management device 103, as shown in FIG.
An implementation class name-required role IF correspondence table 112 as shown in FIGS. 16 and 17 is created so that necessary libraries can be collectively fetched for each business unit such as “member management”.

When developing a new application,
The application construction class editing device 104 is used.
The application construction class editing device 104 is shown in FIG.
As shown in, when a job is entered, the library is searched and a list of required role interface classes is read and displayed. By selecting the implementation class corresponding to the role interface class, the new class name-role interface name correspondence table 113 of the new application is created.

When the new class name-role interface name correspondence table 113 of a new application as shown in FIG. 18 is input to the application construction apparatus 105, the library prepared in this way is used as shown in FIG. Source code corresponding to the class diagram of the new application model is generated.

[0030]

As is apparent from the above description, according to the present invention, it is possible to manage the source code of an existing application developed using object-oriented so that it can be easily reused. Further, it becomes possible to easily create a source code of a new application using the managed source code.

[Brief description of drawings]

FIG. 1 is a functional configuration diagram showing an embodiment of an object-oriented application reuse support system according to the present invention.

FIG. 2 is a configuration diagram of role IF information and implementation class information decomposed by a class decomposition device.

FIG. 3 is a flowchart showing an outline of processing in the embodiment of FIG.

FIG. 4 is a diagram showing an example of a class of an existing application and examples of role IF information and implementation class information decomposed and extracted according to the role of each class.

FIG. 5 is a diagram showing configurations of a class name-method name-destination role IF name correspondence table, an implementation class name-necessary role IF name correspondence table, and a new class name-role IF name correspondence table.

FIG. 6 is a flowchart showing a process of a class decomposition device.

FIG. 7 is a flowchart showing processing of a class name conversion device.

FIG. 8 is a flowchart showing processing of the library management device.

FIG. 9 is a flowchart showing a process of an application building device.

FIG. 10 is a class diagram showing a model example of an existing application to which the present invention is applied.

FIG. 11 is a class diagram showing only classes related to book reservation in FIG.

FIG. 12 is a class diagram showing a result of decomposing a class related to book reservation with a class decomposing device.

FIG. 13 is a class diagram showing a result of disassembling a member class related to book reservation into a class disassembling device.

FIG. 14 is a class diagram showing a result of renaming decomposed classes.

FIG. 15 is a diagram showing an example of a role interface and a mounting class which constitute a library extracted by the library management device.

FIG. 16 is a diagram showing an example (part 1) of an implementation class name-necessary role IF correspondence table created by the library management device.

FIG. 17 is a diagram showing an example (part 2) of a mounting class name-necessary role IF correspondence table created by the library management device.

FIG. 18 is a class diagram showing an example of a new application model.

FIG. 19 is a class diagram of source code corresponding to a new application model generated based on a library.

[Explanation of symbols]

101 ... Class decomposing device, 102 ... Class name changing device,
103 ... Library management device, 104 ... Application construction class editing device, 105 ... Application construction device, 106 ... Existing application class, 107
... Role IF information, 108 ... Implementation class information, 109 ... Class name-method name-destination role IF name correspondence table, 110
... post-conversion role IF information, 111 ... post-conversion implementation class information, 112 ... implementation class-necessary role IF name correspondence table, 11
3 ... New class-role IF correspondence table, 114 ... New class.

   ─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor Hiroshi Suganuma             6-81 Onoe-cho, Naka-ku, Yokohama-shi, Kanagawa             Hitachi Software Engineering Stock Association             In-house (72) Inventor Akihiro Hosomi             6-81 Onoe-cho, Naka-ku, Yokohama-shi, Kanagawa             Hitachi Software Engineering Stock Association             In-house (72) Inventor Norikazu Kijima             6-81 Onoe-cho, Naka-ku, Yokohama-shi, Kanagawa             Hitachi Software Engineering Stock Association             In-house (72) Inventor Tsutomu Masamura             6-81 Onoe-cho, Naka-ku, Yokohama-shi, Kanagawa             Hitachi Software Engineering Stock Association             In-house F term (reference) 5B076 DD05 DD07 DF06 EC07

Claims (2)

[Claims] 1. An application reuse support system using object-oriented technology, wherein a class that constitutes a source code of an input existing class is extracted, and an interface class and an implementation are implemented for each role with respect to other classes of each class. A class decomposing means for decomposing and extracting into a class and creating a first correspondence table showing a correspondence relationship between a class name and method of an extraction source and an interface class of an extraction destination, based on the first correspondence table, Class name conversion means for converting the class names of the extraction source class and the implementation class into the extracted interface class name, and creating a second correspondence table showing the relationship with the interface class name required by the implementation class. , The interface class is divided into categories, and a library with corresponding multiple implementation classes An object-oriented application reuse support system comprising: a library management unit that registers and manages the object. 2. A class editing means for creating a third correspondence table showing a class name and an interface class name required to realize the function based on input information of the function necessary for the new application, And an application generation unit that acquires the interface class and the implementation class corresponding to the class name and the interface class name shown in the correspondence table of No. 3 from the library management unit and generates the source code of the new application. Claim 1 characterized by
An object-oriented application reuse support system described in.