[go: up one dir, main page]

WO1997033243A1 - Systeme de gestion de cas et methode pour gerer des modeles de cas de systemes physiques - Google Patents

Systeme de gestion de cas et methode pour gerer des modeles de cas de systemes physiques Download PDF

Info

Publication number
WO1997033243A1
WO1997033243A1 PCT/US1997/003473 US9703473W WO9733243A1 WO 1997033243 A1 WO1997033243 A1 WO 1997033243A1 US 9703473 W US9703473 W US 9703473W WO 9733243 A1 WO9733243 A1 WO 9733243A1
Authority
WO
WIPO (PCT)
Prior art keywords
case
cases
instructions
created
base data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US1997/003473
Other languages
English (en)
Inventor
W. Scott Barton
Craig Andrews
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
HP Enterprise Services LLC
Original Assignee
Electronic Data Systems LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Electronic Data Systems LLC filed Critical Electronic Data Systems LLC
Priority to AU25272/97A priority Critical patent/AU2527297A/en
Publication of WO1997033243A1 publication Critical patent/WO1997033243A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation

Definitions

  • the present invention relates to management software and, more particularly, to a software system and method for managing computer software models of physical systems.
  • Simulation modeling provides a tool to predict system operation, cost, and performance.
  • Many highly complex physical systems use computer software programs to accomplish this modeling.
  • Systems for modeling the operation of a physical system differ, but typically the models require input of information from a base set of data. Typically this data defines the variables, assumptions, and other data that the physical system uses and produces. From the base set of data, a user can run a model to predict performance, cost, and other characteristics of the system in operation based on the variables in the base data. A user can then create different models of the system by altering variables in the base data and re-running the modeling software to create different case scenarios. Each model of the system results in a case. In addition to running different models, users of these modeling systems often need to manipulate the different cases by, for example, storing the cases modeled, comparing the cases, and retrieving past cases.
  • a case management system allows a user of such a modeling system to manage these individual cases and maintain a record of the various models and the associated results, such as performance and cost, of each case modeled.
  • Most physical systems have mechanisms built into them to allow an operator to change one or more of the variables m the system to try to improve performance or adjust to a change of other operating conditions.
  • An effective case management system will allow a user of a modeling system to make changes to the source or base data in order to simulate a change in the operating conditions of the physical system.
  • This technique of changing variables in the base data presents problems in a typical database-type modeling system.
  • One problem involves how to make changes to the base data for the case a user wants to model without affecting other cases made in the past, or cases made in the future. While a user could make a change to a variable directly to the base data, this change would affect all other users of the system because all cases run in the future must run with the changed variable. This change may also change the stored results of past cases modeled. Other users of the modeling system may not want to make that particular change to the base data. In fact, other users might decide to change a different variable altogether. Thus, making changes directly to the base data can lead to control problems. When a user changes the base data, problems can arise with traceability of those changes.
  • a tracking system does not exist to alert a future user of the modeling system, a user might run a case without realizing a change to the base data has occurred and make decisions based on a different set of variables than the user anticipated. Thus, making changes directly to the base data can also lead to traceability problems. In order to avoid this problem, many modeling systems prevent users from changing the base data.
  • Typical case management systems also do not provide for a hierarchy of base data assumptions where a user can have a particular set of assumptions that others can use and modify without affecting the original user's set of assumptions. For example, a user may want to use the set of variables another user has established, but make a change to one or more variables, while not changing the original set of variables borrowed from the other user.
  • Typical management systems do not allow a first user to let other users of the modeling system access the first user's case models while, at the same time, protecting some or all of the first user's variables from being changed by those other users. Another problem with current case management systems lies in the security associated with the cases.
  • the present invention provides a case management system and method that substantially eliminate or reduce disadvantages and problems associated with previously developed case management systems and methods.
  • a case management system and method that manage software case models that simulate operations of systems.
  • Software cases are created by a user having access to a base data set that contains variables.
  • the case manager software receives input from users to create cases that contain data from the base data set.
  • the case manager software also creates cases directly from the base data set without the need to copy the base data for each created case.
  • the case manager software also possesses the ability to receive input from users to create cases that allow the users to change variables in the base data and create cases.
  • the created cases may contain a combination of unchanged variables from the base data, as well as changed variables from the base data set, without there being the need to alter the variables within the base data for future case creation.
  • the present invention includes an important technical advantage of allowing the modeling system user who accesses a base data set to change the data in the base data set. Without copying a complete set of base data and without duplicating, the user may change the base data set to model "what-if" physical system scenarios without affecting the base data set for any other cases.
  • the present invention allows a user to change a variable within the base data and run a case model, while the base data or base assumptions that all users have access to remains unchanged.
  • the present invention provides another technical advantage by allowing a user to run a case model and then to "promote" the variables of that case model into the base data.
  • the present invention allows a user to run a case with variables different from the base data, and then modify the base data to agree with the data used in that particular case by promoting the case data to the base data.
  • the present invention can incorporate a security system that defines which users can promote variables to base and which variables can or cannot be changed in the base data.
  • Yet another technical advantage of the present invention is the ability to limit the shareability of the base data.
  • the present invention has a feature that can limit or expand access to the base data to individual users. This results in some users having a different view of base, but all users have access to the same case modeling and case management capabilities.
  • Still another technical advantage of the present invention lies in the ability to share cases. If a user makes a change to the base data and runs a case, other users can access that case and run other cases using that data.
  • the user can determine the level of security appropriate to the changes.
  • the user can designate the security level for the changes.
  • Other users cannot see or modify private assumptions.
  • Others sharing the case can see, but cannot change, the read ⁇ only public assumptions.
  • Writable public assumptions can be seen and modified by other users.
  • the present invention provides another technical advantage with regard to traceability of changes to base.
  • the present invention tracks case model changes so that the case variables that change and how those variables differ from the base variables can be determined.
  • FIGURE 1 depicts lines of communication for use in one embodiment of the present invention
  • FIGURE 2 illustrates a block diagram of one embodiment of the case manager of the present invention
  • FIGURE 3 provides a block diagram of one embodiment of the create case operation of the present invention
  • FIGURE 4 shows a block diagram of one embodiment of the select case operation of the present invention
  • FIGURE 5 is a block diagram of one embodiment of the remove case operation of the present invention
  • FIGURE 6 depicts a block diagram of one embodiment of the copy case operation of the present invention.
  • FIGURE 7 provides a block diagram of one embodiment of the move case operation of the present invention.
  • FIGURE 8 renders a block diagram of one embodiment of the compress case operation of the present invention.
  • FIGURE 9 shows a block diagram of one embodiment of the compare case operation of the present invention
  • FIGURE 10 gives a block diagram of one embodiment of the promote case operation of the present invention
  • FIGURE ll supplies a block diagram of one embodiment of the register change operation of the present invention.
  • FIGURES Preferred embodiments of the present invention are illustrated in the FIGURES in which like numerals being used to refer to like and corresponding parts of the various drawings.
  • One application of the case management system of the present invention involves managing object oriented simulation models of physical systems.
  • An example of a physical system modeled using object-oriented software may be a model for power system operations.
  • simulating the power system includes building an object model of the power system.
  • objects may model concrete things (e.g., people and computers), as well as abstract concepts, (e.g., numbers or geometrical concepts) .
  • the present invention can be utilized to manage these cases.
  • the case management system of the present invention uses object oriented software objects in one implementation.
  • the software objects of the present invention have been written in Small Talk, but could also be written in other software code languages including an object oriented code language such as C++ .
  • FIGURE 1 shows object model diagram 12 of the interaction of case manager object 10 with user 11 and base data set 13.
  • Base data set 13 includes assumptions and/or variables.
  • Base data set 13 includes a case context 15 and a persistent collection 1 .
  • user 11 interacts with case manager object 10 in some fashion that can include requesting certain functions or operations. The functions and operations case manager object 10 performs are discussed below in more detail.
  • User 11 also has the option to modify base data set 13.
  • Case manager object 10 either registers or retrieves case context 15 from persistent collection 14.
  • Case context object 15 represents a specific case node created from base data set 13 that a user is manipulating.
  • Persistent collection 14 represents a collection of software object cases created from base data set 13.
  • Base data set 13 includes variables, assumptions, and other data available to all users 11.
  • Base data set 13 can be controlled by a system administrator who defines the rules and access capabilities for any user 11. Subject to those rules, user 11 can make copies of base data set 13 for building particular models of the system.
  • FIGURE 2 shows case manager object 10 that includes application result object 22, case context 15 object, and case dictionary object 24 that further includes case node object 20, case change object 26 and audit log object 28.
  • the case context object described above is retrieved from case dictionary 24.
  • the application result object 22 represents the results from running a particular case model from a particular case context 15.
  • Case dictionary object 24 stores all cases, or case node objects 20 created by user 11.
  • Case change object 26 stores any changes made to case node 26.
  • audit log object 28 creates an audit trail of changes made to case node objects 20.
  • FIGURE 2 represents FUSION notation as described in numerous texts, such as D. Coleman, Ob-iect-Oriented Development of Fusion Methods (1994) .
  • a box denotes an object, usually a software object, and a line connecting objects represents a functional relationship between those objects.
  • a plus (+) , asterisk (*) , or a specific numeral (1, 2, 3, . . .) notation above the line represents the number of instances of that object.
  • a plus indicates one or more instances of the connected object within that object, an asterisk represents zero or more instances of the connected object within that object, and a numeral represents that number of instances of the connected object within that object.
  • case dictionary 24 can have one or more case node objects 20.
  • Case node object 20 can either be created from base data set 13, or created from the data in an existing case node object 20.
  • case node object 20 created from an existing case node object 20 can only have one case node object 20 as its source (source of data) , but it can have many descendants that are created case node objects 20.
  • case node object 20 can only have one parent, but can have as many children as users 11 decide to create.
  • Each case node object 20 can have zero or more case changes.
  • each case node 26 can log all of these changes, and thus, can log zero or more audit entries. Audit log object 28 thereby creates a chain of changes associated with each case node 26. This chain allows case manager object 10 to track the evolution of all case node objects 20.
  • case manager object 10 The life cycle of case manager object 10 involves interacting with other objects, registering changes to case objects, and retrieving case objects. To interact with other objects, case manager object 10 must first create case node object 20. Case manager object 10 can then perform other interactions with objects including selecting, releasing, removing, copying, compressing, comparing, and promoting a case. Once the user creates a case, user 11 has the option to perform any of the other interactions as many times as user 11 chooses.
  • FIGURE 3 shows an object model diagram of the create case operation 30 that creates new case node object 20 from source data contained in either base data set 13 or an existing case node object 20.
  • Create case operation 30 includes interaction between case manager object 10, case dictionary object 24, a new case node object 20 and audit entry object 28.
  • user 11 sends create case message 19 to create case node object 20 from case manager object 10.
  • the data input from message 19, preferably includes the case name, case description and case source (the hierarchy parent) .
  • Case manager object 10 assumes that the case name supplied is unique and occupies a unique name space. Case manager object 10 will modify case dictionary 24 to add new case node object 20 into source case dictionary 24 after new case node object 20 has been created. Case dictionary object 24 then creates new case node object 20 based on the input from operation 19 and creates an audit entry object to modify audit log object 28. Audit log object 28 modifies itself based on the information sent by case node object 20. Case manager object 10 then adds new case node object 20 to case dictionary 24 and returns a true if the operation of adding new case node object 20 is successful or a false if the operation is unsuccessful.
  • FIGURE 4 shows an object model diagram of select case operation 40 that selects existing case node object 20, in either read or write mode, from case dictionary 24.
  • Select case operation 40 includes interaction between case manager object 10, case dictionary object 24, a consistent collection of case nodes 14 and case context object 15.
  • user 11 sends select case message 19 to case manager object 10.
  • the data input from message 19 includes the case name and the case access mode (read or write) .
  • Case manager object 10 assumes that the case name exists among existing case nodes object 20.
  • Case manager object 10 will select requested case node object 20 from case dictionary 24 if case node object 20 is available for the requested access mode of read or write. Case node object 20 determines its access status mode of either read or write. Case dictionary 24 then creates new case context 15 and populates the newly created case context 15 with selected case node object 20. Case manager object 10 then returns case context 15 to the user and returns a true if the operation of selecting new case node object 20 is successful or a false if the operation is unsuccessful.
  • FIGURE 5 shows an object model diagram of remove case operation 50 that removes an existing case node object 20 from case dictionary 24.
  • the remove case operation deletes a case node from a case dictionary if case node object 20 is an end case (no dependents) and if the user possesses the appropriate authorizations to do this type of operation.
  • Select case operation 40 includes interaction between case manager object 10, case dictionary object 24, a persistent collection of case nodes object 14 and audit object 15. To remove a case, user 11 sends remove case message
  • FIGURE 6 shows an object model diagram of the copy case operation 60 that copies existing case node object
  • the copy case operation copies the case node plus all data associated with that case node. This function allows a user to copy cases from other users to which the user may then make changes and run new cases. These changes to the copied case will not affect the original case in any way.
  • Copy case operation 40 includes interaction between case manager object 10, case dictionary object 24, a persistent collection of case nodes 14 and audit log object 28.
  • user 11 sends copy case message 19 to case manager object 10.
  • the data input from message 19 includes the case name and the case destination.
  • Case manager object 10 finds requested case node object 20 in case dictionary 24.
  • Case manager object 10 will then create new case node object 20 and copy the information from requested case node object 20 into the new case node object 20.
  • Case dictionary 24 then creates a new audit entry to record the case node copy event and the audit log object 28 modifies itself based on this information.
  • Case manager object 10 then returns a true if the operation of copying case node object 20 is successful or a false if the operation is unsuccessful.
  • FIGURE 7 shows an object model diagram of the move case operation 70 that moves existing case node object 20 to new case node object 20.
  • the move case operation replaces an existing destination case node with a target case node.
  • Move case operation 70 includes interaction between case manager object 10, case dictionary object 24, a persistent collection of case nodes 14 and audit log object 28.
  • To move a case user 11 sends move case message 19 to case manager object 10.
  • the data input from move case message 19 includes the case name and the case destination.
  • Case manager object 10 assumes that the target case name and the destination case name exist among existing case node objects 20. Case manager object 10 finds target case node object 20 from the persistent collection of cases 14 within case dictionary 24. Case manager object 10 then removes target case node 20 from current source node 20 list of descendants, replaces the name of target case node 20 with the name of destination case node object 20, and add target case node 20 to the descendant list of the source node that includes that descendant name. Case dictionary 24 then creates a new audit entry to record the move case event, and the audit log object 28 modifies itself based on this information. Case manager object 10 then returns a true if the operation of moving case node object 20 is successful or a false if the operation is unsuccessful.
  • FIGURE 8 shows an object model diagram of the compress case operation 80 that compresses an existing set of dependent cases into the end case in the string of dependent case node objects 20.
  • the compress case operation consolidates the changes made to case node object 20 at some point in the hierarchy to a different point upward in the hierarchy.
  • the compress case allows a user to incorporate any selected number of changes to a case into a new case.
  • Compress case operation 80 includes interaction between (a) case manager object 10, (b) case dictionary object 24, (c) a collection of case nodes 14, and (d) audit log object 28.
  • To compress a case user 11 sends compress case message 19 to case manager object 10.
  • the data input from compress case message 19 includes the begin case name, the end case name, and the compress case name.
  • Case manager object 10 assumes that the begin case name and the end case name exist among existing case node objects 20, and that the compress case name is unique among existing cases and does not currently exist. Case manager object 10 will find begin case node object 20 from the persistent collection of cases 14 within the case dictionary 24. Case manager object 10 then follows the inheritance path, defined by the nodes descending from begin case node object 20, to end case node object 20 specified in compress case message 19. Case manager object 10 then consolidates the changes made throughout the inheritance path and replace the state of end case node object 20 with the consolidated changes. Case manager object 10 will then remove the case nodes in the inheritance path. Case dictionary 24 then creates a new audit entry to record the compress case event and audit log object 28 modifies itself based on this information. Case manager object 10 then returns a true if the operation of compressing case node object 20 is successful or a false if the operation is unsuccessful.
  • the inheritance path is defined by the original case created from the base data and cases created in a direct chain from that original case.
  • an inheritance path contains an original case (created from base data or from base data with some variable modifications) and a case created from that original case, and a case created from the secondary case and so on until a case exists from which no other cases have been created.
  • the inheritance path follows singularly down the creation path so that there is only one case forming a link in the chain at every creation step. For example, if an original case created from base has two cases created from it, that means two inheritance paths now exist.
  • FIGURE 9 shows an object model diagram of the compare case operation 90 that allows a compare case object to access two or more case node objects 20 from within case dictionary 24 and compare the attributes of those two or more case node objects 20 with one another.
  • Compare case operation 90 includes interaction between case manager object 10, case dictionary object 24, a persistent collection of case nodes 14, and compare case object 90 to create compare report 92.
  • user 11 sends compare case message 19 to compare case object 90.
  • Compare case object 90 sends a compare case message to case manager object 10 informing the case manager of the source case name and the target case name.
  • Case manager object 10 assumes that the source case name and the target case name exist among existing case node objects 20.
  • Case manager object 10 finds source case node 20 and the target case node from the persistent collection of cases 14 within case dictionary 24. Case manager object 10 then provides the target case data and the source case data to compare case object 91 that then determines the differences between the two cases. Case manager object 10 creates compare report 92 into which the differences in the compared cases is recorded.
  • FIGURE 10 shows an object model diagram of the promote case operation 100 that promotes the variables in an existing case into base data set 13.
  • Promote case operation 100 includes interaction between case manager object 10, the case dictionary object 24, a persistent collection of case nodes 14 and an audit log object 28.
  • user 11 sends promote case message 19 to case manager object 10.
  • the data input from promote case message 19 includes the case name of the case to be promoted.
  • Case manager object 10 assumes that the promote case name exists among existing case node objects 20. 24
  • Case manager object 10 will find promote case node object 20 from the persistent collection of cases 14 within case dictionary 24. Case manager object 10 then promotes the changes associated with case node object 20 into the base data set 13. This process involves identifying all changes that have occurred in case node object 20 and changing any base variables/assumptions/data that have been changed. Case dictionary 24 then creates a new audit entry to record the promote case event and the audit log object 28 modifies itself based on this information. Case manager object 10 then returns a true if the operation of promoting case node object 20 is successful or a false if the operation is unsuccessful. Promote case operation 100 allows a user to impose the changes in the data made to create a particular case (including any changes along the cases inheritance path) onto the base data. Thus, the base data for every user from this point forward will have the promoted data. This does not affect previously built cases, but works prospectively to affect all future cases. A security system can establish which users can promote changes and what variables these users can actually change.
  • FIGURE 11 shows an object model diagram of register change operation 110 that registers the variable changes made to existing case node object 20.
  • Case manager object 10 makes a change to case node object 20, each case node object 20 performs register change operation 110 and informs audit object log 28. Audit log object 28 then logs the change to case node object 20.
  • Case manager object 10 then returns a true if the operation of registering case node object 20 is successful or a false if the operation is unsuccessful.
  • the case management system and method of the present invention supports numerous cases where a case can represent a particular computer model of a physical system.
  • the modeling of the physical system begins based on a base data set including variables, assumptions, and other data. All users have access to the base data.
  • the system administrator can limit the amount of access of certain users to case management system objects and the associated base data. For example, the systems administrator can give user A unlimited access to the entire base when modeling cases, but can restrict user B from access to one or more specific variables or assumptions in the base.
  • each user case regardless of the amount of access the user has to the base data, inherits the same capabilities as every other case.
  • the present invention allows a user to specify a set of changes to the base model state that represents the system at some reference point in time to create a case representing a different model of the system.
  • a user can make any number of changes to the base data that the user can access.
  • the case management system allows a user to perform "what-if" analysis by creating a study case from the base model state (root case) or create a study case from an existing case (branch or leaf case) .
  • the case management system records and tracks the changes made to the base data in subsequent cases in a case dictionary that represents a repository for all changes associated with the case inheritance chain.
  • the net state of a case is determined by applying the ordered set of changes from the root case to the case along the case inheritance path.
  • the case manager also provides controlled multi-user access to the individual cases. Only one user can create a case (each case may be write protected) , but an unlimited number of users can read a case. Each user can then modify the model state represented by the case independent of any other users without affecting the case from which the modified case was built. If a user modifies a case that already has dependent cases built from it, the case manager object notifies the dependent cases that changes have been made. Modifications to a case may be made even when a dependent case is currently in use. The case manager will notify the users of the cases affected that the results of simulations based on those modified case nodes are now invalid. Thus, the case nodes have inherited the changes and the previous results from those cases in their previous form are now invalid.
  • the user can access audit log object 28 to determine what changes to the case nodes have occurred.
  • Each case created either from the base data or from the data in existing cases, gets added to the case dictionary that stores the created cases.
  • Each case that gets created from a parent (existing) case become a part of the inheritance path of that case.
  • an inheritance path includes the original case created from base data, the case created from that original case, the case created from the second case, and so on until no other cases have been created in that chain.
  • the case manager also allows a user to consolidate all changes into a destination case by compressing the case tree structure into a single case to capture all the changes to base that have occurred on a particular inheritance path.
  • the case manager further allows a user to compare two cases or a case to its base model state and report the differences.
  • a user can also select all or some of the data from a particular case to be promoted to the base data.
  • the case manager also maintains an audit trail of all modifications made to the case.
  • the audit object logs interactions with a case to include what was changed, when it was changed and who changed it.
  • the case manager allows a user to view the change events made (the audit trail) of any case.
  • the audit trail that belongs to the root or original case will be removed from the system upon deletion of the case root and all its dependents.
  • the case manager allows a user to store and retrieve a case.
  • the case manager also stores output result objects containing the study outcomes of application models.
  • the case manager will store the simulation model results based on case information for every case model that gets run as a simulation.
  • a user may also delete a study case if the study case has no dependent cases.
  • the present invention prevents deletion of a case with dependents to avoid deleting the dependent cases. By preventing cascade deletes, the case manager ensures that dependent cases built off of existing cases are not lost.
  • the case management system can be written in SmallTalk object oriented code.
  • the management of cases allows the user to create cases, each case representing one model of a system, from a set of base data/assumptions/variables. Each case can be modified by the user.
  • the present invention allows other users to see cases (results for a particular modeling of the system) .
  • Case management also allows other users to change public (non-private) variables/data/assumptions to get a different model of the system and store that case in the case management system.
  • a user can also change the base assumptions by "promoting" the changes from a particular case to the base data.
  • the present invention provides a case management system and method for managing case models of physical systems that allows a user to create cases with changed base variables without copying the entire base and without altering the base data for future.
  • the case manager software receives input from users to create cases containing data from the base data.
  • the case manager software also creates cases directly from the base data without copying the base data for each case created.
  • the case manager software can also receive input from users to create cases that allows the users to change variables in the base data and creation of cases containing a combination of unchanged variables from the base data and changed variables from the base data without altering the variables within the base data for future case creation and without copying the entire base each time a case needs to be created with changed variables.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Système logiciel de gestion de cas et méthode pour gérer des cas (20) représentant des modèles d'un système d'exploitation, dans lequel les cas (20) sont créés par un utilisateur (11) qui a accès à un ensemble de données de base contenant des variables. L'objet (10) du gestionnaire de cas reçoit une entrée venant d'un utilisateur, de façon à créer des cas (20) qui contiennent des données tirées des données de base. L'objet (10) du gestionnaire de cas crée également des cas directement à partir de l'ensemble (13) de données de base, sans copier ces dernières pour chaque cas créé. Ledit objet (10) reçoit aussi une entrée provenant des utilisateurs (11), de façon à créer des cas (20) qui permettent aux utilisateurs (11) de changer les variables de l'ensemble de données de base (13) et de créer des cas contenant une combinaison de variables non modifiées et de variables modifiées tirées de l'ensemble de données de base (13), sans changer les variables contenues dans l'ensemble de données de base (13) en vue d'une future création de cas et sans copier la totalité de l'ensemble de données de base (13) chaque fois qu'il est nécessaire de créer un cas (20) avec des variables modifiées.
