JPH10301782A - Frame work mechanism - Google Patents

Abstract

PROBLEM TO BE SOLVED: To perform customization and extension in many forms by providing common object relation in context management for plural tools in an object- oriented programming environment. SOLUTION: Information relating to a model object 1 is defined by a character string 2 which is the name of the object and the plural different character strings such as the attribute of the object inclusively indicated by a code 3 or the like. The feature of the name 5 which is the character string is provided in the entire relation 4 of the model object 1. One set of references 6 to the other model object are provided in each relation 4 as well. A search context 7 and a lock context are provided and the lock context is provided with the three forms of a deletion lock 8, a rename lock 9 and a change lock 10. Within such an object-oriented programming environment, the common object relation in the context management for the plural tools is provided.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates to the field of data processing, and in particular, to the field of object-oriented framework mechanisms.

[0002]

2. Description of the Related Art A tool is a unit of software, a program or an application module within a program that stores, manages, and retrieves data for a user. For all of the new tools currently being developed,
Tools for designing, implementing, and testing storage for tool data are included. As a result, the costs associated with new tool development (both time and money) are generally not small.

[0003] Most tools are often "exclusive"
It has a unique mechanism for storing and managing data. Exclusive in this context means that the implementation details are not shared with other tool manufacturers or tool developers. This raises a number of problems associated with customizing and extending proven existing tools to the needs of individual users. For example, the interface or "view" portion of a tool may be entangled with the storage or model of the tool, making it difficult to integrate a new view into an existing view. This is referred to as the tool being neutral.

[0004] Also, data created by one tool cannot be directly or transparently consumed by another tool. Instead, operations such as "export", which writes data to an external format that is compatible with other tools, and "import", which reads data in an external format, are required. You must consciously choose to export or import your data.

[0005] Further, a part of the data imported from the external format may be replaced by a data
It is meaningless or incompatible with the store and may be discarded immediately. This sacrifices the integrity of the information that travels and makes it difficult or impossible to iteratively develop information with multiple tools.

Finally, tool developers must add new features to monitor the revision and creation of other tools that manage similar data, and export and import corresponding new data formats. In addition to the direct costs of developing and testing new import and export functions, the introduction of new formats will enable the import and export functions of other tools to process that format There is a time lag until.

[0007] Object oriented (OO) programming, specifically OO framework technology, addresses the costs associated with constantly updating existing tools and providing data integrity when using multiple tools. A method is provided.

[0008] Object Oriented vs. Procedural Techniques [0009] Although the present invention relates to specific OO techniques (ie, OO framework techniques), OO techniques are generally referred to as conventional procedural based techniques (often referred to as procedural techniques). Please understand that this is significantly different from Both of these techniques can be used to solve the same problem, but the final solution to that problem is always quite different. This difference stems from the fact that the design focus of procedural technology is completely different from that of OO technology. The focus of procedural design is on the whole process of solving the problem. In contrast, the focus of OO design is on how to divide the problem into a set of autonomous entities that can work together to provide a solution. An autonomous entity of the OO technology is called an object. In other words, OO technology differs significantly from procedural technology because the problem is divided into a set of cooperating objects rather than a nested hierarchy of computer programs or procedures.

An important feature of OO programming is that objects are reusable software entities that can be combined in different combinations or assigned different attributes for different uses. This one
Examples are described in US Pat. No. 5,550,971. In this specification, a dynamic model for generating a user interface with various "information forms" representing a database schema is described. This model allows users to use different query languages and data
It can be transported to different database management systems without the need to learn the base system, specific database records, fields and relationships. This model is implemented by a set of concrete classes in which instances of each class represent entities and relationships at various distances from the actual database. Objects of these classes are created and correlated to describe the organization of the database. The classes in this model provide a standard interface for exploring the structure of the actual database to create a user interface and caching database information consumed by the user interface.

In a similar series, US Pat. No. 5,428,729.
There is an issue specification. It includes data entities (documentation, source code, test data) within the context of the software project under development.
Describes a system designed to track procedures for accessing, accessing, and translating data (compilers, editors, linkers, documentation formatters, test harnesses).
Each new project under development is created from a template by a "metaprogrammer" and presented through a GUI (graphical user interface). From this "master view", each user can clone a "user view" consisting of a subset of objects from the master, selected according to the user's access rights. Specific flows are described through views, allowing users to access data entities to edit, define and dispatch build procedures,
Define and dispatch test cases. Access rights associate a user with an object via the user's "class." This patent teaches the appearance and flow of a GUI, how the GUI provides access to files stored in an optional but separate repository, and how to store rules for converting files from source to target format. And methods of controlling access through user-specific project views. However, the present invention is not an object-oriented data integration framework, and the fundamental difference between this system and the present invention is that the system of the present invention uses a specified but extensible framework interface and protocol. Thus, it is not designed to promote the impression of consistent behavior between separate and unknown tools.

