JPH09185542A - Object management method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To execute an operation on retrieval, addition and deletion for the relation by collectively managing objects and the relation of the objects through the use of an adjacent list. SOLUTION: When the objects stored in a file and related information between the objects are restored in a memory again, the object becoming a starting point is restored on the memory at first by using the adjacent list storing relation information on the objects and the related objects are restored on the memory while adjacent information which the start object has is analyzed. When the adjacent list of the related object is repeatedly analyzed and restored, the object related to the object of the starting point is restored on the memory.

Description

Detailed Description of the Invention

[0001]

FIELD OF THE INVENTION The present invention is applicable to all software developed by object-oriented techniques. In particular, by accumulating and providing a plurality of classes including the classes adopting the present invention as a library, the productivity of software is improved.

[0002]

Programs developed on the basis of object-oriented techniques implement the relationships between objects.
For example, in a financial business program, the business office object and the passbook object owned by the business office are 1
There is a many-to-many relationship. Furthermore, there is a one-to-many relationship between the customer object and the passbook object that the customer object has.

Since the number of related objects differs for each object, the relationship between objects is often managed by a list structure that can have variable information. There are various relationships such as the relationship between the business office and the passbook, and the relationship between the passbook and the customer, and each class has a list holding information of the related partner class as an attribute.

However, since the operation for the relation is similar to any list such as addition, deletion, and retrieval of the related object, similar processing is scattered in each class.

Further, when a sales office implements a reference operation such as acquiring customer information, the method of implementing each class implements a method in which the office object directly has the information of the customer object. Or it should be implemented in the passbook class for the method to get customer information. In the former method, for example, when a business such as a name change business that changes the relationship between objects occurs, the information on the customer object in the store object becomes information that always reflects the relationship between the passbook object and the customer object. You have to consider
In the latter implementation method, a business that refers to multiple associations requires a more complicated interface and processing. In this way, with the method in which each class determines the relationship with its own specifications, in order to add the implementation of the business that operates across multiple objects, the designer should always grasp the movement of objects other than the business to be added. This is a problem in terms of extensibility and maintainability.

In order to solve such a problem, a list for centrally managing the relation between objects under the same standard is prepared, and the processes scattered for each class are all summarized in the process for the list. There was a way.

According to the Nikkei Intelligent Systems separate volume "Object Oriented Database", there is an object oriented DB as a system for managing the relation between objects in a non-volatile memory. According to the Object Store manual, the Object Store, which is one of the object-oriented DBs, creates a memory map for managing objects in the Object Store based on the declaration information of the class of the application that uses the Object Store. The information of the value of the object in the volatile memory included in is stored in the non-volatile memory. When reading an object, the memory map of the non-volatile memory and the memory map in the volatile memory of the application are associated with each other to restore the relationship between the objects.

[0008]

In the conventional program, since the relation between objects is managed for each class, similar processing is implemented for each class.
Not only development man-hours were required, but maintenance man-hours were also required.

In the method of expressing the relation between objects in one relation table by using the link object, the processing for the relation table can be summarized in one place, but all relations between objects in the application are managed in one relation table. Therefore, there is a problem that the number of elements in the related table becomes huge and the search time and the deletion time are delayed.

Further, in the conventional method, it is necessary to describe a process of reading or storing an object from a file or a DB on a volatile memory for each application.

Further, since the relation between objects is determined at the time of compiling the program, it is necessary to define the relation between objects required under special conditions in the class header without fail. For example, a bank loan object must have an overdue object if the repayment date has passed. In the conventional method, there is always an association with the overdue object.

[0012]

A class having an adjacency list management list is provided. Such a class is called an object class. The object class has operations such as element addition / deletion / search for the adjacency list included in the adjacency list management list. The classes required for each application are developed by inheriting the object class. By registering the adjacency list between objects, which the inherited class requires, in the adjacency list management list, the object class can operate on the adjacency list. In this method, since the adjacent list management list is provided for each object, the related information between the managed objects can be limited to the information in one object, so that operations such as addition / deletion / search can be performed at high speed.

Further, according to the present invention, since the relationship between objects is established by registering the adjacency list in the adjacency list management list during object construction, it is not necessary to always provide the object with the necessary relationship under special conditions. .

