WO2001069402A1 - Dispositif de recompilation d'instructions produites par un systeme graphique - Google Patents

Dispositif de recompilation d'instructions produites par un systeme graphique Download PDF

Info

Publication number
WO2001069402A1
WO2001069402A1 PCT/US2001/001271 US0101271W WO0169402A1 WO 2001069402 A1 WO2001069402 A1 WO 2001069402A1 US 0101271 W US0101271 W US 0101271W WO 0169402 A1 WO0169402 A1 WO 0169402A1
Authority
WO
WIPO (PCT)
Prior art keywords
logic
graphical object
recited
application program
changed
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/US2001/001271
Other languages
English (en)
Inventor
Scott Posey
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.)
STAGECAST SOFTWARE Inc
Original Assignee
STAGECAST SOFTWARE Inc
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 STAGECAST SOFTWARE Inc filed Critical STAGECAST SOFTWARE Inc
Priority to AU2001227911A priority Critical patent/AU2001227911A1/en
Publication of WO2001069402A1 publication Critical patent/WO2001069402A1/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
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming

Definitions

  • This invention relates generally to computer programming, and more particularly to recompiling logic associated with an object upon changing the object in a graphics-based logic driven application program. .
  • An emerging technology is graphics-based programming, which permits such activities as drag and drop programming on a display.
  • the programming may be accomplished by demonstrating desired reactions of an object.
  • To create a program an object is moved from its current cell on the display to another cell using a mouse. This movement automatically creates code including a rule of movement for the graphical object, which the object will follow to move independently from cell to cell across the display. The code remains transparent to the user.
  • Stagecast Creator developed by Stagecast Software, Inc. 580 College Avenue, Palo Alto, CA 94306.
  • the first stage of rule-matching is a pattern match between the rule's before board template and the current simulation.
  • the template consists of one or more objects 100 which must exist in the simulation in order for the rule to match.
  • the template also records the relative positions of these objects 100, and the areas they occupy.
  • the locations of the cells 102 occupied by a graphical object 100 is determined by its shape.
  • a graphical- rewrite rule (GRR) is said to match when the simulation contains all of the graphical objects 100 in the template and the objects in the simulation occupy the same areas as the graphical objects 100 in the template.
  • each rule is compiled into a series of matching-tests 104-107, where there is one test 104 for each cell 102, in the template.
  • a test 104 succeeds when the corresponding cell 102 in the simulation contains analogues of all the graphical objects that were in that cell 102 at the time the rule was created.
  • the rule matches when all of these tests 104-107 succeed.
  • any rules that use the graphical object 100 and were compiled into tests 104 before the shape changed will no longer match, because occurrences of the graphical object 100 in the simulation will have a different pattern of cells 102 than what is in the templates. For instance, if the object 100 in figure la is resized so that it occupies four cells as in figure lc, tests 105-107 will fail. Consequently, the program will no longer work and the user would have to manually rewrite every rule whose "before" part includes the graphical object whose shape changed.
  • Figure lc illustrates the graphical rewrite rule after the user has resized an object 100 and figure Id presents the recompiled tests 108-111 corresponding to the original tests 104-107.
  • Each node might contain data about a person, and the tree could be organized such that a left branch off of a node contains a record of a person whose last name is alphabetically before the node before it, and the right branch similarly contains the record of a person whose last name is alphabetically after it.
  • the search through such a tree for a particular person therefore consists of examining each node recursively, navigating to the next left or right node according to whether or not the target person's name is alphabetically before or after the current node.
  • the search terminates when there are no more nodes or when the node containing the record of the desired person is found.
  • Such algorithms are highly efficient for their application.
  • the invention addresses these issues by ensuring that all nodes present a common interface and that all searches utilize it.
  • the present invention overcomes the limitations of the prior art and allows modification of a graphical object by automatically recompiling some or all of the rules which make use of the object upon a change in the object. More particularly, logic is updated so that the rules throughout the simulation continue to operate as they did before the object was changed.
  • rule recompilation and a search mechanism for locating the rules which must be recompiled.
  • the search mechanism has a plug-in module which permits different kinds of searches to be performed. Automatic rule recompilation is accomplished by one such plug-in module. A similar plug-in module is used to count the number of rules which require recompilation.
  • DAG directed acyclic graph
  • the present invention recompiles a portion of the logic in a graphics-based logic driven application program.
  • the logic in the simulation containing the object is searched. As the logic associated with the graphical object is found, it is changed automatically.
  • the present invention searches through the rules in the simulation to identify the rules which make use of the object, and compiles their "before" portions with the modified shape.
  • the object may be changed manually by a user.
  • the change in the object may include a change in the object's size and/or shape.
  • a change in the size of the object could include causing the object to occupy more cells on the template or board.
  • the object may be edited in a manner similar to the way it would be edited in conventional paint programs.
  • an editing palette that allows the user to select an editing tool such as a paintbrush or an eraser using the input device could be generated and displayed.
  • Input devices include a keyboard, mouse, joystick, etc.
  • the recompilation of the logic may be carried out only upon receiving permission from a user.
  • One manner of obtaining permission from the user is through the display of a pop-up window which prompts the user for the permission.
  • An affirmation or negation of permission to make the change would then be received from the user based on a user interaction with the pop-up window.
  • the window displays a message such as "Do you wish to make the change to the graphical object? The change will require updating 23 rules" and two buttons, one affirmative and one negative. If the user chooses the affirmative button, such as by pointing to it with a mouse pointer and clicking a button on the mouse, recompilation of the logic is performed. If the user chooses the negative button, no recompilation of the logic is performed, and the change to the graphical object is cancelled.
  • the automatic recompilation of the logic is accomplished by clearing all objects from the "before" portion of a rule and then adding them back in. As a result, the changed object is restored to the "before" portion of the rule with its new shape.
  • the new logic replaces the old logic entirely. The new logic ensures that the object continues to function properly throughout the simulation. No user actions are required in this recompilation process.
  • the preferred searching architecture for locating the rules which make use of the changed object decomposes the search into two parts: an interface which is implemented by objects which contain rules, and an interface which is implemented by searching functions which examine them.
  • the searching architecture is described hereafter in Sun's Java programming language. Those skilled in the art will recognize that the searching architecture could be implemented in virtually any object-oriented programming language.
  • the searching architecture is used to count the number of rules which make use of the object which is changed. In another aspect, the same searching architecture is used to locate the logic to be recompiled.
  • Figure la illustrates a prior art graphical representation of a graphical rewrite rule
  • Figure lb illustates a compiled representation of the graphical rewrite rule presented in la;
  • Figure lc illustrates the rule in la after the user has altered object 0 ⁇ such that it occupies four cells
  • Figure Id illustrates the recompiled representation of the graphical rule in lc
  • Figure 2 illustrates a process for asking a user for permission to recompile logic that is related to an object being changed in a graphics-based logic driven application program
  • Figure 3 illustrates a calling chain where different objects implement the node interface, permitting a variety of searches to be implemented
  • Figure 4 is a flow diagram illustrating the implementation of the "iterate" method by nodes (containers and meta-containers);
  • Figure 4A is a flow diagram illustrating the implementation of the iterate method by leaf nodes (rules);
  • Figure 5 is a flow diagram showing a general process item flow that can be used to perform operation 421 of Figure 4A;
  • Figure 6A is a flow diagram depicting a searcher which uses the Searcher state parameter as an accumulator to count the number of objects meeting the criteria of a search;
  • Figure 6B is a flow diagram illustrating operation 416 of Figure 4 when the process of Figure 6A is used in operation 502 of Figure 5;
  • Figures 7A and 7B collectively represent the implementation of a Searcher object which locates and returns a Rule making reference to some simulation object, such as a simulation variable or appearance which the user would like to delete;
  • Figure 7A is a flow diagram illustrating a process for changing the Searcher state in operation 502 of Figure 5 such that the Searcher state represents an identity of one or more objects meeting the criteria of a search;
  • Figure 7B is a flow diagram illustrating operation 416 of Figure 4 when the process of Figure 7A is used in operation 502 of Figure 5;
  • Figures 8 A and 8B collectively represent a Searcher object whose purpose is to locate all rules making use of a changed simulation object, and recompile them;
  • Figure 8 A is a flow diagram illustrating a process for recompiling a rule during operation 502 of Figure 5 when the search architecture of Figure 4 is used to find a rule that uses the graphical object in operation 216 of Figure 2;
  • Figure 8B is a flow diagram illustrating operation 416 of Figure 4 when the process of Figure 8A is used in operation 502 of Figure 5;
  • Figure 8B is identical to 6B in that the return value of "no" effectively indicates that the entire tree is to be searched;
  • Figure 9 is a flow diagram that illustrates a process for recompiling logic during operation 804 of Figure 8 A.
  • Figure 9A is a depiction of a change in the size of a graphical object from one cell on a "before" portion of a rule to several cells, and the corresponding change in the tests which are effected by the present invention.
  • a graphical object is "moved" from a repository of objects and positioned in a cell or cells of a grid on a template or board, i.e., a display or other graphical user interface, such as by clicking on the object with a mouse pointer and dropping the object in the cell, for example.
  • a template or board i.e., a display or other graphical user interface
  • a system utilizing a programming language based on graphical-rewrite rules is described by U.S. Patent No. 5,566,295, which is herein incorporated by reference in its entirety for all purposes.
  • the graphical object is moved from its current cell to another cell or cells using the mouse or other input device.
  • This movement automatically creates logic, i.e., code, including a rule of movement for the object, which the object will follow to move independently from cell to cell across the board.
  • each rule is compiled into a series of matching tests, where there is one test for each cell, or rectangle, on the board.
  • a test succeeds when the corresponding cell in the simulation contains all of the objects that were in that cell at the time the template was created.
  • the rule matches when all of these tests succeed.
  • the "before" portion of a graphical rewrite rule is compiled in order to make execution more efficient.
  • the GRR must be recompiled.
  • the rules that use the graphical object are located and automatically recompiled.
  • the changed graphical object will continue to function according to the rules during execution of the program as it did before it was changed by the user. It should be noted that it is not necessary that the changed graphical object be in contiguous cells. For example, the object may be altered so that it surrounds a cell in the simulation which it does not itself occupy.
  • a process 200 for asking a user for permission to recompile logic that is related to an object being changed in a graphics-based logic driven application program begins at 202 once an indication is received that a graphical object is or has changed in the program such that it occupies more or fewer cells
  • an operation 204 the number of rules that make use of the object in their "before" portions are counted utilizing the searching mechanism which is also the subject of the invention.
  • the number of rules which make use of the object is presented to the user before any changes are made, so that the user may have the option to avoid such changes in order to avoid the automatic recompilation, which may take a long time.
  • Each instance of logic is part of a rule that refers to the object. Refer to the discussion of Figures 4, 5, 6A and 6B for a description of an illustrative searching mechanism that may be used to count the number of rules that make use of the object in their "before" portion.
  • a user may be queried in an operation 210 as to whether the change in the object is desired.
  • This operation is to ensure that the user gives permission for the recompilation of the logic, the other is to inform the user of the scope of the recompilation required by his change.
  • One way of querying the user is through the display of a pop-up window which prompts the user for the permission. An affirmation or negation of permission to make the change would then be received from the user based on a user interaction with the pop-up window. For example, the window could display a message such as "Do you wish to make the change to the graphical object? 132 rules will be changed! and two buttons, one affirmative and one negative.
  • a decision operation 212 it is determined whether the user desires the change in the object based on the user interaction. For example, if the user chooses the negative button in the pop-up window, the object is reverted to its original state in operation 214 and the process ends at 208 with no recompilation of the logic because the object has reverted to its previous state. If the user chooses the affirmative button, such as by pointing to it with a mouse pointer and clicking a button on the mouse, the process continues with the modified object.
  • operation 216 the logic that is associated with the changed object is found and recompiled.
  • a searching mechanism that may be used to find the logic associated with the object in operation 216 is described with reference to Figures 4, 5, 7A and 7B. More information regarding recompilation of the logic is found below with reference to Figures 8 A through 9 A. The process ends at 218.
  • the search mechanism has three design goals: 1) to provide a mechanism by which all rules in a simulation may be examined 2) to enable different kinds of searches to be performed, that is, to scan an entire simulation for a particular rule or to count all rules which make use of an object, such as a simulation object type or a variable. (In the prior art, there were separate calling chains for these uses) 3) to enable different kinds of containers and meta-containers for rules to be added without having to rewrite any searches or any calling chains.
  • Simulations and objects which are or contain rules, including simulation object types, subroutines, and rules all implement a single "iterate" method.
  • This method has two parameters: an object which implements the Searcher interface and a parameter which may be any object or null.
  • the purpose of the second parameter is to provide the Searcher with a way of maintaining its internal state. For instance, when counting rules referring to a particular object, the second parameter would be the number of rules found thus far.
  • this is a standard technique that permits the code of the Searcher object to be re-entrant, or thread-safe. That is, it permits a single instance of a Searcher object to be in use by multiple threads without having one thread distort the internal state of a search being performed by a second thread..
  • Figure 3 illustrates a calling chain where different objects implement the node interface, permitting a variety of searches to be implemented.
  • the searching architecture 302 of Figure 3 decomposes the search into two parts: an interface which is implemented by nodes 304, and an interface which is implemented by searching functions 306. These interfaces are described below in Sun's Java® programming language, although the searching architecture 302 could be implemented in virtually any programming language.
  • Each node 304 determines what data are subjected to the searching function.
  • the searching function 306 determines whether it is done. If not, searching continues.
  • Figure 4 illustrates the preferred process 400 of an "iterate" method as implemented by objects which contain nodes (containers and/or meta-containers), for performing searches such as those described in relation to Figure 3.
  • the process 400 of Figure 4 represents a searching architecture with variable applications. For example, this process 400 may be used to count the number of rules that are associated with the graphical object. See operation 204 of Figure 2. This process 400 may also be used to identify logic that is associated with the graphical object so that the logic may be recompiled. See operation 216 of Figure 2.
  • the process 400 starts at 402 with the receipt of a Searcher software object and a "Searcher state" parameter.
  • the "Searcher state” parameter will generally be null at the beginning of search.
  • a decision operation 404 it is determined whether data remains to be searched, for instance, whether or not the Searcher software object has been passed to all simulation objects. If no more data is to be searched, the Searcher state is returned in operation 406 and the process ends at 408.
  • a data item is retrieved in operation 410.
  • the data item will be a rule or a container which must also implement the "iterate” method.
  • the Searcher software object and the "Searcher state” parameter are given to the data item's “iterate” method in operation 412.
  • a new “Searcher state” is received from the invocation of the data item's “iterate” method in operation 414.
  • the Searcher is asked whether it is done in a decision operation 416 by invoking the Searcher's "done" method using the Searcher state.
  • This operation 416 separates the criterion of being done from the act of performing the objective of the search, such as counting or finding particular data items. Those skilled in the art will recognize this as an alternative to testing the Searcher for a particular value. If the searcher indicates that it is not done in operation 416, the process 400 repeats beginning with operation 404 to determine whether there is more data to search. If the searcher indicates that it is done, the current Searcher state is returned in operation 406 and the process ends at 408. It should be noted that it is possible for the original Searcher state to be returned in operation 406, such as when the search does not find data items it is searching for.
  • the process 400 shown in Figure 4 searches through a set of data structures about which nothing is known, other than any contained objects implement the "iterate" method. This permits the container objects to organize the data however they like. The searcher does not need to know how the container objects organize their data; it merely processes each contained object one-by-one.
  • the process of the "iterate” method is depicted in Figure 4A.
  • the process starts at 420 with the receipt of the Searcher software object and the searcher's state.
  • the Rule invokes the Searcher's "processltem” method, passing itself and the Searcher's state as parameters.
  • the Searcher's "processltem” method then returns the new or updated state 422 which is finally returned to whoever invoked the Rule's "iterate” method in 423.
  • Figure 5 illustrates an exemplary process that the searcher can perform to create a new Searcher state once it receives the Searcher state and data item in operation 421 of Figure 4A.
  • the process starts at 500.
  • the searcher uses the item and Searcher state to find a new Searcher state, which is returned in operation 504.
  • the process ends at 506.
  • a code segment that may be used to perform the process of Figure 5.
  • the code segment is written in Java.
  • Figures 6 A and 6B collectively illustrate the implementation of a Searcher software object whose purpose is to count the number of Rules in a Simulation which make reference to a given simulation object.
  • Figure 6A illustrates an exemplary searcher process for counting all Rules which make reference to a simulation object during performance of operation 502 of Figure 5.
  • the searcher process begins at 600 and in a decision operation 602 it is determined whether the Rule makes such a reference. If the item meets the criteria, the Searcher state, in this case a number, is incremented by one in operation 604 and the Searcher state is returned in operation 606. If the item does not make reference to the Simulation object, the Searcher state is returned unchanged in operation 606. The process ends at 608.
  • this counting procedure could be used to count objects which meet any given criteria.
  • RuleListltem.IterationProcessor ruleCounter new RuleListItem.IterationProcessor()
  • processorState // expects processorState to be an Integer public Object processItem(RuleListItem item, Object processorState)
  • a second searcher method "done” corresponding to the searcher process of Figure 6A begins at 610 and, in operation 612, returns an answer to the question posed to the searcher in operation 416 of Figure 4, namely, whether the searcher is "done” given the new Searcher state. Because this search must check all Rules in the simulation to make an accurate count, "done” is always false, regardless of the current count. Those skilled in the art will recognize that an alternative might be to return "true” if the count has reached a certain limit.
  • the searcher process ends at 614.
  • Figures 7A and 7B collectively represent the implementation of a Searcher object which locates and returns a Rule making reference to some simulation object, such as a simulation variable or appearance which the user would like to delete.
  • a searcher process for performing operation 502 of Figure 5 finds data items meeting predetermined criteria.
  • the searcher process begins at 700 with a Searcher state equal to null.
  • a decision operation 702 it is determined whether the item meets the criteria. If the item meets the criteria, the Searcher state is altered to identify the item in operation 704 and returned in operation 706. If the item does not meet the criteria, the Searcher state is returned as null.
  • the process ends at 708.
  • Figure 7B illustrates a second searcher process, corresponding to the searcher process of Figure 7A, that returns an answer to the question posed to the searcher in operation 416 of Figure 4, which is whether the searcher is done given the new Searcher state.
  • the searcher process of Figure 7B begins at 710 and, in operation 712, the searcher determines whether the Searcher state has a null value. If the Searcher state is null, the searcher returns a negative response in operation 714 and the process of Figure 4 is repeated to continue searching for the data item. If the Searcher state is not null, the searcher returns a positive response in operation 716, which causes the Searcher state to be returned in operation 406 of Figure 4.
  • the searcher process of Figure 7B ends at 718.
  • RuleListltem. IterationProcessor ruleFinder new RuleListItem.IterationProcessor()
  • Figures 8 A and 8B collectively represent a Searcher object whose purpose is to locate all rules making use of a changed simulation object, and recompile them.
  • Figure 8 A depicts a process for performing operation 502 of Figure 5 for recompiling the logic and/or rule that is associated with the graphical object, in accordance with operation 216 of Figure 2.
  • operation 502 is in turn used to perform part of the process of operation 412 of the process 400 of Figure 4.
  • Operation 216 of Figure 2 is in turn partially or fully performed by the process 400 of Figure 4.
  • the process of Figure 8 A begins at 800 and in operation 802 it is determined whether the logic is associated with the graphical object. If the logic is associated with the graphical object, the rule is recompiled in operation 804 and a Searcher state is returned in operation 806. The Searcher state is always returned as null in operation 806 because the Searcher state is not being used to return any information. The process ends at 808.
  • a process corresponding to the process of Figure 8 A, returns a negative response to the question posed to the searcher in operation 416 of Figure 4.
  • the process begins at 810 and the negative response is returned in operation 812.
  • the process ends at 814.
  • the search process of Figure 4 is repeated until all of the logic associated with the graphical object has been found and recompiled if necessary.
  • RuleListltem. IterationProcessor ruleRecompiler new RuleListltem.IterationProcessorO
  • Rule rule (Rule) item; rule.recompileO;
  • Figure 9 illustrates a process for performing operation 804 of Figure 8 A for recompiling logic. See also Figure 9A for a graphical depiction of the process of Figure 9.
  • the process begins at 900.
  • a before board i.e., a template or a board of a graphical user interface on which the graphical object is positioned before its movement according to the rules, is cleared of the graphical object in operation 902 to create a new blank before board.
  • all of the objects on the before board are cleared, including those remaining unaltered.
  • the altered graphical object is placed on the new before board with its new size, shape, etc. in operation 904.
  • new logic preferably new tests
  • new tests are generated on the new before board, which are used to replace the old logic and/or tests in operation 908.
  • the process ends at 910. It should be noted that any searching mechanism or search engine could be used to find and recompile the logic affected by the change in the graphical object, not just those presented here.
  • Figure 9A is a graphical depiction of the process of Figure 9.
  • the before board 920 has a first graphical object 922 positioned in cell (0,0) and a second graphical object 924 positioned in cell (1,1).
  • the before board 920 is cleared of the objects 922,924 to create the new before board 926.
  • each rule is compiled into a series of matching-tests, where there is one test for each cell, or rectangle, in the before board 920. A test succeeds when the corresponding cell in the simulation contains all of the objects that were in that cell at the time the template was created. The rule matches when all of these tests succeed.
  • Each cell on the before board 920 has a list 928 of graphical objects in that cell.
  • Each test is based on the list 928 of the objects found in the cell.
  • the lists for the affected cells change.
  • the tests are recompiled based on the new lists for some or all of the cells on the new before board 926. In this way, the tests will be updated so that they do not fail thus causing the rule to not match, thereby causing the program to malfunction.
  • the graphical object will move to another cell or cells according to the rules during execution of the program. It should be noted that it is not necessary that the changed graphical object be in contiguous cells.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un procédé permettant de recompiler une portion de la logique dans un programme d'application commandé par logique en mode graphique. Ce procédé consiste à recevoir une indication indiquant qu'un objet graphique a été transformé en un programme d'application commandé par logique en mode graphique. La logique du programme d'application associée à l'objet graphique est recherchée. Une fois que toute ou partie de la logique associée à l'objet graphique est trouvée, elle est recompilée dans le programme d'application qui est associé à l'objet graphique. Le système permettant de recompiler la logique associée à un objet par transformation dudit objet en un programme d'application commandé par logique en mode graphique (fig. 4 à 9) comprend un processeur qui reçoit une indication qui indique cette transformation, un programme de recherche qui recherche la logique dans le programme d'application associée à l'objet graphique, et un compilateur qui recompile la logique dans le programme d'application associé à l'objet graphique (fig. 9a).