[0011] Terms have been devised in the art that have particular meaning to those skilled in the art of OO design. But,
The term “framework” is one of the most ambiguous terms and has different meanings for different users. Therefore, when comparing the properties of two hypothetical framework mechanisms, care must be taken to make the comparisons appropriate.

As specifically described below, the term "framework" is used herein to describe an OO mechanism designed to have core and extensible features. Core functions are those parts of the framework that are not subject to change by the framework purchaser. In contrast, extensible features are those parts of the framework mechanism that are explicitly designed so that framework buyers can customize and extend them.

OO Framework Mechanism The OO framework mechanism can generally be characterized as an OO solution. Nevertheless, there is a fundamental difference between the framework mechanism and the basic OO solution. The framework mechanism is designed to allow and facilitate some aspects of the solution. In other words, a framework mechanism is more than just a solution to a problem. The framework mechanism can be customized and extended to address individual requirements that change over time.
Provide a "live" solution. As noted above, customizing or extending the properties of the framework mechanism is of great value to the purchaser, as its cost is much lower than the cost of replacing or revising existing non-framework solutions.

Thus, when a framework designer begins to solve a particular problem, the framework designer does more than just design individual objects and their correlations. The framework designer has two core features of the framework (ie, those that are not likely to be customized and extended by the framework consumers) and the extensible features of the framework (ie, those that are customized and extended). (Possible parts). Ultimately, the ultimate value of the framework mechanism is based not only on the quality of the object design, but also on design choices, including which aspects of the framework represent core functionality and which aspects represent extensible functionality.

One example of a framework is disclosed in US Pat.
25533. The framework described there is an incremental interaction for the development environment,
Provides generation and construction functions.

[0016]

SUMMARY OF THE INVENTION The present invention is directed to a framework for defining a comprehensive but extensible model for storing, managing and retrieving a variety of tool data. The framework is designed to organize all of the information manipulated by a tool into different classes of model objects and the relationships between those objects. All of the model objects and relationships are given three attributes or core functions, each of the model objects and relationships: It has persistence so that objects can exist on disk after the tool is closed, and can be locked to prevent two tools from changing the same object or the same relationship at the same time. Yes, 3 Observations are made so that one tool can detect changes made to an object by another tool and update its presentation.

It is an object of the present invention to provide a framework for naming object instances (model objects), where the object instances include named properties and named relationships.

[0018]

SUMMARY OF THE INVENTION Accordingly, the present invention provides
A framework mechanism for providing common object relationships in context management for multiple tools in an object-oriented programming environment. This framework consists of objects with tool information. Each object consists of a name, a set of attributes, and a set of relationships including references to other objects in the framework mechanism.

The present invention also provides a framework mechanism for sharing tool data. This framework mechanism provides core functionality for maintaining, identifying, and locking objects containing tool data, and allows user tools to tailor tool data to a particular programming environment. Consisting of extensible functions.

[0020]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The preferred embodiment of the present invention has been implemented with a common data model framework that provides a basis for sharing part information between different tools. This framework combines a model mechanism for standardizing the information built by individual tools with a common repository of information that supports partitioning and code generation. One example of a common repository structure implemented in the preferred embodiment is the co-filed "A Hierarchical Me
tadata Store for an Integrated Development Environ
ment "(IBM docket number CA9-97-003), which is fully described herein. The remainder of the specification provides a complete understanding of the preferred embodiment of the present invention. Includes references to common repositories as needed.

As stated above, the principle of this framework is to organize tool information into various classes of model objects and the relationships between these objects.

Each model object contains three items of information: one name, one set of attributes, and a reference to other model objects in the framework.
It has the characteristic of a set relationship. An outline of the model / class hierarchy is shown in FIG. FIG. 2 shows the C ++ interface to the abstract class Object, which represents the object of the preferred embodiment.

Referring to FIGS. 1 and 2, the information associated with the model object 1 includes a plurality of separate characters Defined by columns. Each of the attributes indicated generically by the reference 3 stores a value that is either a regular string 3a or "BLOB" 3b (the term "BLOB" is commonly used in database technology) The term "bin
ary large object ". In this specification, B
LOB refers to an unstructured sequence of bytes. This is described in more detail below).

FIG. 4 shows a C ++ interface to an abstract class Blob representing a BLOB according to the preferred embodiment. Values that are too complex to represent in the form of a string or that are too highly structured can be implemented as a type of BLOB. Every BLOB must provide an operation of setting and checking a segment of data using a character string as a key. The interpretation of this string is completely BLOB dependent.

Another aspect of the framework mechanism according to the preferred embodiment is that the object model relationships 4 shown in FIGS. 1 and 2 are defined in separate classes,
It is to have a mutually unique name. FIG. 3 is a diagram illustrating the C ++ interface to the abstract class Relation, which defines the relationships of the preferred embodiment, defining some of the attributes described below.

Returning to FIG. 1, all of the relationships 4 of the model object 1 have a feature of a name 5 which is a character string.
Each of the relationships 4 also includes a set (zero or more) references 6 to other model objects. Relationship 4 must provide an operation to check the name and an operation to add, check and remove any of its references.

The function of reference 6 is to load the model object from disk to memory if the model object is not already in memory. The reference must be in both directions. That is, if an object references a second object, it is necessary that one of the relationships of the second object includes a reference to the first object. Also, the reference is
Either "strong reference" or "weak reference". When model object 1 is deleted, all object models that strongly reference it are deleted, but when an object that weakly references another object is deleted, it is included in other objects and deleted. Only bidirectional references to the object are deleted.

The other two mechanisms shown in FIG. 1 must also be defined. This is the search context 7 and the lock context. The lock contexts are delete lock 8, rename lock 9, and change lock 10.
There are three aspects.

In the object model, it can be assumed that different contexts depend on the path to the object through the model. FIG. 5 shows an abstract class Sear representing a search context according to a preferred embodiment.
Shows the C ++ interface to chContext. Search context 7 represents a path along a subset of objects in the model. The search context provides the actions of finding and checking attributes, and when asked to search for an attribute, the search context encounters an object with the requested attribute or until the end of the list is reached. Navigate along the list of model objects. If an object with the requested attribute is found, return the value of that attribute. Therefore,
Different search contexts allow one object in the model to appear to have different attributes.

The model objects included in the relationship are:
Before being changed by a tool, it must be locked by that tool. Locks are described in detail below in connection with the preferred embodiment of the framework hierarchy. To change the attributes of a model object, only lock the object itself. Renaming a model object requires locking the object itself, as well as any relationships that refer to that object by name. model·
In order to delete an object, the object itself and all objects directly or indirectly strongly referenced by that object as well as any relationships referring to these objects must be locked. Each object in each relationship is independently lockable, and this basic behavior is sufficient for simple operations such as changing the attributes of an object. The model framework includes a lock context object to handle more complex rename and delete scenarios. FIG. 6 shows the delete lock 8 and the rename
Abstract class DeleteLockCo representing the context of lock 9
Shows the C ++ interface to ntext and RenameLockContext.

A rename lock context can be constructed from a model object before renaming the object. In a rename lock context,
Since some relationships may be keys to the name of a model object, lock all model objects in the relationship that contain a reference to that object.

A delete lock context can be composed of model objects before deleting the objects. In a delete lock context, contains the model object and all of the model objects reachable by the chain of strong references (since they are also deleted on the framework), as well as references to any of the aforementioned objects All of the relationships are locked. These references must be removed from the relationship to prevent unauthorized references.

In another preferred embodiment, the object classes are actually two classes, an abstract class and an implementation class. This is shown in FIG. Each model object has a corresponding implementation object 14
Consists of an abstract object 11 containing a reference 13 to

The complete interface to an object and the behavior of that object is exposed through the abstraction of the object. However, in practice, only the name 12 of the object is stored in the abstract part. Object attributes 15 and relationships 16 are hidden in the implementation.
Requests for non-name information about an object are secretly satisfied by the implementation, and possibly by any of the relationships contained in the implementation.

Since the abstract, implementation, and relationship objects are independently persistent, requesting the name of the object incurs the cost of loading the abstract portion from disk 17, but loading the implementation portion or relationship. No need. This technique minimizes the amount of data transferred from disk to satisfy the query and improves the overall performance of the tool on the framework.

Using the above definitions, the framework of the preferred embodiment provides an environment and support mechanism for implementing a flexible containment hierarchy of development parts. The base classes define the basic behavior for part locks (also called containment support), references between objects, attribute / property access, runtime type identification and persistence. All tools derive concrete implementations from this set of base classes.

FIG. 8 is a diagram illustrating an abstract base layer according to a preferred embodiment of the present invention. The core functions of this hierarchy are, above the dashed line, a persistence class 20, a notification class 21, and a lock class 2, which are identified as base classes of this hierarchy
2. This does not mean that these classes cannot be overridden (as is possible with C ++ programming), but some form of persistence, identification and locking is a core feature required for the framework of the present invention to work. Means that. The classes below the dashed line, starting with IDE element class 24, illustrate some of the data model types that can be included in the framework hierarchy. These additional classes are defined in the Appendix, and a number of additional classes have been published in co-pending patent applications (IBM
Docket number CA9-97-003).

The inheritance in the framework hierarchy of the present invention is as follows:
Operates to provide: The persistence service maintains the state of the data model in the host computer's file system and shares this data among multiple running programs. Model objects derived from this framework hierarchy are
Grouped into files in the system. File·
Objects in the system are referred to as "committed models." When a program using the framework model runs, only the data of the committed model is visible. All changes to the model
It is performed on an in-memory copy of the model object in the private address space of the single running program.

The lock service enforces mutual exclusion of changes to the model. Since each of the running programs makes changes to the private in-memory copy of the model objects, there is no possibility that two programs will modify or delete the same object at the same time.
The lock service provides a mandatory lock scheme that prohibits simultaneous access. This will be described in detail below.

Referring to FIG. 8, by inheriting from the base class, the persistence class 20, model objects are created from the default local heap of each program, and by persistence, the host computer's file system. Is shared via In many C ++ implementations, dynamic or late binding is typically implemented within each object as a pointer to a class-specific table of constant method pointers. The method table pointer is usually stored in a dynamically linked library or executable program, but is inaccessible because all executable images are different and the location of the table is different. as a result,
In a typical implementation, it is not possible to store C ++ objects in shared memory and access their data from different executable programs.

The persistence service of the present invention avoids this problem through creation from the default local heap.

The persistence class 20 also provides a mechanism for all classes in the framework to read and write to disk. All of the derived classes in this model that extend the base object state must provide their own "read" and "write" methods, whereas the persistence class provides Capabilities are also defined, so that lower classes will override stream operators for use in converting between disk-shaped objects and in-memory objects. The stream operator is
Call the unique "read" and "write" methods of each object to do the actual work. The following implementation conventions are used by all classes in defining the "read" and "write" methods of derived classes in the preferred embodiment.

In a preferred embodiment, the framework is C
++ Provides a standard interface to enforce mandatory mutual exclusion of objects. The class that uses this implementation derives from lock class 22. Mutual exclusion is
Lock class 22 itself is a subclass of persistence class 20 because it is needed only for objects that are shared between running programs.

The locking scheme provided by lock class 22 is described below. However, there are two cases where these mechanisms become inappropriate. One is a global "parts" list, which is a data structure whose data structure is guaranteed to contain all objects of a particular type.
Another is a "dirty pool", which is a mechanism for updated meta information that is stored with the model object but not as part of it.

Lock class 22 is a model abstraction for lockable persistent objects. This provides the locking primitives used in the model. In general, these primitives are not used directly,
Called as part of a complex object lock.
An object lock is created in the following two steps. 1. Get the lock identifier for the desired type of action. In the preferred embodiment, the lock pool is a singleton C ++ class located in a scalable shared memory pool that operates on a fixed size named shared memory segment, as described below. Thus, the lock identifier is actually an array index in the pool. 2. Then, using the lock identifier obtained by instantiating the lock object type,
Create a shared or exclusive lock. In the preferred embodiment, the lock is acquired by a C ++ constructor and is typically used as a local instance to ensure that the destructor is executed automatically, regardless of how the code block ends. Failure to acquire a lock is signaled by an exception. Destructors release locks in most cases, with one exception being the change lock context.

In C ++ programming convention, a singleton class indicates that there can be only one instance of that class per process at a time.

The use of a scalable shared memory pool as a repository for locking objects, separate from the tool data model object itself, is described in the co-pending patent application entitled Locking Tool Data Objects in a F
ramework Environment "(IBM docket number CA9-
97-010).

The scalable shared memory pool has a fixed size from the system's named shared memory pool.
It is a peer pool mechanism that uses segment allocation. Segment names are created by appending a segment number (starting from 0) to a predefined character sequence. Each process has its own pool
It has a singleton pool that operates segments.
When a new segment is needed, an attempt is made to calculate its name and find the segment in current memory. If not found, allocate a segment. This process means that the first process that needs a memory segment will allocate it, and all subsequent processes will re-access that segment (thus client /
Synchronized (equivalent to server). Each singleton pool class within a process holds an array of all segments known to that class. This allows all segments in the process to be accessed as fast indirects in the array. In addition to an array of segments, a special named area is allocated that contains global information about the pool. The name of this area is fixed, and the process that starts the pool first allocates the area. Access to global information in the pool is synchronized to avoid race conditions between multiple processes.

Each segment is treated as a fixed size array of objects, so that each segment is divided into "n" pieces of size "x"("x" is located in the pool) Object size). Each process requests a pool ID when it needs one piece of storage. The pool uses the global information segment to look for the largest index currently given. If the next value is still in the segment (ie, not a multiple of n), simply return that value. Otherwise, it checks all objects currently in the pool to find those that are not in use. Each of the "n" pieces of storage in the pool segment must have an indicator that marks it as busy or unused so that the singleton class can perform this check. If an unused object is found, return its index and mark its storage as in use. If not found, allocate a new segment.

After the index is provided, it can be used to access shared memory storage via special pool methods. This pool method simply receives the index and calculates the segment number and the index within the segment. After that, this pool
The method accesses an array of segment addresses and computes the addresses of the objects in the segment. In this manner, the same ID can be used by multiple processes, even if different virtual addresses are assigned to shared memory on some platforms, such as Windows NT. This calculation is performed according to the following equation. Segment number = pool ID / n segment index = pool ID mod n