PCT/US1997/003473 1996-03-05 1997-03-04 Systeme de gestion de cas et methode pour gerer des modeles de cas de systemes physiques Ceased WO1997033243A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU25272/97A AU2527297A (en) 1996-03-05 1997-03-04 A case management system and method for managing case models of physical systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US61092496A 1996-03-05 1996-03-05
US08/610,924 1996-03-05

Publications (1)

Publication Number Publication Date
WO1997033243A1 true WO1997033243A1 (fr) 1997-09-12

Family

ID=24446953

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/003473 Ceased WO1997033243A1 (fr) 1996-03-05 1997-03-04 Systeme de gestion de cas et methode pour gerer des modeles de cas de systemes physiques

Country Status (2)

Country Link
AU (1) AU2527297A (fr)
WO (1) WO1997033243A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999052048A1 (fr) * 1998-04-03 1999-10-14 Schlumberger Evaluation & Production (Uk) Services Systeme de simulation comprenant un simulateur et un gestionnaire de cas conçu pour mettre sur pied des fichiers de donnees destines au simulateur selon une structure du type arborescent
EP0994429A1 (fr) * 1998-10-14 2000-04-19 ETP Software Limited Système de modélisation pour l'administration de projets

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
EGE R K: "database support for object oriented simulation", JOURNAL OF SYSTEMS ENGINEERING, vol. 3, no. 4, 1993, UK, pages 184 - 190, XP002035190 *
ROVIRA M ET AL: "THE CONCEPT OF VIEWS IN SIMULATION", PROCEEDINGS OF THE WINTER SIMULATION CONFERENCE, LOS ANGELES, DEC. 12 - 15, 1993, no. -, 12 December 1993 (1993-12-12), INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, pages 552 - 559, XP000479554 *
SAULNIER E T ET AL: "SIMULATION MODEL REUSABILITY", IEEE COMMUNICATIONS MAGAZINE, vol. 32, no. 3, 1 March 1994 (1994-03-01), pages 64 - 69, XP000442188 *
ZEIGLER B P ET AL: "MODEL BASE MANAGEMENT FOR MULTIFACETTED SYSTEMS", ACM TRANSACTIONS ON MODELING AND COMPUTER SIMULATION, vol. 1, no. 3, 1 July 1991 (1991-07-01), pages 195 - 218, XP000290594 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999052048A1 (fr) * 1998-04-03 1999-10-14 Schlumberger Evaluation & Production (Uk) Services Systeme de simulation comprenant un simulateur et un gestionnaire de cas conçu pour mettre sur pied des fichiers de donnees destines au simulateur selon une structure du type arborescent
US7561997B1 (en) 1998-04-03 2009-07-14 Schlumberger Technology Corporation Simulation system including a simulator and a case manager adapted for organizing data files for the simulator in a non-conventional tree like structure
EP0994429A1 (fr) * 1998-10-14 2000-04-19 ETP Software Limited Système de modélisation pour l'administration de projets

Also Published As

Publication number Publication date
AU2527297A (en) 1997-09-22

Similar Documents

Publication Publication Date Title
US7472122B2 (en) Computer system and method for managing file versions
US7539680B2 (en) Revision control for database of evolved design
JP2783109B2 (ja) データベースシステム退避装置及びデータベースシステム復元装置及びデータベースシステム移行装置
Østerbye Structural and cognitive problems in providing version control for hypertext
ES2290736T3 (es) Sistema y procedimiento de gestion de medios de copia de seguridad en un entorno informatico.
Schroeder et al. A caching file system for a programmer's workstation
US7979441B2 (en) Method of creating hierarchical indices for a distributed object system
US6094654A (en) Data management system for file and database management
US11294958B2 (en) Managing a distributed knowledge graph
US20150186445A1 (en) Mechanism for deprecating object oriented data
CN113835685B (zh) 一种基于拟态数据库的网络操作系统设计方法
CN101441563A (zh) 自动化用于信息服务的架构设计模型的创建的系统和方法
JPH0652531B2 (ja) リレーシヨナル・データベース管理システム
JPH10505440A (ja) プログラミング言語−具体的データファイルのｓｑｌベースの操作を可能にするコンピュータベースの情報アクセス方法および装置
US6941309B2 (en) Object integrated management system
CN102171694A (zh) 数据层应用程序组件结构管理
CA2533916A1 (fr) Systeme d'archivage represente a l'interieur d'une base de donnees
Wiil et al. Hyperform: A hypermedia system development environment
CN113407626B (zh) 一种基于区块链的规划管控方法、存储介质及终端设备
EP1091295B1 (fr) Système de gestion de données avec plusieurs modules d'exploitation de données
CN103841178B (zh) 网络附连存储环境的带内管理的方法和系统
Nestor Toward a persistent object base
WO1997033243A1 (fr) Systeme de gestion de cas et methode pour gerer des modeles de cas de systemes physiques
Aish Bentley systems
CN113722343A (zh) 一种多级中心环境下数据状态一致性管控方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CN CZ JP NZ PL

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 97531919

Format of ref document f/p: F

122 Ep: pct application non-entry in european phase