PCT/US2001/001271 2000-03-13 2001-01-12 Dispositif de recompilation d'instructions produites par un systeme graphique Ceased WO2001069402A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001227911A AU2001227911A1 (en) 2000-03-13 2001-01-12 Apparatus for recompiling instruction produced from graphical based system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US52405300A 2000-03-13 2000-03-13
US09/524,053 2000-03-13

Publications (1)

Publication Number Publication Date
WO2001069402A1 true WO2001069402A1 (fr) 2001-09-20

Family

ID=24087557

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/001271 Ceased WO2001069402A1 (fr) 2000-03-13 2001-01-12 Dispositif de recompilation d'instructions produites par un systeme graphique

Country Status (2)

Country Link
AU (1) AU2001227911A1 (fr)
WO (1) WO2001069402A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5831611A (en) * 1995-02-24 1998-11-03 Saleslogix Corporation Apparatus and method for creating and executing graphically depicted communication
US5973686A (en) * 1996-09-30 1999-10-26 Kabushiki Kaisha Toshiba GUI edition aiding apparatus, GUI edition aiding method, and record medium recording GUI edition aiding program

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5831611A (en) * 1995-02-24 1998-11-03 Saleslogix Corporation Apparatus and method for creating and executing graphically depicted communication
US5973686A (en) * 1996-09-30 1999-10-26 Kabushiki Kaisha Toshiba GUI edition aiding apparatus, GUI edition aiding method, and record medium recording GUI edition aiding program