[0014]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention applied to financial relations will be described in detail below.

FIG. 3 shows a hardware configuration diagram of the present invention, and 302 is a CPU for executing the program of the present invention, 3
Reference numeral 05 is an external storage device for storing the program of the present invention or a program to be analyzed, 301 is a main storage device for temporarily storing the program to be analyzed by the present invention, 303 is an input device for executing the program, and 304 is It is a device for displaying the execution result of the present invention.

FIG. 2 shows a class structure including financial classes and the present invention. The part corresponding to the present invention is a container management class 201, an object management class 202,
It is composed of an object class 203, a neighbor list management list class 204, and a neighbor list 205. In addition, financial-related classes are branch office class 206 and passbook class 2.
07 and customer class 208 inherit the object class.

As a class key for externally referencing an object, a sales office class is a store name, a passbook class is a customer number, and a customer class is a customer name. The class key is specified using the class key registration method.

The management method of each generated object of the financial relation class is such that a unique value is given to the object ID of the attribute of the object class for the generated object, and the entity of the generated object is added to the container of the dynamically created object management class. Store a pointer. The created container is managed by the container management list of the container management class. If you want to sort the containers to be stored, define the container name using the container name registration method.

In the method of managing the related information of an object, an adjacency list is created for each associated partner container, and either the reference pointer or the object ID of the associated partner object is set in the adjacency list. The adjacency list management list aggregates and manages one or more adjacency lists. The adjacency list name is defined using the adjacency list name registration method. If it is not defined, the adjacency list management list and adjacency list are not created. Since each of the class key registration method, container name registration method, and adjacency list name registration method is called during object construction, the registered contents can be changed on an object-by-object basis. You can also change the registered contents in units.

How to retain the relevant information of the three financial relation classes will be described with reference to FIGS. 2 and 4.

The sales office class 206 has a one-to-many relationship with the passbook class 207. The sales office object 406 has a shop name of Tokyo branch, an object ID of 01, belongs to a sales office container 413, and an adjacency list management list 41.
It has 0 and has a passbook adjacency list 401. The contents of the passbook adjacency list have object IDs 02 and 04 of passbook objects 407 and 409, respectively.

The passbook class 207 has only one association with the customer class 208. Passbook object 407
Has a customer number of 001, an object ID of 02, belongs to a passbook container 414, and has an adjacency list management list 411, a branch office adjacency list 402, and a customer adjacency list 403. The business office adjacency list has the object ID 01 of the business office object 406, and the customer adjacency list 403 has the object ID 03 of the customer object 408.

Another passbook object 409 has a customer number of 002, an object ID of 04, belongs to a passbook container 414, and has an adjacency list management list 41.
2, a store adjacency list 404 and a customer adjacency list 405
Having. The sales office adjacency list 404 has the object ID 01 of the sales office object 406, and the customer adjacency list 405 is the object ID of the customer object 408.
03. A customer class is a one-to-many association with multiple passbooks. The customer object 408 has a customer name Taro Yamada, an object ID 03, and a customer container 415.
Belong to. It does not have a neighbor list management list and a neighbor list.

The data structure as shown above supports all one-to-one, one-to-many, and many-to-many associations. By repeatedly applying this data structure to the relationship between each object and treating the relationship of the entire system uniformly,
It is possible to generalize and make common the object operation methods such as generation / addition / search / search / deletion for the associations that each class has implemented up to now.

An embodiment in which an object is manipulated using the present invention is shown in FIG. 5 showing the states of objects between a memory and a file.

The upper half (area M) of the dotted lines 501 to 507 shows the state of the object on the memory, and the lower half (area H) shows the state of the object on the file. The object diagram in 501 to 507 is based on FIG. 3, and only the object ID is shown.

When an object class generation method (step 508) is called to generate an object ID 01 from a state 501 in which no object has been generated, the object is generated and the state of 502 is entered. Next, when the additional method (step 509) is called to generate the object ID 02 in the state of 502, the object ID is generated, and the object ID is generated.
Associated with 01. The object IDs 03 and 04 also repeat the state of 503. Next, when the storage method (step 510) is called in the state of 503, the object IDs 01, 02, 03, 04 are stored in the file, and the objects in the memory are erased.
04. Next, in the state of 504, the object ID 01
When the search method (step 511) is selected by selecting as the starting point, the object IDs 01, 02, 0 are stored in the memory.
The objects of 3, 04 are expanded again to be in the state of 505. At this time, it is possible to expand only the objects required for reference updating by limiting the adjacency list expanded in the memory. As the information on the object expanded on the memory, the information before expansion is saved until the next storage method is called. Next, in the state of 505,
When the search method (step 512) is called to refer to the customer object related to the object ID 01, the state 506 in which the pointer of the object ID 03 is acquired is obtained. In the state of 506, when the delete method (step 513) is called for the object ID 03 acquired earlier, the state 5 in which the object ID 03 is deleted
07. The deleted object is reflected in the file when stored.

By providing the inherited class with the interface of the method for performing the above operation,
The inherited class does not need to implement the method related to the object operation, and has the effect that it can be implemented regardless of the file type.

FIG. 1 is a flowchart showing a search method as an example of object operation. The search method is a method for restoring an object chained from the object specified by the caller as a starting point on the memory, based on the object already stored in the file and the related information between the objects.

First, all the objects already developed in the memory are stored in the file, and the objects in the memory are erased (step 101). Next, the object serving as the starting point is restored (step 102). As for the order of restoration, the object is generated, the object data that matches the object is read from the file, and the object pointer is reset. The object data is composed of an object ID, a class name, a class key, an adjacency list, and attribute value data of the inherited class. Then, the analysis (range from step 104 to step 109) of the adjacency list (step 103) acquired from the starting point object is started. An adjacent object is acquired from the elements of the adjacent list (step 105), the acquired adjacent object is restored (step 107), and the restored object is added to the queue (step 1).
08). However, if the adjacent object has been restored (step 106), steps 107 and 108 are skipped. When the analysis of the neighbor list is completed (step 10
9) Confirm the queue status (step 110). If the queue is not empty, the adjacent object is acquired from the queue (step 111), the adjacent list of the acquired adjacent objects is acquired (step 112), and the analysis of the adjacent list is started again (return to step 104). When all the neighboring objects stored in the queue have been extracted and become empty, the search method ends.

According to this flow, objects linked to the origin object are stored in the respective containers on the memory. If the designation of the starting object changes,
Even in the container with the same name, the objects linked to the changed starting object are replaced and stored. The search method, which is one of the methods for operating an object, can acquire the object for the starting object by specifying the container name of the object to be acquired. Referring to FIG. 4, the starting point is a sales office object 406.
In the case of, the customer object becomes the customer object 408 stored in the customer container. By using this method, there is an advantage that the same method can be used as long as the partner to be acquired does not change even if the object relation between the object to be acquired and the origin object changes.

[0032]

According to the present invention, the implementation means for defining the relation between objects is designated by the method, so that the definition regarding the relation can be easily added or changed. Further, object operations such as addition, deletion, and search for associations can be realized simply by calling the method interface. Also, the search time is faster than the conventional method.

[Brief description of the drawings]

FIG. 1 is a flowchart showing an embodiment of the present invention.

FIG. 2 is a hardware configuration diagram of the present invention.

FIG. 3 is an object diagram realized by the present invention.

FIG. 4 is an image diagram of a data structure expressing the present invention based on an embodiment.

FIG. 5 is a diagram showing an embodiment of the present invention in comparison with a state of an object between a memory and a file.

[Explanation of symbols]

201 ... Container management list class, 202 ... Object management class, 203 ... Object class,
204 ... Neighbor list management list class, 205 ... Neighbor list class.

Claims (3)

[Claims] 1. In a system in which an object in an application system and information relating to the object are read from a file or a database, updated or referenced, and stored again in the file or the database during execution of the application system An adjacency list management list for managing a plurality of adjacency lists for managing associations and a class having the adjacency list management list are prepared, and a class required for each application is developed by inheriting the class, and for each inherited class By registering the adjacency list required for the adjacency list management list, search for the relationship between multiple objects,
An object management method characterized in that operations such as addition and deletion are performed in the class. 2. The class can be rearranged in object units by registering the adjacency list required for each inherited class in the adjacency list management list at the time of execution. Object management method. 3. The object management method according to claim 1, further comprising an operation capable of acquiring information on objects chained via a plurality of associations starting from an object.