The pool is scalable because segments are allocated as needed. Pools are equal because the number of processes involved and the order in which they start up does not matter (no servers are required).
This mechanism requires only two indirect designations to access items by ID.

In the preferred embodiment of the present invention, there are two types of lock objects: 1. Shared lock Shared read-only access 2. Exclusive lock Read / write access restricted to one process

As can be seen from the state diagram of FIG.
Creating an object locks access to its underlying lockable model object. Destroying a lock object almost always requires unlocking access. Thus, by instantiating the delete lock type and removing the instantiation of the shared lock type, limited shared read / write access to the underlying model objects is restored. This ensures that the object will not be deleted and allows other processes to read or modify the object (ie, obtain a shared or exclusive change lock). The exception is when the underlying locked object has changed. This lock can be destroyed when saving changes.

Forced locking for creation and destruction is implemented through some convention. Framework class constructors and destructors are "protected".
This prevents the program from directly creating or deleting objects. Instead, all framework classes have "create" and "destroy" methods for class data. In the create method, before creating the object,
Get the locks needed to create objects and insert them into existing models. The destroy method gets all the locks needed to remove all references to the object from the model before deleting the object. Failure to acquire a lock results in abnormal termination of the alter operation, the model state is unchanged, and an exception is thrown.

The lifetime of the lock is determined by the persistence subsystem,
Depends on both the existence of a lock object referencing the lock in memory. This is shown in FIG. LockObject100 which is a lock object class is a shared lock class SharedLock102 as a derived class.
And an exclusive lock class ExclusiveLock104. The difference between these classes is that shared locks can have multiple processes, while exclusive locks are limited to only one process at a time. A single process resource can have one exclusive lock on it, or one or more shared locks.

When a LockObject 100 is instantiated by a lockable object LockableObject 106, a lock is located by referring to the lock pool LockPool 108 via the lock ID assigned when the lockable object was created. . Shared Pool Segm in rock pool
ent112 is the process ID o of the lock owner
wningPID 116 is included. If the lock owner attempts to reacquire a lock already owned, this reacquisition is allowed.

In the case of a shared lock, the process ID is always a dummy identifier or a reserved identifier. The same dummy identifier is used in all attempts to acquire a shared lock. Thus, if the shared lock is already held by another process, the process IDs match,
Locks are granted. Use a reference counter to keep track of the number of shared lock owners. This counter is
It is incremented by one each time a lock is acquired and decremented by one each time a lock is released. When the counter reaches zero, the lock is no longer owned by any process and is ready to be used as either a shared or exclusive lock.

In the case of an exclusive lock, the actual process ID is used to prevent sharing. A special type of exclusive lock is a "change" lock, which records the changed state of a locked object. If the object has not changed, the lock is released immediately when the lock's destructor runs. If the locked object has changed, the change lock is not released by the change lock destructor until all changes to the locked object have been committed or canceled by save. If the change lock is not destroyed (even when the save is performed), the object remains locked. Programs can rely on this behavior to keep objects locked between saves.

Two exceptions to the use of this locking mechanism are the global parts list and "dirty pool" mentioned above.

The global parts list contains a set of objects having unique names. In the framework of the preferred embodiment, this is contained in a single object, which is a singleton class. When implementing a shared memory list containing a data structure that detects name collisions, one part is added to the global list of a program, and the name of the part is compared to the committed list of parts and the uncommitted part Tested for uniqueness in both shared lists of part names. If the name is not unique, the add operation fails and an exception is raised. If not, the insert operation is complete and the name is added to the shared heap to prevent other programs from using it.
Each running program maintains a list of objects inserted by that program. When a save operation is in progress, the program removes all of these objects. Storing names only provides scalability in that the amount of shared memory used to prevent name collisions within the global parts group is minimized.

The second exception is a dirty pool.
It points to an index pool that tracks whether an object has changed without a corresponding update to the object's source code file. When an object's dependencies change, the object must be regenerated. By not changing the actual object, lock contention between processes is reduced and performance is improved. When an object and its source file did not match, the object was called "dirty" or "dirty" and thus became the name of the index pool. Dirty pools use the scalable shared memory pool mechanism to support remote data for shared objects. Remote data is an object-independent, encapsulated object state. This data can be changed without performing the sequence of locking, changing, and saving the object, thereby reducing the need for lock contention between processes. In a dirty pool, a lock pool indexing scheme is used, and one identifier is assigned to one object, the identifier in the dirty pool index being permanent for the life of the model object. It is a bit segment. Dirty
Each of the pool segments is split into two.
The first half has a busy bit and the second half has a dirty status bit. This pool is permanent in the preferred embodiment. The dirty pool can stream itself to and from disk. In this way, information about whether the source of the object needs to be regenerated can be queried in a subsequent session.

There are three requirements for the persistence service when committing changes to the model: 1. The program must not be able to read the new version of the old object from the committed model during operation. 2. Failure to complete writing changes to a file must not destroy the committed model. 3. Changes made in one program must not overwrite changes committed by another program.

Storage is implemented as a two-phase commit to a file system that is synchronized by an interprocess communication protocol. This process is shown in the flowchart of FIG.

In this inter-process communication protocol, two events, “storage pending” and “storage complete”
Use These events are implemented using a shared memory flag, a shared memory counter, and two host system semaphores called "notification" and "acknowledgment."

Archiving begins when the archival program sends an "archiving pending" event (block 4).
0). "Send event" sets the shared memory flag of the event to true, initializes the model's shared memory count to the number of programs added to the model, and sets the "acknowledgment" semaphore. Reset and post a "notification" semaphore.

When the flag file indicates that the first phase of the save has been initiated (block 42), the source program writes all of the files it has modified to a temporary file (block 44). Storing in a temporary file prevents those programs from accessing the temporary file if other programs are still actively using the model. This satisfies half of Condition 1 for the purpose of secure storage, in that no other program can mix objects from the committed model with objects in the temporary file.

After completing the writing of the changed file to all temporary files (block 46), the archival source program waits for the completion of the "archiving pending" event. This is signaled to the sending program when the "acknowledgment" semaphore is posted (block 48).

The storage pending event is stored in the framework
Processed by worker threads in each program attached to the model. When an event is received,
The worker thread wakes up. The thread determines whether the program has been added to the saved model by comparing all models open in the program with models for which the save flag is set. If the program is attached to the saved model, use a cross-thread package to post a notification to the main thread of the program. This notification is received asynchronously after the main thread completes processing of all notifications and GUI events received before the pending storage notification (block 5).
8).

When the main thread of the program receives the same pending notification, it stops demand loading or changing objects in the model (block 6).
0). This completes the requirement 1 that the program cannot mix new and old objects.

When the other program receives and processes the pending-save event, it acknowledges the receipt of the event by decrementing the shared memory counter by one (block 62). When the counter is decremented and equals one, all programs are processing the "notification" and the event "acknowledgment" semaphore is posted, indicating the completion of the event (block 64), whereby The source program wakes up (block 48).

When the "save pending" event is completed, the archival program indicates that the first phase of archival is complete via a flag file on disk (block 46). If an interrupt such as a system crash occurs before this point, all changes will be lost, but the database will be kept in a consistent state.

If no errors occur, all of the data needed to access the modified version of the model is written to disk, and a system or program crash causes the model on disk to become inconsistent. There is no possibility. Thereafter, the archiving program renames all of the temporary files to the correct names and removes all empty data files from the committed model (block 50). This means that all of the modified files have their contents replaced with the contents of the temporary file, which satisfies secure storage requirement 2.

The storage source program is composed of a waiting worker
A "save complete" event is sent to the thread and the program main thread (block 52), indicating to all other programs that the model on disk is consistent and waiting for the event to complete (block 54). Then, cleanup is performed (block 56).

Another core function found in the notification class 21 of FIG. 9 provides a mechanism for communicating tool data changes in the framework to other users. This mechanism is also shown in FIG.
It is shown in FIG.

All other programs that have been added to the model wake up upon receiving the "save complete" event (block 64). These programs call the framework refresh method (block 6).
6). This method examines each of the files opened by the program and loads the latest version of each changed object. After this process is completed, all programs will include a private in-memory version of the model, consistent with the latest saved changes.
Save Completed if the program contains objects that were deleted or modified by the archiving program
The program receiving the event causes a model / view / control notification to be sent to all observers observing the affected object (block 68).
The observation of these notifications is the hook that the program uses to change its internal state in a manner consistent with the changes committed to the model. After performing the refresh, each program acknowledges receipt of a storage complete event (block 70).

When the storage completion event is completed, the storage source program and all worker threads wake up. The archival program completes all housekeeping operations and returns from archival. Worker threads are
The process returns to the waiting state for waiting for an inter-process event pending storage.

In another preferred embodiment of the present invention, the persistence service provides for the failure of a fault because it is not always possible to determine in advance whether the operation of modifying a large number of model objects will complete successfully. Provides the ability to return to a known good condition. This process is shown in FIG.

This check point mechanism restores the state of a program in private memory. Saved states include all deletions, creations, and modifications of objects and objects and data since the program started or since the program saved the model.
Contains the persistence service data structures used to manage files. While the Check Point mechanism is operating,
This data is stored in a temporary file.

The program calls the Check Point mechanism to indicate that it initiates a change that may need to be restored to a previous state (block 76). The persistence subsystem looks at each of the persistence files opened by the program on the model. The persistence subsystem identifies objects whose state in memory is different from the committed state (block 78).
In memory, the modified object is flagged as being stored in a temporary file (block 8).
0 and 82).

If the change attempt is unsuccessful, an exception is usually thrown and received (blocks 84 and 86).
Therefore, the "roll back" method is called (block 88). The rollback method recreates the object that was deleted after the check point,
Remove the objects created since Check Point and restore the state of all changed objects and the state of the persistence services data structures to the state they were in when Check Point was called (block 90). .

If the process determines that the algorithm has completed successfully (blocks 84 and 86), the process calls "commit" (block 92) to release the resources used by the Check Point mechanism. , Indicates that the internal model state is consistent.

Appendix The following defines the data model class shown in FIG. 8 according to the preferred embodiment. Basic: Names, Named Properties, Named Relationships IDE Elements: Allows creation / manipulation of graphical tree views / tree elements Inclusion: Folder / Grouping Scope: Namespace Scope File Reference: One Disk File Pointer Sub Parts: For example, C ++ data members Name scope folder: The concept of grouping by namespace scope Named parts: Basic complex type Model: Singleton root Builder Consumable parts: Component (Allows composition / operation by composite editor ) Typedef: alias of parts enum: set of named ordinals struct: record union: overlapping structure base type: base type builder separable container: part that enables distribution Classification

In summary, the following items are disclosed regarding the configuration of the present invention.

(1) An object-oriented programming environment in which each object has an object with tool information, including a name, a set of attributes, and a set of relationships including references to other objects in the framework mechanism. Within, a framework mechanism for providing common object relationships in context management for multiple tools. (2) The framework mechanism according to (1), wherein the tool information in each object is defined by a plurality of separate character strings. (3) each object includes a standard defined value string and the undefined value string having an action of setting and checking a segment of data included in the undefined value; The framework mechanism according to (2), which provides a definition for a character string for an attribute. (4) The relationship in the object set is bi-directional, defined as a strong or weak relationship, such that upon deletion of an object, all other objects referenced by the deleted object are deleted upon deletion of the object. The framework mechanism according to (1), wherein all references to the deleted object are deleted when the object is deleted due to the weak relationship. And (5) further including a mechanism for locking the object to permit changes made to the object by a single user, the mechanism including an object and a reference to the object for permitting the object to be renamed. An object and all other objects strongly referenced by the object, and a reference to or strong reference to the object, to lock all relationships, including, and to allow the deletion of the object (4), including a delete lock, which locks all relationships involving references to all other objects being created, and a change lock, which permits all changes to the object and affected relationships. The described framework mechanism. (6) The framework mechanism according to (1), wherein each object includes an abstract class and an implementation class. (7) The framework mechanism according to (6), wherein, for each object, the name of the object is stored in the abstract class, and the set of attributes and the relation of the object are stored in the implementation class. (8) The framework mechanism according to (7), wherein a set of attributes and a set of relationships stored in the implementation class of the object are hidden. (9) A framework mechanism for sharing tool data, which allows for extensible functions for user tools to tailor tool data for a particular programming environment, wherein the tool data is shared. A framework mechanism that includes core functionality for maintaining, identifying, and locking the containing objects. (10) A core function for maintaining persistence provides a basic mechanism for all classes in the framework to write objects to disk and read objects from disk to an in-memory format; But,
The framework mechanism according to (9), which can be extended in a derived class by a specific read method and write method. (11) the basic mechanism includes a streaming operator for converting the object from a disk format to an in-memory format, wherein the streaming operator invokes a read method and a write method of the object itself; The framework mechanism according to the above (10). (12) Core functions for maintaining persistence are tools and
A shared memory flag that is activated while the file containing the data is stored,
The framework mechanism according to (9), further including a communication semaphore adapted to notify a process dependent on tool data in the file in an active state and an inactive state of a shared memory flag. (13) The core lock function locks the object and all of the relationships including references to the object to permit the object to be renamed.
A lock and an object, all other objects strongly referenced by the object, and a relationship involving a reference to the object or to all other strongly referenced objects, to permit deletion of the object. The framework mechanism of (9), including a delete lock that locks everything, and a change lock to allow changes to objects and affected relationships.

[Brief description of the drawings]

FIG. 1 is a schematic diagram illustrating a class hierarchy of model objects according to the present invention using OMT (Object Modeling Technique) notation.

FIG. 2 is a class diagram of a framework mechanism according to a preferred embodiment of the present invention, represented by C ++.

FIG. 3 is a class diagram of a framework mechanism according to a preferred embodiment of the present invention, represented by C ++.

FIG. 4 is a class diagram of a framework mechanism according to a preferred embodiment of the present invention, represented by C ++.

FIG. 5 is a class diagram of a framework mechanism represented by C ++ according to a preferred embodiment of the present invention.

FIG. 6 is a class diagram of a framework mechanism according to a preferred embodiment of the present invention, represented by C ++.