Also Published As

Publication number Publication date
AU2001227911A1 (en) 2001-09-24

Similar Documents

Publication Publication Date Title
CA2144874C (fr) Systeme de creation incrementielle de programme
Bardohl et al. Application of graph transformation to visual languages
US6209125B1 (en) Method and apparatus for software component analysis
EP0664027B1 (fr) Systeme de modelisation de programmes
Kieras A guide to GOMS model usability evaluation using GOMSL and GLEAN3
DeMichiel et al. The common lisp object system: An overview
US8214822B2 (en) Editor for program files
Jahnke et al. Rewriting poor design patterns by good design patterns
CN109189374A (zh) 基于对象引用链的对象构造代码生成方法及系统
Rosson et al. Active programming strategies in reuse
Schafer et al. The SEXTANT software exploration tool
Korn et al. Traversal-based visualization of data structures
WO2001069402A1 (fr) Dispositif de recompilation d'instructions produites par un systeme graphique
Bobrow et al. New programming languages for AI research
Berón et al. Static and dynamic strategies to understand c programs by code annotation
Ahrendt et al. Using the KeY prover
Price et al. Mastering Visual C#. Net
Jesshope et al. An intelligent Pascal editor for a graphical oriented workstation
Mcdonald et al. Computing Environments for Data Analysis. Part 3. Programming Environments.
Achten et al. The beauty and the beast
Alspaugh Scenario networks and formalization for scenario management
McLennan Object-Oriented Programming with [incr Tcl] Building Mega-Widgets with [incr Tk]
Riesco et al. A declarative debugger for Maude specifications-User guide
Furtado et al. An ontology-based method for designing multiple user interfaces
Rogers Visual programming using graphics, relations, and classes

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP