KR20010103604A - Apparatus and method for building modeling tools - Google Patents

Abstract

A method and system for an extensible macro language is provided. The system for providing the extensible macro language includes a parser and a macro handler for processing macro commands not previously defined in the macro language. The parser analyzes keywords in a macro language expression and recognizes one or more keywords representing macro commands that were not previously defined in the macro language. The macro handler receives the keywords in the macro expression and retrieves from a registry of keywords, an executable code or procedure associated with the keyword. The executable code is run to process the macro command represented by the keyword. The template language registry may be augmented to include any keywords and associated codes for extending the macro language.

Description

Apparatus and method for making modeling tools {APPARATUS AND METHOD FOR BUILDING MODELING TOOLS}

Reference to the appendix

This application contains annex appendix that describes exemplary services and functions for the exemplary embodiments of the invention that are cited herein. The public portions of this application contain copyrighted works. The Copyright Holder does not challenge the facsimile copying of one of the co-inventors of the present invention with a patent publication as indicated in the Patent and Trademark Office patent file or record. However, anyone else reserves the copyright.

Background of the Invention

The present invention relates to a modeling engine, and in particular to an apparatus and method for manufacturing a modeling tool.

Background Information

Modeling tools have been around since the past. A common way of constructing these modeling tools is to record special modeling tools that use special modeling methods. This method has been generally accepted, but this method has some disadvantages. For example, conventional modeling tools require a new configuration each time a new modeling tool is created, although many of the functions within a given tool are not the same but similar.

Accordingly, there is a need for a method and apparatus for fabricating a modeling tool using a single structure configured to support generating a plurality of entirely different modeling methods. This new modeling tool builder and methodology will save the effort and time required to construct a new modeling tool.

This application is related to the advantages of US Patent Provisional Application No. 60 / 104,682, filed October 16, 1998, entitled "Modeling Tool Systems and Methods," which is incorporated herein by reference. .

This application is related to US Patent Provisional Application No. 60 / 104,682 (Representative Document No. # 22074661-25532), filed concurrently with the same applicant, and entitled "Method for Impact Analysis of Models." It is cited herein.

This application is related to US Patent Provisional Application No. 60 / 104,682 (Attorney Docket No. # 22074661-25531), filed concurrently with the same application, and entitled "Method for Determining Differences Between Two or More Models". This US patent is incorporated herein.

This application is related to US Patent Provisional Application No. 60 / 104,682 (Representative Document No. # 22074661-25533), filed simultaneously on the same date and entitled "Method and System for Extensible Macro Language". Patents are cited herein.

This application is filed concurrently under the same application and is disclosed in U.S. Patent Provisional Application No. 60 / 104,682 (Representative Document No. # 22074661-25534) entitled "Method and Apparatus for Accessing Hierarchical Data Storage via SQL Input". As related, such US patents are incorporated herein.

1 shows a functional block diagram of a conventional computer system.

2 illustrates a functional block diagram of an exemplary embodiment of the present invention.

3 illustrates a data model of an exemplary embodiment of the metamodel of the present invention.

4 shows a flowchart of an exemplary embodiment of a method of implementing object semantics of the present invention.

5 shows a flowchart of an exemplary embodiment of a method of implementing the characteristic semantics of the present invention.

6 shows a flowchart of an exemplary embodiment of a method of creating a modeling tool of the present invention.

7 shows a flowchart of an example embodiment for carrying out the example functions of the present invention.

One feature of the present invention is to provide a method and apparatus that includes semantics and models with objects and properties. Semantics are supplied at the time of transactional modification of objects and properties that may be included in the model. No change is made to objects and properties by transactions that violate individual semantics. In addition, the developer can extend the semantics.

Another feature of the invention provides an apparatus for manufacturing a modeling tool. The apparatus includes, for example, a metamodel with a semantic register and a metadata manager, an object / property interface and an object / property builder register. An object / property builder register is coupled to the metamodel and the object / property interface. The device also includes an object / property model coupled to the object / property interface.

Another feature of the invention provides a method of making a modeling tool. The method involves constructing an object / characteristic model by defining a first set of classes and constructing a metamodel by defining a second set of classes. The method also includes associating a type code with a first set of classes and a second set of classes and supplying a metaset with a predefined set of semantics. The method also includes recognizing the plurality of independent tasks when the semantics of at least one of the semantic sets are invoked upon each occurrence of the plurality of independent tasks. The method also includes providing an object / property interface for restricting the developer from accessing the object / property model.

1 shows a conventional computer system 101 in which the present invention operates. In an exemplary embodiment, the present invention is practiced, for example, on a SUN workstation manufactured by SUN MICROSYSTEMS. Other embodiments may be implemented, for example, on a IBM (registered trademark) personal computer manufactured by IBM Corporation or a MACINTOSH (registered trademark) computer manufactured by APPLE (registered trademark) computer. It will be apparent to one skilled in the art that other computer system architectures may be used. In general, such a computer system shown in FIG. 1 includes a bus 102 for communicating information, a processor 103 such as a central processing unit coupled to the bus 102 for processing information, and the bus 102 And a main memory 104 for storing information and instructions for the processor 103. Read-only memory 105 is coupled to bus 102 to store static information and instructions for processor 103. Display device 106 coupled to bus 102 displays information, for example, for the developer.

An alphanumeric input device 107 such as a keyboard is coupled to the bus 102 to communicate information selection and command selection with the processor 103. Modem 110 is coupled to bus 102, for example, another computer system or database, a mass storage medium 108, such as a magnetic disk, and an associated disk drive coupled to bus 102 for storing information and instructions. Communicate with The data storage medium 109 carrying digital information is configured to interlock with the mass storage medium 108, for example, so that the processor 103 can access the digital information on the data storage medium 109 via the bus 102. To be. Also, a CD-ROM drive (not shown) for storing high resolution images may be used for display on the display device 106.

One embodiment of the invention may be implemented as a software module written in the C ++ programming language, which may be executed, for example, in a computer system such as computer system 101 in a conventional manner. Using known techniques, the application software can be stored on the data storage medium 109 and then loaded and executed in the computer system 101. Once disclosed, the software of the preferred embodiment operates, for example, in the manner described below. The Universal Modeling Architecture (UMA) is a data-driven modeling engine that can work in a variety of problem areas based on external definitions of metamodels that developers can provide and can be extended to provide UMA-based products. have. An external definition of a metamodel is a series of descriptions of the types of objects that may appear in a problem area, for example, and the characteristics associated with each of those objects. This description can be supplied by invoking the function set indicated by the usage example and passing the description information via the function parameters. Exemplary problem areas include data modeling such as data tables, columns and indexes, processing modeling such as activities and flows, access modeling such as data manipulation language statements and files, and interfaces, applications and dependencies; There is the same component modeling.

In an exemplary embodiment of the invention, the UMA-based product is a modeling tool. The UMA-based product may be a UMA-based application, such as a user interface that includes the UMA. In addition, a UMA-based product may include an example of an object / characteristic model based on, for example, an external definition of a metamodel supplied by a developer.

In an exemplary embodiment of the present invention, as shown in FIG. 2, the UMA 200 includes a metamodel 210, an object and property builder register 260, an object / property interface 280, a transaction manager 285. , Log file 295, and object / property model 290. The metamodel 210 may include a semantic registration unit 220 that includes a plurality of sets of semantic units 230, and a metadata manager 240 that includes an object / characteristic description unit 250. . The object / property descriptor 250 is a set of information that describes the characteristics of an object or property. In the case of an object, this may include its name, human readable portion of the descriptive text, generalization information, and information about whether other types of objects may be included therein. For example, generalization information describes subdivision / subtyping such as synonym information.

The object / property description is an externally defined metamodel that can be provided by the developer or user. The metamodel 210 describes the objects and properties of the problem area to be solved, and the description of a plurality of sets of semantics 230 that must each be called to change these objects and properties when a change to the objects and properties is required. to be.

3 illustrates an exemplary embodiment of the metamodel 210 of the present invention. As shown in FIG. 3, the metamodel 210 includes a plurality of classes such as objects, properties, and semantics, and establishes relationships between objects, properties, and semantics. Type 310 is associated with a type code key, a name attribute, and a definition attribute. Type 310 may be, for example, category 330 or item 320. Category 330 is associated with a type code key and includes a plurality of items. Category qualification 340 is associated with a category key and a member key. Item 320 is associated with a type code key and may be a property or an object.

Property 350 is associated with a type code key, a default value attribute, and a data type attribute. In addition, feature 350 is associated with feature use 375. Object 360 is associated with a type code key, an object implementation attribute, and a supertype attribute. Supertype attributes provide more special content to the object 360. Object 360 may own or include other objects (eg, include as components). Object ownership 370 is associated with an ownership assigner key and an ownership assignee key. Property use 375 is associated with a property key and an object key.

Property usage 375 also associates property 350 with object 360. Object semantics uses 390 are associated with type code keys and identification (ID) keys. Object Semantics Use 390 associates object 360 with object semantics 395. Feature semantics Use 380 is associated with an ID key, a feature key, and an object key. Feature semantics use 390 associates feature semantics 385 with feature use 375. Feature semantics 385 are associated with ID keys.

As shown in FIG. 2, meta data manager 240 of meta model 210 receives meta data (eg, description of objects and properties), eg, from a developer via UMA based application 225. Metadata is objects and properties supplied by developers to solve their problem areas. Metadata manager 240 receives a justification generation request from object and property builder register 260.

As shown in FIG. 2, the semantics register 220 of the metamodel 230 includes a plurality of sets of semantics 230, the semantics of which set being supplied by a developer through, for example, a UMA based application. It can include one predefined set and additional sets. The semantic unit 230 is a modeling rule encapsulated within a semantic object that represents an interface like a pure virtual class and hides the modeling engine from the details of the semantic unit 230. The predefined set of semantics provides the rules for preserving the basic modeling engine, and in a preferred embodiment of the present invention, the developer cannot change the semantics of the predefined set. An additional set of semantics provided by the developer can be modified by the developer. An example of semantics may be to enforce the rule, for example, that two columns in a database table cannot use the same name.

The semantic unit 230 accesses the object / characteristic model 290 via the object / characteristic interface 280. The semantics register 220 may include an object semantics register to determine if there is a special set of object semantics and, if so, to find individual sets of object semantics. Further, the semantic register 220 may include a characteristic semantic register for determining if there is a special set of object semantics and, if any, to find the characteristic semantics of the individual set. The semantics register 220 finds a separate set of semantics, for example required by the object / characteristic interface 280. The semantics register 220 makes changes to individual objects and properties in accordance with the called semantics, and supplies the changed objects and properties to the object / characteristic interface 280. In addition, the semantic register 220 also supplies the state of transaction behavior to the object / characteristic interface 280. For example, one of the semantics called for a given action may indicate that the action failed because it violated the rule.

The object and property builder register 260 may include a builder 270 such as an object builder and a property builder, respectively. The object and property builder register 260 receives a request for the creation of objects and properties from a developer, for example via a UMA based application 225. Builder 270 creates objects and properties. The object and property builder register 260 determines if there is a special builder, and if so, finds that individual builder and creates the individual objects or properties that are required. In addition, the object and property builder register 260 supplies the justification generation request to the metadata manager 240. The justification can include, for example, whether the creation of the required object or property was successful. The object and property builder register 260 demonstrates objects and properties, respectively, and supplies these objects and properties to the object / property interface 280.

As shown in FIG. 2, object / property interface 280 receives, via a UMA-based application 225, a request for modification and deletion of objects and properties, for example, by a developer. This request calls for individual semantics in metamodel 210 which may be a change to the objects and properties supplied to object / property interface 280 from semantics register 220 of metamodel 210. The object / property interface 280 may recognize any independent task among a plurality of discrete events, for example, as shown in Table 1, and determine whether a given semantic portion or set of semantic portions should be called. . Independent work represents an occurrence in which the object / property model 290 can be modified. In an exemplary embodiment of the invention, the author of the UMA may provide a plurality of independent work.

a constant Explanation PostCreation The object is being created PreDestruction Object is destroyed PreEdit The property is about to be created and / or modified PostEdit The property has been created and / or modified PreNull Talent is about to be destroyed PreOwnerDestruction The object owning the property is about to be destroyed

The object / property interface 280 is supplied with the status of the transaction's behavior by the semantic register 220 based on the results of the individual sets of semantics called. For example, if a certain action violates the provision of any of the semantic parts of the called set, the semantic register 220 may provide an indication that the action failed. However, if the action did not violate any of the semantics of the set, the semantics register 220 may provide an indication that the action was successful. The object / property interface 280 supplies the object and property changes to the transaction manager 285, and if the object / property interface 280 determines that "an action failed", it displays an indication that the action failed. May be supplied to transaction manager 285. Object / property interface 280 also supplies objects and properties to object / property model 290. The object / property interface 280 also receives objects and properties from the object / property model 290 and, for example, supplies these objects and properties to the UMA-based application 225 if required.

4 shows a flow diagram of an exemplary method of object / characteristic interface 280 for implementing object semantics. At 410, object / property interface 280 opens a transaction with transaction manager 285. For each change to the model, the transaction is opened for deletion if the change is considered invalid. At 415, object / characteristic interface 280 communicates with the object itself. Every object knows its type, so it can determine its type. At 420, object / property interface 280 obtains completed supertype path for each object from metamodel 210, for example in order of up and down. At 425, a first object type (best supertype) is obtained by object / property interface 280 from the metamodel. At 430, the object / characteristic interface 280 obtains a semantic list for the object type from the object semantics register 220. At 435, object / characteristic interface 280 communicates with semantic register 220 to determine if there are more semantics in the list. If so, the object / characteristic interface 280 obtains the following semantics at 455 and implements at 460. At 465, object / property interface 280 determines whether its semantics failed. If so, at 470, the transaction is rolled back by transaction manager 285 upon the request of object / characteristic interface 280. However, if the semantics did not fail, at 435, object / characteristic interface 280 will again determine whether there are more semantics in the list.

At 440, if there are no more semantics in the list, the object / characteristic interface 280 will communicate with the metamodel and determine whether there are more object types in the parent path. If not, at 450, the transaction is closed. If there are more object types in the higher path, then at 445 the next object type is obtained, and the object / property interface 280 again proceeds to 430 if a semantic list for the object type is obtained from the object semantics register.

5 shows a flowchart of an exemplary method of object / characteristic interface 280 that implements characteristic semantics. At 510, object / property interface 280 opens a transaction with transaction manager 285. At 515, object / property interface 280 communicates with the object to determine the object type. At 520, object / property interface 280 obtains the completed supertype path for each object from metamodel 210, for example, in order of up and down. At 525, the first object type (best supertype) is obtained by the object / property interface 280 from the metamodel. At 527, object / property interface 280 constructs an object / property pair for the object type and the property type. At 530, object / property interface 280 obtains a semantic list for the object / characteristic type from property semantic register 530.

At 535, object / property interface 280 determines if there is more semantics in the list. If so, the object / characteristic interface 280 obtains the next semantics at 560 and implements the next semantics at 560. At 565, object / property interface 280 determines whether the semantics failed, and at 570, the transaction is rolled back. However, if the semantics did not fail, at 435, object / characteristic interface 280 will return to 535 to determine whether there are more semantics in the list.

At 540, if there are no more semantics in the list, the object / characteristic interface 280 will communicate with the metamodel and determine whether there are more object types in the parent path. If not, at 550, the transaction is closed. If there are more object types in the parent path, then at 545, the next object type is obtained, and the object / property interface 280 again proceeds to 527 when constructing an object / property pair for the object type and the property type. .

In an exemplary embodiment of the invention, the object / property model 290 includes a predetermined set of predefined objects and properties. The predefined set of objects and properties can be supplied by the UMA developer, for example, to reduce the amount of work required by the product developer. The object / property model 290 also receives objects and properties from the object / property interface 280. Objects and properties received from the object / property interface are based on the external definition of metadata supplied by the developer. Included in the object / property model 290 are the objects and properties required by the developer to be created and modified. The object / property model 290 also logs model changes to the transaction manager 285 via the object / property interface 280. However, in the exemplary embodiment of the present invention, the objects and properties of the object / property model 290 that are the result of the failed action are removed from the object / property model 290.

Thus, in an exemplary embodiment of the present invention, the objects and properties supplied by the developer and remaining within the object / property model 290 are the objects and properties obtained from the successful act. Thus, the developer may not directly access or change the object / property model 290. As a result, changes in the model are recognized by the modeling engine, and a consistent and valid state can be guaranteed at any time. If the developer has accessed the underlying data structure directly, improper changes can be made and thus an invalid state can be generated.

Transaction manager 285 puts the individual objects and properties into the state they were in before they were changed by the failed action. For example, transaction manager 285 is supplied with an indication that object / characteristic interface 280 has failed certain actions. All failing actions are not performed or erased. Transaction manager 285, for example, logs changes to object / property model 290 to log file 295, obtains non-executive data from log file 295, and is used by object / property interface 280. This can be accomplished by performing a non-executive action based on the success or failure of the action within the determined transaction. Thus, object / property model 285 remains valid. In addition, in an exemplary embodiment of the invention, transaction manager 285 may receive certain requests to undo or redo actions from UMA-based application 225. If some redo is required, transaction manager 285 may request redo information from log file 295 and perform the redo operation in a known manner.

In an exemplary embodiment of the present invention, the UMA 200 may further include an internal service component and an external service component. The internal service component may include a service or a function that can be exposed to the developer to support a problem in the generation and manipulation of the model, for example, to solve the problem area of the developer. In an exemplary embodiment of the present invention, internal services may include those services or functions shown in Appendix 1 attached herein.

The external service interface is an interface that allows an external service to communicate with the UMA 200. The external service interface can be, for example, an object that connects and implements an add-in application program interface that allows a third party module to extend the modeling capabilities of the tool, and thus functions such as being automatically customized. You can extend the modeling environment and modeling rules to include. Accordingly, the developer may access a service outside the service inside the UMA 200. The external service may be, for example, a module for creating an integrated nomenclature criteria for all names entered by the user. In addition, the UMA 200 may be reduced and enlarged as a user interface such as the UMA-based application 225 is separated from the semantic unit 230.

6 illustrates an exemplary embodiment of a method for manufacturing the modeling tool of the present invention. At 610, the object / property model 290 is constructed by defining a first set of classes for objects and properties supplied by the developer as metadata. In an exemplary embodiment of the invention, the object / property model 290 may include a predefined set of one or more objects and features. An object provides a storage mechanism for a property, which property applies to that storage mechanism. In an exemplary embodiment of the invention, the interface class for the object may be, for example, UMEObjectI. The property can be configured as a base class that the programmer needs to subclass. In an exemplary embodiment of the invention, the base class can provide administrative services without data storage. In an exemplary embodiment of the invention, a developer may provide a subclass that declares a data element and a method for creating access.

At 620, the metamodel 210 is configured by, for example, defining a second set of classes. The second set of classes is designated to maintain descriptions of properties, objects, and semantics. For example, in an exemplary embodiment of the present invention, two semantic interface classes are specified. The first semantic interface class, such as UMEObjectSemanticI, is an interface to any semantics that affects the creation or destruction of a given object. Further, the second semantic interface class, such as UMEPropertySemanticI, is an interface to any semantics that affects the creation, destruction or modification of certain properties. In an exemplary embodiment of the invention, the implementation of the representation of the metamodel 210 includes a proprietary object that exposes a static method for registering metadata and semantics.

Modeling rules, such as semantics 230, are supplied by the developer as a predefined set of semantics at 640 in the semantics register 220 of metamodel 210 and / or at startup or at any time thereafter, for example. It can be integrated as an additional set of semantics. In order to integrate modeling rules into the metamodel 210 for a given object, the developer may call appropriate calls, e.g., UMEObjectSemanticI for modeling rules for a given object and UMEPropertySemanticI for modeling rules for a given property. Subclass into subclasses. In addition, the developer can implement the first method to perform the desired action and to check the object / property model 290. A value indicating whether the operation was successful will be returned. For example, a return value of TRUE indicates that the operation was successful, and a return value of FALSE would indicate that the operation was not successful or the model was in an invalid state. In addition, to call the semantic unit 230, the metamodel 210 may include an access point (eg, an object / characteristic model transformation point). Various model transformation points (eg, CreatObject) will call the individual semantics of the appropriate points. If a certain indication, such as FALSE, is received among those implementing one or more semantics that failed to successfully complete, the operation may eventually stop.

At 630, the type code is associated with a first set of classes and a second set of classes. The type code is a unique identifier that specifies which type of metadata is being represented. Each item indicated in the metamodel, i.e., both the object and the property, will have a unique type code. In an exemplary embodiment of the invention, UMA 200 includes a variable type, TypeCode_t, which is declared to maintain a type code. The predefined set of semantics is supplied to the semantics register 220 of the metamodel 210 at 640.

At 650, a plurality of independent jobs, for example as shown in Table 1, are recognized. The separate tasks represent occurrences in which the object / characteristic model 290 can be modified. In an exemplary embodiment of the invention, each independent task is assigned a constant that represents it, and a variable type, such as Event_t, is declared to hold the event constants.

At 660, object / property interface 280 is executed. The object / property interface 280 includes, for example, preventing a developer from directly accessing the object / property model 290 and limiting the number of code paths for which the developer can transform the object / property model 290; have. For example, if a developer wishes to destroy a given object in the object / property model 290, a request must be made to the object / property interface 280, such as UMEObjectI: DestroyObject in the list in Appendix 1. .

7 illustrates an example embodiment of an object / characteristic interface 280 that executes a DestroyObject request. As shown in FIG. 7, access to the object / property model 290 is limited by the object / property interface 280 that handles DestroyObject requests. For example, at 710, object / property interface 280 communicates with transaction manager 285 to open a transaction when receiving a request, destroying the object (eg, the DestroyObject function). At 715, object / property interface 280 communicates with object / property model 290 to find the object that is required to be destroyed. At 720, object / characteristic interface 280 determines whether the object was found. If not found, at 725, transaction manager 285 rolls back the transaction in response to a request by object / characteristic interface 280, and at 730, the transaction manager sends a failure code back to the calling module, such as the user interface. . However, if an object is found, at 735, object / property interface 280 supplies object destruction information to transaction manager 285, and transaction manager 285 logs the object destruction in transaction log 295.

At 740, object / property interface 280 implements PreOwnerDestruction Semantics for all properties of an individual object. At 745, the object / characteristic interface 280 determines whether all semantics succeeded. Otherwise, at 725, transaction manager 285 rolls back the transaction in response to a request by object / characteristic interface 280, and transaction manager 285 returns a failure code to the call module.

If all PreOwner Destruction Semantics succeeded, then at 750, object / property interface 280 implements PreDestruction Semantics. At 755, object / property interface 280 determines whether all PreDestruction Semantics have succeeded. If successful, the object is destroyed at 760, and at 765, the object / property interface 280 contacts transaction manager 285 to terminate the transaction, and at 770, 730, transaction manager 285 returns a success code. Send it back to the call module. However, if PreDestruction Semantics failed, then at 725, transaction manager 285 rolls back the transaction in response to a request from object / property interfaces 280 and 730, and transaction manager 285 returns the failure code to the call module. .

To limit the construction and destruction of objects, for example, object constructors and object destroyers are protected so that developers cannot demonstrate or destroy objects directly. In order to limit the creation, destruction and modification of a characteristic, for example, the data members of the characteristic are done individually. In an exemplary embodiment of the invention, UMA 200 includes a class called an accessor that includes an interface class, such as UMEAccessorI. The accessor interface class is the equivalent class for the property, and it is through the accessor that access is granted to data members. The accessor is supplied with a data value and a command (eg, "set that value" or "delete the characteristic"), and the accessor is injected into the characteristics. Accessors perform their actions and return code indicating success or failure. An accessor is constructed by requesting one to be supplied to a characteristic. This makes it possible to construct an accessor capable of handling the data type of the characteristic. All operations on properties are configured through accessors, so any code required by semantics can be in the provided accessor base class. The developer subclass class accessor will simply supply a data element and a way to read and write it. The method is supplied with respect to an accessor base class that can allow binding to properties.

As shown in FIG. 6, at 670, a transaction manager 285 is performed. The transaction manager 285 manages the actions of the transaction, and if those actions fail, those actions are inactivated or erased. By starting the transaction at the beginning of the model manipulation and then monitoring the error state of various semantics, transaction manager 285 keeps object / characteristic model 290 valid. In an exemplary embodiment of the invention, transaction manager 285 records an accurate image of object / property model 290 prior to implementing the change based on the behavior. If the action succeeds, the individual change is not changed. If a failure occurs, transaction manager 285 re-memorizes the past image. Transaction manager 285 may incrementally preserve the image as the model changes.

As an example, in a single transaction the user creates an object and sets its name. Upon successful creation of an object, the fact that the object was created and the handling for that object are stored in transaction log 295. Then, if the user sets the name of the object for "Customer", the generation of the property is rewritten and the past value (none) is stored in the log. Subsequently, when the user sets the name to "Cust" again, the past value ("Customer") is stored in the log. If all succeeds, an object named "Cust" remains. However, upon failure, transaction manager 285 will begin rollback. That is, firstly, the name is changed from "Cust" to "Customer", secondly, all the existence of the name property is deleted, and finally, the object is deleted. As such, the object / property model 290 is re-memorized to the state it was in before the execution of the failed transaction.

In an exemplary embodiment of the invention, the objects and properties that changed as a result of the action are supplied to the object / property model 290 by the object / property interface 280. If the semantics associated with the action fail, the object / property interface 280 notifies the transaction manager 285 not to execute the action. As a result, the object / property model 290 is again in a state prior to the changed objects and properties that are being supplied from the object / property interface 280 to the object / property model 290 as a result of the failed behavior.

Since the above-described embodiments are illustrative examples of the present invention, the present invention should not be construed as being limited to these specific embodiments. Various modifications and variations can be made to those skilled in the art without departing from the spirit or scope of the invention as defined in the claims.

Appendix

Claims (16)

A metamodel including a semantic registry and a metadata manager, Object / property interface, An object / property builder register coupled to the metamodel and the object / property interface; And an object / property model coupled to the object / property interface. 10. The apparatus of claim 1, further comprising a transaction manager coupled to the object / property interface to disable the act of invalidating the object / property model. The apparatus of claim 1, wherein the semantic register of the metamodel includes at least a predefined set of semantics. The apparatus of claim 1, wherein the semantic register of the metamodel includes at least one set of semantics supplied by a developer. The modeling of claim 1, wherein the object / property builder register of the metamodel includes at least one object builder for generating an example of an object and one property builder for generating an example of a property. Tool making device. The apparatus of claim 1, wherein the object / property model comprises a predefined set of at least one of a plurality of objects and a plurality of properties. The apparatus of claim 1, wherein the object / property model includes examples of objects and properties based on an external definition of the metamodel. 3. The apparatus of claim 2, further comprising a log file coupled to the transaction manager object / property interface. The apparatus of claim 1, wherein the object / property interface restricts access to the object / property model. Constructing an object / property model by defining a first set of classes, Constructing a metamodel by defining a second set of classes, Associating a type code with the first set of classes and the second set of classes; Supplying a predefined set of semantics to the metamodel, Recognizing the plurality of independent tasks when at least one of the semantics of the set is called at each occurrence of the plurality of independent tasks; Supplying an object / characteristic interface for restricting access to the object / characteristic model. 11. The method of claim 10, further comprising providing a transaction manager to not execute the act of invalidating the object / property model. The method of claim 10 wherein the object / property model comprises a predefined set of at least one of the plurality of objects and the plurality of properties. The method of claim 10 wherein the object / property model includes examples of objects and properties based on an external definition of the metamodel supplied by the developer. The method of claim 10, wherein the metamodel includes at least one set of semantics supplied by the developer. A first model comprising a register and a data manager, Interface, A builder register coupled to the first model and the interface; A second model coupled to the interface, And the register includes semantics. Constructing a first model by defining a first set of classes, Constructing a second model by defining a second set of classes, Associating a type code with the first set of classes and the second set of classes; Supplying a first set of semantics to the first model, Recognizing the plurality of independent tasks when at least one of the semantics of the set is called at each occurrence of the plurality of independent tasks; Supplying an interface for restricting access to the first model.