FIG. 7 is a schematic diagram similar to FIG. 1, showing the object model as two classes, according to another preferred embodiment;

FIG. 8 is a hierarchical category diagram of a framework mechanism constructed according to the teachings of the present invention using OMT notation.

FIG. 9 is a state diagram showing a locked state of an object.

FIG. 10 is a schematic diagram illustrating a locking mechanism implemented in a preferred embodiment of the present invention.

FIG. 11 is a flow diagram showing the steps for saving tool data changes using the core functionality of the present invention.

FIG. 12 is a flow chart showing the steps for issuing a notification of a change in tool data using the core functionality of the present invention.

[Explanation of symbols]

 1 model object 2 character string 3 character string 3a character string 3b BLOB 4 relation 5 name 6 reference 7 search context 8 delete lock 9 rename lock 10 change lock 11 abstract object 12 name 13 reference 14 implementation object 15 attribute 17 relation 17 disk Reference Signs List 20 persistence class 21 notification class 22 lock class 24 IDE element class 100 LockObject 102 SharedLock 104 ExclusiveLock 106 LockableObject 108 LockPool 112 lock 116 owningPID

 ────────────────────────────────────────────────── ─── Continuing on the front page (72) Inventor Jeffrey Grant Johnston Canada M1S2X4 On Scarboroughborough, Ontario Hoody Hill Crescent 34 (72) Inventor Vladimir Criticnik Canada L1G2S2 Ontario Oshawa Pinewood Street, 567 (72) Inventor David Martin Lawson Canada M9C 4N5 Ontario Etobicoke Rangoon Road 47 (72) Inventor Lok Tin Roy Canada M4B 3M8 East York, Ontario Park Vista Drive 4 Suite 1208 (72) Inventor Dark Alexander Thielman The Second Canada L 3 Tee 4 Zet 3 on Thornhill, Tario Kindale Way 56

Claims (13)

[Claims] 1. An object-oriented programming environment comprising an object having tool information, wherein each object includes a name, a set of attributes, and a set of relationships including references to other objects in the framework mechanism. so,
Framework mechanism for providing common object relationships in context management for multiple tools. 2. The framework mechanism according to claim 1, wherein said tool information in each object is defined by a plurality of separate character strings. 3. An object according to claim 1, wherein each object comprises a string of standard defined values and a string of undefined values having an action of setting and checking a segment of data contained in the undefined values. 3. The framework mechanism of claim 2, providing definitions for strings for attributes, including. 4. The relationship within the set of objects is bidirectional and is defined as a strong or weak relationship, wherein the strong relationship causes all other objects referenced by the deleted object upon deletion of the object. 2. The framework mechanism according to claim 1, wherein, upon deletion of the object, all references to the deleted object are deleted due to the weak relationship. 5. The system further includes a mechanism for locking the object to permit changes made to the object by a single user, the mechanism comprising: An object and all other objects strongly referenced by the object, and a reference to the object, to lock all relationships, including references to the object, and to allow the object to be deleted. 5. A lock comprising: a delete lock, which locks all relationships containing references to all other strongly referenced objects; and a change lock, which permits all changes to the object and the affected relationships. The framework mechanism described in 1. 6. The framework mechanism of claim 1, wherein each object includes an abstract class and an implementation class. 7. The framework mechanism of claim 6, wherein for each object, the name of the object is stored in an abstract class, and the set of attributes and relationships of the object are stored in an implementation class. 8. The framework mechanism according to claim 7, wherein a set of attributes and a set of relationships stored in an implementation class of the object are hidden. 9. A framework for sharing tool data, which allows for extensible functionality for user tools to tailor tool data for a particular programming environment, the framework mechanism for sharing tool data. A framework mechanism that includes core functionality for maintaining, identifying, and locking objects containing data. 10. The core functionality for maintaining persistence provides a basic mechanism for all classes in the framework to write objects to disk and read objects from disk to an in-memory format. 10. The framework mechanism of claim 9, wherein the base mechanism is extensible in derived classes by specific read and write methods. 11. The basic mechanism includes a streaming operator for converting an object from a disk format to an in-memory format, said streaming operator being adapted to invoke read and write methods of the object itself. The framework mechanism of claim 10, wherein: 12. The core function for maintaining persistence includes a shared memory flag that is activated while a file containing tool data is stored, and the core identification function includes: 10. The framework mechanism of claim 9, including a communication semaphore adapted to signal active and inactive processing dependent on tool data in the file. 13. A core lock function for locking an object and all of its relationships, including references to the object, for permitting the object to be renamed, a rename lock, and a method for permitting the deletion of the object. A delete lock, which locks an object, all other objects strongly referenced by the object, and all relationships involving references to the object or all other strongly referenced objects; 10. The framework mechanism of claim 9, including a change lock to allow changes in affected relationships.