Method and apparatus for executing control system functions in a computer system5386558Abstract A control system is implemented by provision of parts which are data structures with identities, properties, and references to other parts, and clusters which are structures of associated parts. Clusters are assembled into meanings, and contexts are built from meanings and logic components. A current behavior expression consisting of a cluster is established and a meaning analysis procedure searches a set of meanings in a current context for correspondence between one or more meanings and the current behavior expression. When correspondence is found, further analysis switches the current behavior expression to a meaning matched in the current context. The process continues, switching context if necessary, until no meaning can be matched to a portion of the current behavior expression. Those portions of the current behavior expression for which no meaning is found represent primitive actions which are executed to carry out a system intention. Claims We claim: Description BACKGROUND OF THE INVENTION
______________________________________
Property-Kind
Property-Value
______________________________________
type either "box", "connector" or "triangle".
Each part must contain exactly one of
these properties.
style either "solid", "bold", or "dashed".
Each part must contain exactly one of
these properties.
______________________________________
There are several notational conventions that are useful to introduce at this point: 1. The property-kind of a property may be used to characterize or qualify a property. Thus, if a property within a part has a property-kind of "type", this property may be referred to as the "type property" of that part. Similarly, if a property within a part has a property-kind of "style", this property might be referred to as the "style property" of the part. 2. Both the property-kind and the property-value can be expressed by a statement to the effect that a given part has a type property of "box". What is meant by this statement is that the given part contains a property whose property-kind is "type" and whose property-value is "box". 3. A part may be characterized by its type property (since every part must contain such a property). Thus a part whose type property is box may be referred to as a "box". Similarly, a "connector" is a part whose type property is connector and a "triangle" is a part whose type property is triangle. 4. A part described as a box, a connector or a triangle may be further qualified by its style property. Thus, a connector may be "solid", "bold", or "dashed". Making use of these short-hand conventions, additional constraints on properties can be described. A "connector" will always possess the following additional properties:
______________________________________
Property-Kind
Property-Value
______________________________________
source the identity of the part from which the
connector emanates.
target the identity of the part at which the
connector terminates.
______________________________________
According to the above, a connector's source property is said to point at the part which is the source of the connector, and the target property points at the connector's target. A connector's source and target properties are matched by two additional properties:
______________________________________
Property-Kind
Property-Value
______________________________________
source-of this property indicates the part is the
source of a connector; the value of this
property is a reference to the connector.
Multiple source-of properties are
permitted per part.
target-of this property indicates the part is the
target of a connector; the value of this
property is a reference to the connector.
Multiple target-of properties are
permitted per part.
______________________________________
Finally, there is one property whose existence is optional:
______________________________________
Property-Kind
Property-Value
______________________________________
text a string of characters which are to be
associated with the part. These are
displayed inside the outline of a box or
triangle and near the mid-point of a
connector. Only one text property is
permitted per part.
______________________________________
Each part may also contain certain properties used by the diagram-editor such as those used to specify the on-screen coordinates of the corresponding visual element (the visible representation of a part). These properties will not be discussed further here. FIG. 9A is a diagrammatic representation of a collection of parts. Each box, triangle or connector which appears in diagram will also have a corresponding internal machine representation which conforms to the requirements set out above. Consider the parts 101, 102, 103, 103a, 103b, and 104 which appear at the top of FIG. 9A. The internal, machine representation of these parts would include: part (101): has a type property of box, has a style property of solid, has a text property of "handle request", has a source-of property which references (or points at) part (102), has a source-of property which points at part (103a) (the solid connector attached to the triangle). part (102): has a type property of connector, has a style property of dashed, has a text property of "what", has a source property which points at part (101), has a target property which points at part (103). part (103): has a type property of box, has a style property of solid, has a text property of "**details", has a target-of property which points at part (102). part (103a): has a type property of connector, has a style property of solid, has a source property which points at part (101), has a target property which points at part (103b). part (103b): has a type property of triangle, has a style property of solid, has a target-of property which points at part (103a). has a source-of property which points at part (104). has a text property of "C2" part (104): has a type property of connector, has a style property of solid, has a source property which points at part (103b), has a target property which points at part (117). The remaining diagrammatic elements in FIGS. 9A thru 12E and 14 will have internal representations which correspond in a similar fashion. DETAILED DISCUSSION OF THE EXAMPLE In accordance with the Detailed Description of the Preferred Embodiment, several things are required for a fully functioning system. The system's executor component must be able to construct and initialize one or more context data structures in which each context contains a series of meanings and a collection of logic components. It is assumed that the executor has the ability to access the diagrams necessary for each case of the example discussed here. Further, it is assumed that the executor has the ability to access the logic components described in detail below and to properly associate these logic components with the three contexts used in this example. When the executor begins operation, it must initialize all the parts of the system which are under its control. As part of initialization, the executor will initialize the default context C1 along with any other context it may detect. The default context is always assumed to exist. An additional context is designated by the existence of a part whose type is "box" and whose style is "bold". Meaning-Definition-Logic The meaning-definition-logic component for this context is found in the diagram editor, described above. The logic must: 1. Search all diagrams for collections of parts which can be recognized as meanings by this meaning-definition-logic, 2. For each meaning so identified, find and store the primary-part of the meaning-template, the primary-part of the definition-cluster and the definition-context to be used for the meaning. The definition-cluster-logic used in this example employs a simple set of conventions which permit these steps to be carried out. A user who wishes to create a new meaning uses the diagram-editor to construct a cluster of diagrammatic elements (parts) which is the desired meaning-template and another cluster of parts which is the desired definition-cluster. This logic employs a diagrammatic convention by which these two clusters may be associated together and identified as a meaning in such a way that their distinct roles are preserved. According to the simple convention used in this example, triangles are reserved for the purpose of identifying meanings. So, a triangle is not permitted to exist within either a meaning-template, a definition-cluster, or the system's initial behavior-expression. The user marks the existence of the new meaning by creating a triangle and two connectors. The meaning-template is designated by creating a connector whose source is the primary-part of the meaning-template and whose target is the triangle. The definition-cluster is designated by creating a connector whose source is the triangle and whose target is the primary-part of the definition-cluster. This simple convention unambiguously indicates the existence of a meaning and identifies the primary-parts of both the meaning-template and the definition-cluster. The text property of the triangle is used to designate the definition-context that is to be associated with the meaning. Given this convention, the meaning-definition-logic builds the context's meanings-list by searching the diagrams for triangles and then inspecting the two connectors which are, according to this convention, attached. It can be seen, then, that the primary-part of the meaning-template is the part pointed at by the source-of property of the connector whose target property points at the triangle. Looking at FIG. 9A, the triangle is part 103b. This triangle is pointed at by the connector 103a. The source-of property of this connector points at part 101. Thus, part 101 is the primary-part of a meaning-template. The primary-part of the definition-cluster is the connector whose source property references the triangle. Looking again at FIG. 9A, part 104 is the primary-part of the definition-cluster. As each meaning is added to the meanings-list, the triangle and its two adjacent connectors must be identified in some way so that later processing will not erroneously consider them to be part of a meaning-template or a definition-cluster. This is done here by adding these parts to a list of parts already matched in this context. The definition-context saved with a meaning is the context designated by the text property of the triangle. Thus, for example, the triangle 103b of FIG. 9A includes a text property "C2", which identifies the context C2. This means that the definition cluster whose primary part is 104 is to be evaluated in context C2. It is assumed in this example, that the items identified as meanings are stored in a simple list in whatever order the they are encountered by the meaning-definition-logic. This simple list storage device constitutes the meanings-list for the context. Observe that in FIG. 10, the illustrated meanings (A and B) are enclosed in a single rectangle, together with the notation "C2::import C1". This indicates that these meanings are defined in context C2 and that context C2 "imports" the meanings from context C1. Similar notation is found in FIG. 14. Initial Behavior-Expression FIG. 9B shows the example's initial behavior-expression. It is assumed that the initial behavior-expression for a system begins with a box whose text is "start" (as with part 105). The point of this behavior-expression is to test the meaning of "handle request" with a sample request for a meeting at noon-wednesday, in the lunchroom, for the purpose of draft-product-spec with the members of the planning group as participants. Here, the executor is presumed to have initialized the text properties of parts 108, 110, 112, 114, and 116 from the corresponding fields of the an electronic mail message like:
______________________________________
what: meeting
who: the planning group
where: lunchroom
why: draft-product-spec
when: noon-wednesday
______________________________________
Meaning Analysis Applied to the Example As discussed in the Detailed Description of the Preferred Embodiment, the system's intention is evaluated by the executor through a meaning analysis process which is presented with an initial behavior-expression, a context and a set of circumstances. In this case, the initial behavior-expression is given by FIG. 9B, the context is the global context (C1) which is assumed to exist for this example, and the set of circumstances is initially empty (that is, an internal machine data structure which is capable of storing various items of information but which has been initialized to contain no such items). It is also assumed that the meaning-definition-logic for each context has been activated so as to result in the construction of a meanings-list data structure for each context. For sake of the example, assume that the triangles in the diagrams are encountered in the order in which the figures are presented here. Thus, the meanings-list for context C1 will be ordered so as to correspond with FIGS. 9A, 11A, 11B, 12A, 12B, 12C, 12D, and 12E. The first two meanings in the meanings-list for context C2 will correspond with meanings A and B in FIG. 10. The remainder of C2's meanings-list will be copied from C1's meaning-list because "::import C1" appears in the text property of C2. Similarly, the meanings-list for context C3 will consist of the meaning that corresponds with FIG. 14 followed by the meanings from C1's meaning-list because "::import C1" also appears in the text property of C3. Note that FIG. 9B does not contain a triangle and so has no corresponding meaning in any meanings-list. The Example is next illustrated with a step-by-step description of the operation of the invention. This description is intended to be read with reference to FIGS. 9A-12E and to the logic descriptions which follow it. The following steps are now performed: 1. The executor creates a new instance of the meaning analysis process shown in FIG. 8, and gives it references to the initial behavior-expression, the global context and the current circumstances. 2. Next, C1's first-part-logic (see logic description 1.1.1) is activated in order to select an initial candidate part. When activated for the first time, the first-part-logic searches the behavior-expression for a box whose text is "start". Given the initial behavior-expression shown in FIG. 9B, part 105 will be selected by the first-part-logic. 3. With this part as the current candidate part, C1's first-meaning-logic is now activated (see logic description section 1.2.1). The first-meaning-logic will pick the first meaning on the context's meanings-list. This first meaning is the one represented in FIG. 9A. 4. References to the primary-part of this meaning's meaning-template (part 101) and the current candidate part (part 105) are routed to C1's cluster-match-logic (see logic description 1.3.1). 5. Cluster-match-logic begins by invoking the match-parts-logic (see logic description 1.3.2) in order to compare parts 101 and 105. 6. While parts 101 and 105 have matching type and style properties, their text properties fail to match. Match-parts-logic reports failure to cluster-match-logic. 7. Cluster-match-logic notes the failure and calls C1's get-parts-logic (see logic description 1.3.4) passing it a reference to the current candidate part (part 105). 8. Get-parts-logic inspects part 105 and notes that it has a source-of property. The connector referenced by this property (the connector 105a) is examined. Since the style property of this connector is "solid", a reference to this part (connector 105a) is added to the parts list being built (the "boundary list"). At this point get-parts-logic is finished because part 105 has no more properties of interest (see logic description 1.3.4). Get-parts-logic returns a list containing only part 105a. 9. Cluster-match-logic now returns to the instance of meaning analysis which invoked it, passing back the boundary list built by get-parts-logic and a failure indication. 10. Meaning analysis now builds a result-item (the build step 76 in FIG. 8) consisting of the boundary-list (which contains part 105a only) and the failure indication. This result-item is stored in the results-pool for this instance of meaning analysis (see FIG. 8, step 78, and FIG. 15). 11. Next, the match-loop-control-logic (FIG. 8, reference numeral 79) is activated. This logic functions by processing each result-item as it is generated (see logic description 1.3.5). In this case, since the result-item indicates failure, the next-meaning-logic is activated (see logic description 1.2.2). Given the earlier assumption as to the order of meanings in the meanings-list, the next-meaning-logic will return a reference to the meaning shown in FIG. 11A. 12. Meaning analysis will now attempt another cluster-match (as in step 4 above), this time with the current candidate part (part 105) and the primary-part of the next meaning found in the meanings-list (part 160). 13. The above steps 4 through 11 will be repeated for each meaning in the meanings-list. By examining the diagrams involved in the example, it can be seen that there is no meaning that will match the part 105. These steps will be repeated essentially as described above until the match-loop-control-logic (step 11) is encountered after an uncessful attempt to match the last meaning. 14. At this point, the example is in match-loop-control under conditions that will cause the next-meaning-logic to report that there are no more meanings to examine. As described below in logic description 1.3.5, match-loop-control will now activate the primitive-action-logic, giving it a reference to the current candidate part (part 105). 15. The primitive-action-logic (see logic description 1.4) will examine each word in the text property of the part, looking for words which begin with the character "*". In this case, there is only one word ("start") and it does not begin with a "*", so the word "start" is written into the system's log file and control is returned to the match-loop-control-logic. Match-loop-control-logic now accesses the current result-item, copies its boundary-list (consisting of part 105a only) into the working-pool (FIG. 15) and returns to meaning analysis with a result indicating that a new candidate part should be selected. 16. Meaning analysis now activates the next-part-logic (FIG. 8, reference numeral 89). Next-part-logic (see logic description 1.1.2) takes a part from the working-pool (FIG. 15) and makes this part the current candidate part. In this case, the new candidate part will be the connector 105a. 17. Meaning analysis once again sets about searching the meanings-list for a successful cluster-match. This is done by again invoking C1's first-meaning-logic. This corresponds to step 3 above (but this time with part 105a as the current candidate part). 18. As was true previously, there is no meaning in the meanings-list that will successfully match the connector 105a. Therefore, meaning analysis will cycle through the meanings-list as it did before, with match-parts-logic failing every time. The only real difference in attempting to find a cluster match with connector 105a is that when get-parts-logic inspects this part (in accordance with logic description 1.3.4), it will not find a source-of property. Instead, a source and a target property will be detected. When the source property is examined, get-parts-logic will note that the part referenced by this property (part 105) has been marked as matched in the current meaning analysis instance and, consequently, part 105 will not be placed on get-part-logic's list. When the target property is examined, get-parts-logic will note that the part referenced by this property (part 106) has not been marked as matched and will, consequently, place part 106 on the list it returns to cluster-match-logic. As in steps 9 and 10, cluster-match-logic returns this list to meaning analysis where the list becomes the boundary-list in a new result-item which takes the place of the old one in the results-pool (FIG. 15). 19. Control will finally arrive at match-loop-control-logic with the meanings-list having again been fully examined. As before in step 14 above, match-loop-control-logic will activate the primitive-action-logic, giving it a reference to the current candidate part (this time part 105a). Primitive-action-logic (logic description 1.4) will attempt to examine each word in the part's text property. Since this part has no text property, primitive-action-logic returns, taking no action. Match-loop-control-logic now copies the current result-item's boundary-list (this time consisting of part 106 only) into the working-pool (FIG. 15) and returns to meaning analysis with a result indicating that a new candidate part should be selected. 20. Meaning analysis now activates the next-part-logic. Next-part-logic (see logic description 1.1.2) takes a part from the working-pool (FIG. 15) and makes this part the current candidate part. In this case, the new candidate part will be the box 106. 21. Meaning analysis again sets out to find a successful cluster-match. This is done by invoking C1's first-meaning-logic (reference numeral 72 in FIG. 8) which again corresponds to step 3 above (but now with part 106 as the current candidate part). 22. In the case of the two candidate parts examined so far (parts 105 and 105b), both parts failed all cluster-match attempts. With part 106 as the current candidate part, a successful cluster-match will occur. 23. References to the current candidate part (part 106) and the primary-part of the first meaning (part 101) are routed to C1's cluster-match-logic (see logic description 1.3.1). 24. Cluster-match-logic invokes match-parts-logic (logic description 1.3.2) to compare parts 101 and 106. Since parts 101 and 106 have matching type, style and text properties, match-parts-logic reports success to cluster-match-logic. 25. Cluster-match-logic next invokes get-parts-logic (logic description 1.3.4), passing it a reference to the candidate part, in order to build a "candidate.sub.-- list" of parts referenced by the candidate but excluding any parts previously matched. In this case, the candidate.sub.-- list will contain just one part, the connector identified as part 107 in FIG. 9B. 26. Cluster-match-logic invokes get-parts-logic again, this time passing it a reference to the meaning part (part 101), in order to build a "meaning.sub.-- list" of parts referenced by the meaning part but excluding any parts already matched during this match attempt. The meaning.sub.-- list will also contain just one part, the connector identified as part 102 in FIG. 9A. 27. Cluster-match-logic now invokes C1's recursive-match-logic, giving this logic access to the candidate.sub.-- list and the meaning.sub.-- list. 28. Recursive-match-logic (logic description 1.3.3) performs the function of comparing a candidate.sub.-- list with a meaning.sub.-- list and invoking itself again (recursively) as many times as may be necessary to fully explore the meaning-template. Proceeding with logic description steps 1.3.3.A, recursive-match-logic determines that there is only one possible pairing of parts from the two lists (since each list contains only one part). At this point, the m-part is part 102, and the c-part is part 107. 29. Proceeding with logic description steps 1.3.3.B and 1.3.3.C, recursive-match-logic applies get-parts-logic to the m-part (part 102) to build a "meaning.sub.-- grandchildren" list consisting of part 103. 30. Next (1.3.3.D) match-parts-logic is invoked to determine if the m-part (part 102) and the c-part (part 107) match. 31. Since these two parts match (their type, style and text properties are identical), recursive-match-logic (in accordance with step 1.3.3.E) now applies get-parts-logic to the c-part (part 107) to build a list of "candidate.sub.-- grandchildren" (here consisting solely of part 108). 32. Advancing to step 1.3.3.F, recursive-match-logic determines that the meaning.sub.-- grandchildren list is not empty and so invokes itself, passing both the meaning.sub.-- grandchildren list and the candidate.sub.-- grandchildren list to the new instance of recursive-match-logic. While discussing the operation of this new instance, these two lists will be referred to as its meaning.sub.-- list and candidate list. 33. The new invocation of recursive-match-logic begins at step 1.3.3.A, determining that there is only one possible pairing of parts from the two lists (since each list contains only one part). The m-part is part 103, and the c-part is part 108. 34. Proceeding with steps 1.3.3.B and 1.3.3.C, get-parts-logic is applied to the m-part (part 103) to build a meaning.sub.-- grandchildren list. Since part 103 has no properties which refer to un-matched parts, this list is empty. 35. Next (1.3.3.D) match-parts-logic is invoked to determine if the m-part (part 103) and the c-part (part 108) match. 36. In this instance, match-parts-logic will identify this match as special since the text property of the m-part starts with "**" (see 1.3.2.A). Match-parts-logic reports a match along with an indication that this is a special match involving "**". Also in accord with 1.3.2.D, a circumstance-item is constructed and added to the current circumstances data structure (FIG. 16):
______________________________________
Formal-String: "**details"
Actual-String: 0
Actual-Part: part 108
Actual-Context: C1
______________________________________
37. Recursive-match-logic (in accord with 1.3.3.E) responds to the special match condition by skipping ahead to 1.3.3.H where it is noted that the list of unmatched c-parts is empty and that all m-parts have been matched. 38. Step 1.3.3.I has no effect since the candidate.sub.-- list is exhausted so, at step 1.3.3.J this instance of recursive-match-logic exits, reporting a match and returning an empty boundary-list. 39. This brings the process back to the instance of recursive-match-logic which we left at step 32, above. In returning to this previous instance, we return to the point in 1.3.3.F following the invocation of recursive-match-logic. 40. Continuing with 1.3.3.F, the returned boundary-list is saved. Step 1.3.3.G has no effect since this boundary-list is empty. 41. This instance of recursive-match-logic also moves quickly through steps 1.3.3.H and 1.3.3.I because the list of unmatched c-parts is empty and all m-parts have been matched. 42. At step 1.3.3.J, recursive-match-logic exits back to cluster-match-logic, reporting a match and returning an empty boundary-list. 43. Cluster-match-logic continues in step 1.3.1 and also exits, reporting a match. This exit returns to step 74 in FIG. 8. 44. Next, meaning analysis updates the results-pool (FIG. 15) by (1) discarding any old result-items that may be in the results-pool and (2) adding a new result-item which indicates that part 106 was matched by the meaning of FIG. 9A and which contains an empty boundary-list. 45. Meaning analysis activates the match-loop-control-logic (1.3.5) which immediately processes the new result-item by invoking a new instance of meaning analysis. This instance of meaning analysis will evaluate this definition-cluster in the light of the circumstances data structure and a new context. The circumstances data structure currently contains a circumstance-item indicating that part 103 was matched by a cluster of parts, namely parts 108-116. The new context used by this instance of meaning analysis will be C2 (because the triangle associated with this meaning has a text property of "C2" which caused C2 to be the definition-context designated for this meaning). This change in the "current" context is called a context switch. When this new instance of meaning analysis completes, the executor will return control to the previous instance of meaning analysis which will resume processing using context C1. Thus, a switch to a new context is temporary and returns to the previous context once analysis in the new context has been completed. 46. This instance of meaning analysis starts by invoking C2's first-part-logic (1.1.1) which designates the primary-part of the definition-cluster as the current candidate part (connector 104 in FIG. 9A). Meaning analysis will proceed to search C2's meanings-list for a meaning-template which matches any cluster of parts emanating from part 104. 47. As was the case in step 18 when an attempt was made to find a match for connector 105b, there is no meaning-template that successfully matched connector 104. In this case, when get-parts-logic is applied to part 104, part 117 will be the only member of the list returned. This list will become the boundary-list in new result-item that replaces the old one in the results-pool (FIG. 15). As in step 19 above, primitive-action-logic will be invoked but will take no action since part 104 has no text property. Part 117 will be copied out of the result-item's boundary-list and into the working-pool by match-loop-control-logic who returns to meaning analysis a result indicating that a new candidate part should be selected. 48. It should be clear by now that meaning analysis proceeds to invoke the next-part-logic (89, FIG. 8). In this case, the new candidate part will be the box 117. Meaning analysis once again sets out to find a successful cluster-match for the new candidate part (part 117). 49. A match will be found with the meaning A in FIG. 10. 50. The primary-part for this meaning's meaning-template is part 140 and will be found to match part 117. While the type and style properties of these two parts are identical, their text properties are not. The text property for part 117 is "appropriate subject for me?" while that for part 140 is "appropriate subject for *individual?". 51. The reason why these non-identical text properties are considered to match is to be found in the specification of match-parts-logic, in particular step 1.3.2.D. When this step is reached, the identical words in the two text properties have been found. 52. The text property of part (140) is deemed to match the text of part (117) because the word "*individual" in the meaning-template is allowed to match the word "me" in the candidate-cluster. The convention employed here is that a word beginning with a single "*" is permitted to match any corresponding portion of text in the candidate-cluster not exactly matched by surrounding words or characters. Thus, "appropriate subject for me?" and "appropriate subject for *individual?" are considered to match, according to logic step 1.3.2.D. Also in accord with this step, a circumstance-item will be added to the current circumstances data structure (FIG. 16) that indicates that the word "*individual" was matched by the word "me":
______________________________________
Formal-String: "*individual"
Actual-String: "me"
Actual-Part: 0
Actual-Context: C2
______________________________________
53. Once parts 140 and 117 have been matched, the cluster-match-logic will attempt to match the remaining parts in the meaning-template (141-148). It can be seen that the cluster (145,146) will match (118,120) because of the "**" at the start of the text property of part 146. Another circumstance-item will be added to current circumstances (FIG. 16) indicating that part 146 was matched by part 120:
______________________________________
Formal-String: "**NO"
Actual-String: 0
Actual-Part: part 120
Actual-Context: C2
______________________________________
Similarly, parts 147, 148 and will match parts 119, 121, generating a circumstance-item indicating that part 148 was matched by part 121:
______________________________________
Formal-String: "**YES"
Actual-String: 0
Actual-Part: part 121
Actual-Context: C1
______________________________________
Note that circumstance-items need not be generated for simple, literal matches such as that between part 147 and part 119. 54. The reason that parts 141-144 and 130, 129 match is a bit more complex. In this case, parts 141 and 130 match. Connectors 130-136 are all examples of connectors which are routed from source to target via a right angle at their mid-point; where the arrowhead is positioned. Since these connectors emanate from the same source part (part 129), they are each initially routed downward from their source. Thus, their downward paths overlap and don't diverge until each connector's midpoint. (These connectors could be re-drawn as separate, curved connectors. However, the routing of a connector is not a property involved in comparison in this example.) The question now is how can part 129 be considered as a match for parts 142-144? Part of the answer is that this match is valid only under present circumstances. 55. When connector 130 is matched with part 141 as part of the cluster matching process, get-parts-logic is invoked in order to form the candidates.sub.-- list and candidate.sub.-- grandchildren lists used as part of the recursive matching process. As described in logic step 1.3.4.C, both the source and target properties of connector 130 will be examined. If the text property of the part referenced by a connector's source or target property does not begin with "**" (the usual case), then this part itself is added to the list being built by get-parts-logic. However, according to step 1.3.4.C, whenever such text does start with "**", additional work is performed. Connector 130's source property points at part 129 whose text property starts with "**". So, at step 1.3.4.C in get-parts-logic, when part 129 is being examined to see if it should be added to the list, it will be noticed that its text starts with "**" and a part-substitution will be performed. 56. Part-substitution for part 129 is performed by searching the circumstances data structure for the most recent circumstance-item whose formal-string field is "**details", the text of part 129. In this case, the circumstance-item found is the one built in step 36. As described in step 1.3.4.C, the part referenced by the actual-part field of this circumstance-item will be added to the list build by get-parts-logic instead of part 129. The substituted part is part 108. The result of this substitution is as if part 108 was connector 130's source instead of part 129. (But also note that this effect is a consequence of the current state of the circumstances data structure. If a different part had been matched back in step 36, a different part would be substituted now.) 57. So, as a result, the recursive match attempt actually continues by attempting to match clusters (142-144) and (108-116). Clearly a match-up can be made: 142 & 108, 143 & 113 and 144 & 114. An additional circumstance-item will also be added to the current circumstances data structure as a result of the match-up of parts 144 & 114:
______________________________________
Formal-String: "*subject"
Actual-String: "draft-product-spec"
Actual-Part: 0
Actual-Context: C1
______________________________________
58. The remainder of this successful match will be conducted as before, finally causing another instance of the meaning analysis process to be created in order to evaluate the definition-cluster (whose primary part is part 149) that is associated with the meaning given in FIG. 10 (meaning A). (Note that this new instance of meaning analysis will operate in context C1 because the text property of the meaning triangle is "C1". Once this instance of meaning analysis has finished, control will be returned to the previous instance which was operating in context C2.) 59. At this point, it should be clear how the matching process operates and adds circumstance-items to the circumstances data structure for the various kinds of matches that can occur involving text properties containing words starting with "*" and "**". Relying on this understanding, it can be seen that connector 149 will have no effect other than to bring us to box 150 and the cluster (150-156). 60. This cluster will match the meaning-template shown in FIG. 11A as parts (160-166). The pairing of parts 150 and 160 in this match illustrates the handling of a single "*" in a text property within a candidate-cluster. As in the case of "**", a substitution is made but it is a textual substitution, not a part substitution. Since the circumstances data structure contains a circumstance-item which indicates a correspondence between the formal-string "*subject" and the actual-string "draft-product-spec", the appearance of the string "*subject" in the text of part 150 is replaced by "draft-product-spec". This, in turn, gets associated with the text "*subject" where it appears in part 160. This match-up will lead to the generation of another circumstance-item:
______________________________________
Formal-String: "*subject"
Actual-String: "draft-product-spec"
Actual-Part: 0
Actual-Context: C1
______________________________________
The net effect of this is that the original string "draft-product-spec" from part 114 is propagated through a correspondence with the string "*subject" as it appears in part 144 and then part 150 and later in part 160. (Note that the original Actual-Context field is maintained despite the fact that meaning analysis has switched from context C1 to context C2 and then back again.) 61. After parts 150 and 160 are matched, cluster-match-logic will generate a candidates.sub.-- list consisting of parts 151, 153 and 154 and a meanings.sub.-- list consisting of parts 161, 163 and 165 which will be given to recursive-match-logic to see if matches for all the parts in the meanings.sub.-- list can be found. The logic flow through recursive-match-logic has been described before. But considering the handling of part 151, for instance, it will be found to match-up only with part 163. This will cause a new instance of recursive-match-logic to be activated on a candidates.sub.-- list consisting only of part 152 and a meanings.sub.-- list consisting only of part 164. When match-text-logic is applied to these parts, it will recognize that both the m-part and c-part have text properties which start with "**". As described in logic step 1.3.2.A, a new circumstance-item will be constructed in which the "actual-" fields are copied over from the circumstance-item built in step 53. The new circumstance-item will be:
______________________________________
Formal-String: "**YES"
Actual-String: 0
Actual-Part: part 121
Actual-Context: C2
______________________________________
This instance of recursive-match-logic will quit and return to the previous one which will continue by attempting to match-up the remaining parts (parts 161 and 165 on the meanings side, and parts 153 and 154 on the candidate side). Matches will be found here as well. Parts 153 and 161 will match, adding nothing to current circumstances, but causing another invocation of recursive-match-logic to examine 155 and 162. These will match in the same way as parts 151 and 163. The following circumstance-item will result:
______________________________________
Formal-String: "**NO"
Actual-String: 0
Actual-Part: part 120
Actual-Context: C1
______________________________________
Similarly, parts 154 and 165 will match, leading to a match between parts 156 and 166. This last match will produce the following circumstance-item:
______________________________________
Formal-String: "*item"
Actual-String: "me"
Actual-Part: 0
Actual-Context: C1
______________________________________
62. After a new instance of meaning analysis is applied to part 168 and it is found that there is no meaning that matches, primitive-action-logic is then applied to this part. 63. The primitive-action-logic chosen for this example is very simple in operation. The text property of the part being processed is examined, word-by-word. (Here a word is any group of characters not including a space.) If a word does not start with a "*", it is simply copied to the output file. If a word starts with a "*", the current circumstances are searched for the most recent circumstance-item whose formal-string field matches the word. If the circumstance-item so found has a non-zero actual-string field, a string substitution is performed by copying the actual-string into the output file in place of the word. This sort of action execution, applied to part 168, results in the following output: if (draft-product-spec reasonable for me) { in which the string "*subject" has been replaced by "draft-product-spec" and the string "*item" has been replaced by "me". 64. Since the character "{" of the text property of part 168 is followed by the word "**YES", primitive-action-logic will search for the most recent circumstance-item whose formal-string is "**YES". Since, the actual-string field of this item is zero, and the actual-part field of the circumstance-item is non-zero, the part referenced by the actual-part field is subjected to meaning analysis. In this case, it is part 121. Further processing of part 168 is suspended while part 121 is fully processed. A new instance of meaning analysis is created and part 121 is treated as the primary-part of a definition-cluster to be evaluated in the context specified by the actual-context field of the circumstance-item (in this case, context C2). In this case, the result is the processing of the remainder of FIG. 9A that flows from part 121. Whatever output is to be generated as a result of this new instance of meaning analysis will appear in the output file at this point. (This is discussed more fully in step 65, below.) Once this part (and surrounding clusters) has been fully processed, this new meaning analysis instance concludes and returns to the one whose processing of part 168 was suspended. Any additional circumstance-items created during meaning analysis of part 121 are deleted from the circumstances data structure when this instance terminates. Primitive-action-logic's processing of part 168 will continue with what follows the word "**YES", giving:
______________________________________
}
else {
______________________________________
followed by any output resulting from the word "**NO" which, in turn, is followed by a closing "}". When the word "**NO" is evaluated, the circumstances data structure will be the same as it was when "**YES" was evaluated (since any items added during "**YES" evaluation would have been removed). The evaluation of "**NO" and the closing "}" will actually produce the last lines of output generated by this example (see the full output listing following step 69). 65. But returning to the processing of "**YES" in part 168, the cluster at 121 will be evaluated in context C2 and will, therefore, be matched by the meaning-template at part 170 in FIG. 10. (Note that there would be no match for part 121 if it were evaluated in context C1). The word "*participants" in this cluster will be associated with the string "the planning group" (which appears as the text property of part 110 in FIG. 9B). Similarly, the word "*subject" will again be associated with "draft-product-spec". 66. The definition-cluster shown in FIG. 10 (meaning B) will be evaluated in context C1. (Note the text property of the triangle.) When the cluster at 171 is evaluated, it will not be matched by the meaning-template at 160 because of the different directional orientation of parts 165 and 172. 67. Looking more closely, it is observed that this means that part 171 has two source-of properties (referencing parts 173 and 174) and a target-of property that references part 172 while part 160 has three source-of properties (referencing parts 161, 163 and 165). 68. So, even though their other properties match, these differences are enough to prevent parts 171 and 160 being considered as a match. Since these do not match, other matches will be attempted. Ultimately, it will be found that the candidate-cluster at part 171 does match the meaning-template at part 180) in FIG. 11B. 69. The definition-cluster starting at 181 will then be evaluated. Meaning analysis is applied to this cluster and various matches will be made with meaning-templates appearing in FIG. 12A-E. It is worth noting that when part 182 becomes the candidate-part, it will be matched by part 160 instead of part 180 because of the direction of the dashed-connector. Output The following is the output code generated by the invention as a result of processing the diagrams in the set of FIGS. 9A through 12E:
______________________________________
start
if (draft-product-spec reasonable for me) {
make temporary lists {
appropriate-list ;
inappropriate-list };
while ( the planning group has more individual s) {
examine next individual ;
if ( draft-product-spec reasonable for individual ) {
put this particular individual
at the end of the " appropriate-list ";
else {
put this particular individual
at the end of the " inappropriate-list ";
}
}
if ( appropriate-list matches the planning group ) {
if (time and place are ok) {
accept request
}
else {
propose alternate time and place.
}
}
else {
propose alternate participants.
}
}
else {
decline request
}
______________________________________
This output takes a form familiar to many computer software professionals: a highly-readable, pseudo-code patterned after a popular programming language called C. Since similar textual forms are routinely used to define programs which can be executed on general purpose computer systems, this form of output is taken to be, in effect, equivalent to machine execution. The primary difference between such pseudo-code actual source code in the C language is a line such as:
______________________________________
if ( draft-product-spec reasonable for me ) {
might appear as:
if (reasonable("draft-product-spec", "me") {
______________________________________
This latter would be appropriate given that elsewhere in the program a boolean function named "reasonable " is defined to accept two string arguments. The job of such a function would be to search a database (or a similar collection of data) for a correspondence between a subject whose name matched the first string and an individual whose name can be deduced from the second string and to return a boolean result of TRUE if such a correspondence is found or a boolean result of FALSE if it is not. The effect of this line in the program would thus be to perform a conditional branch based on whether or not the function reasonable returned a TRUE or a FALSE result. The point of using pseudo-code is to avoid the lengthy and tedious presentation of details whose construction can be reasonably considered to be feasible and whose function can be expressed in a short phrase. In summary then: (1) since it is known that the machine-language form of a program is executable on suitable hardware, and (2) it is known that the source-language form of a program can be converted into a machine-language form, and (3) this example illustrates that the source-language form of a program could be generated from a set of diagrams, therefore (4) this example illustrates a method of executing a set of diagrams. So far, this example has served to illustrate the operation of the basic mechanisms of the invention. A further point is to demonstrate how systems built along these lines may be altered or adapted in ways not easily done using conventional techniques. The FIGS. 9A through 12E have some additional characteristics. FIGS. 9A and B express, at the highest level, the desired behavior of the system. FIG. 9A represents the highest level of meaning given to the concept "handle a request for a meeting". (FIG. 9B should be seen only as test-case used to explore the operation of the meaning in FIG. 9A for the purposes of this example.) The diagrams shown in FIG. 10 are transition diagrams, referenced from FIG. 9A above and making references to meanings below them in FIGS. 11A through 12E which represent the lower-level meanings or concepts in the system. This hierarchial view can be seen in FIG. 13 which shows only the primary-parts of the meaning-templates which appear in each of the previous figures. This layering of the levels-of-abstraction in a system is typical of modern-day systems design. What is of interest is the situation in which it is desired to alter such a hierarchial system. The logical flow captured in FIG. 9A, in combination with the meanings given in FIG. 10, has the characteristic of causing a request to be immediately declined as soon as the subject is judged not appropriate. Consider the user who would like to give consideration to the meeting participants prior to declining a request. As always, there are many ways in which the system could be modified to meet this new requirement. An approach that is uniquely supported by the invention is the following: The definition-cluster given in FIG. 9A could have different significance if evaluated in a different context. The evaluation context is determined by the text property of the meaning-triangle, part 103b. If the text in this triangle was changed to "C3", the meanings given in FIG. 10 would not be involved (since these meanings only appear in the meanings-list of context C2). Instead, the meaning given in FIG. 14 would be considered because it is on the meanings-list of context C3. The meaning-template starting with part 190 has been constructed so that it will match a larger candidate-cluster around part 117 in FIG. 9A. Specifically, FIG. 14 will do in one match what FIG. 10 did in two. Note that both parts 117 and 121 will be included in the new match: part 117 will pair with 190 and part 121 will pair with 191. Once this match has been made, the definition-cluster in FIG. 14 will be evaluated and meanings in FIGS. 11A and B and 12A-E will be activated. The following is the output generated as a result of processing the diagrams in FIGS. 9A and B, 14, and 11A through 12E according to the invention:
______________________________________
start
if (my boss is in " the planning group ") {
if (time and place are ok) {
accept request
else {
propose alternate time and place.
}
}
else {
make temporary lists {
appropriate-list ;
inappropriate-list };
while ( the planning group has more individual s) {
examine next individual ;
if ( draft-product-spec reasonable for individual ) {
put this particular individual
at the end of the " appropriate-list ";
}
else {
put this particular individual
at the end of the " inappropriate-list ";
}
}
if ( appropriate-list matches the planning group ) {
if (time and place are ok) {
accept request }
else {
propose alternate time and place. }
}
else {
decline request
}
______________________________________
In the first case, the case involving FIGS. 9A through 12E, the cluster of parts (117-121, and 129-132) were interpreted as two distinct operations, one following the other: "appropriate subject for me?" and "appropriate participants?". In the second case, in which FIG. 10 was replaced by FIG. 14, essentially the same cluster of parts (117-121, and 129-131) was interpreted as a single operation, whose meaning was then free to diverge totally from the significance of the meanings used in FIGS. 10 A and B. In particular, the definition-cluster in FIG. 14 makes reference to "*participants" before referencing the "*subject". Logic Descriptions Following are descriptions of meaning analysis logic components as needed to execute the example discussed above. Each description includes a narrative step-through of the logic function; most descriptions are followed by a code illustration of the logic or a reference to an appendix containing a code illustration. 1.1 Part-Selection-Logic 1.1.1. First-part-logic: If activated for the first time, search the diagram-set for a part whose text is "start" and identify this part as the first-part. Otherwise a definition-cluster is being evaluated, so identify the primary-part of the definition-cluster as the first-part.
______________________________________
if meaning.sub.-- pointer is null then /* first-time */
result = find("start", BE);
else result =
meaning.sub.-- pointer.definition.sub.-- cluster.primary.sub.-- part;
return result;
______________________________________
1.1.2. Next-part-logic: take a part from the working-pool. If the part is a dashed-connector, ignore it and take another part from the working-pool. Once a box or a solid-connector has been taken, see if the part has previously been matched in this instance of meaning analysis. If the part has already been matched, ignore it and take another part from the working-pool. Once a part has been taken which has not yet been matched, identify this part as the next-part. If the working-pool is exhausted before a next-part can be identified, conclude this instance of the meaning analysis process.
______________________________________
loop {
if working.sub.-- pool is empty then terminate MA.sub.-- process;
candidate.sub.-- part = remove(working.sub.-- pool);
if candidate.sub.-- part is in
this.sub.-- context.already.sub.-- matched.sub.-- list then
continue; /* loop back to try another part */
until (candidate.sub.-- part.style is solid or
candidate.sub.-- part.type is box);
return candidate.sub.-- part;
______________________________________
1.2 Meaning-Selection-Logic 1.2.1. First-meaning-logic: identify as first-meaning the first item in the simple list structure that is the context's meanings-list. Make use of a location in working storage that can be used to advance through the current meanings-list. This location must be able to record the last item in the list that has been referenced by meaning-selection-logic while processing this candidate-part in this instance of meaning analysis. Initialize this location to refer to the first meaning in the list.
______________________________________
this.sub.-- context.curr.sub.-- meaning =
head.sub.-- of(this.sub.-- context.meanings.sub.-- list);
______________________________________
1.2.2. Next-meaning-logic: identify as next-meaning the item in the meanings-list which follows the one identified by the location created above. Update this location.
______________________________________
this.sub.-- context.curr.sub.-- meaning =
this.sub.-- context.curr.sub.-- meaning.next.sub.-- meaning;
______________________________________
1.3 Cluster-Match-Loop-Logic 1.3.1. Cluster-match-logic: This logic is given a reference to the primary-part of a meaning-template and a reference to the current candidate-part. Invoke the match-parts-logic to check for a match between the meaning and candidate parts in the current context. If these two parts do NOT match, invoke the get-parts-logic on the candidate part and return the resulting boundary-list along with a report that no match exists. If these parts match, invoke the get-parts-logic to build a "candidate.sub.-- list" consisting of parts referenced by the candidate, excluding parts previously matched in this instance of meaning analysis. Mark the meaning and candidate parts as already-matched in this instance of meaning analysis. Invoke the get-parts-logic to build a "meanings.sub.-- list" consisting of parts referenced by the meaning part. Invoke the recursive-match-logic to see if each part in the meanings.sub.-- list has a corresponding part in the candidate.sub.-- list. If the recursive-match-logic reports a match, exit and report a MATCH and return a "boundary.sub.-- list" of un-matched parts. If a match is not indicated, exit and report NO MATCH. Appendix A contains a pseudo-code representation for cluster-match-logic. 1.3.2. Match-parts-logic: compare the properties of two parts and report if they match. The part from the candidate-cluster will be referred to as the "c-part" and the part from the meaning-template will be referred to as the "m-part". Two parts match if (1) their type and style properties are the same, (2) their directional characteristics are the same and (3) their text properties can be said to match. While parts (in this example) don't have directional properties, their directional characteristics are considered the same if the parts are boxes or when the parts are connectors with the same source/target orientation. The following procedure is used to determine if two text properties match: A. The text property of the m-part is examined to see if it starts with "**" (double asterisks). If it does not, proceed with step B. If the text of the m-part does start with two "*"s, the text properties are considered to match and a circumstance-item is constructed and added to the current circumstances. Before this new circumstance-item can be built, it is determined whether or not the text of the c-part starts with a "*". If so, the circumstances data structure is searched for the most recent circumstance-item whose formal-string field matches the text property of the c-part. The actual-string, actual-part and actual-context fields of this circumstance-item are copied into the corresponding fields in the new circumstance-item. The formal-string field of this new item is then set equal to the text property of the m-part. In addition, this match is marked as a special-case match and match-parts-logic returns control to the logic element which activated it. B. (Performed only if the text of the m-part does not start with "**") the text property of the c-part is copied into an area of working storage and named the "candidate string". Similarly, the text property of the m-part is copied into an area of working storage and named the "meaning string". If these two are identical, they match; C. If there are words in the candidate string which start with "*" each such word must be replace by a string of substitute-text. The current circumstances are searched for the most recent circumstance-item which contains the word in question. If no such item is found, a textual match is not possible. If such an item is found, the text string stored in this item replaces the word in the candidate string. D. Once the substitution of words beginning with "*" in the candidate string has been completed, a match is considered to exist if the strings are identical except for words in the candidate string which can be matched with words in the meaning string starting with "*". Note that when such associations are made, any number of words in the candidate string may be associated with a single word (starting with "*") in the meaning string. For each such association made, a circumstance-item is constructed. Every circumstance-item has the following structure:
______________________________________
Formal-String:
<the text of the meaning token>
Actual-String:
<the associated string, if any>
Actual-Part:
<the associated part, if any>
Actual-Context:
<the context in which the match occurred>
______________________________________
When the meaning token starts with a single "*", a string association is made and the actual-string field of the circumstance-item contains the matching string from the c-part and the actual-part field is empty. When the meaning token starts with a double "*", a part association is made and the actual-part field of the circumstance-item contains a pointer to the matching c-part and the actual-string field is empty. Appendix B contains a pseudo-code representation for match-parts-logic. 1.3.3. Recursive-match-logic: compares a meanings.sub.-- list with a candidate.sub.-- list as follows: A. examine each possible pairing of an m-part from the meanings.sub.-- list and a c-part from the candidate list. B. for each paring proceed with step C. C. apply the get-parts-logic to the m-part to build a list of "meaning.sub.-- grandchildren", D. invoke match-parts-logic on the m-part and c-part to see if they match, E. if they DO NOT match, put the c-part on a list of unmatched c-parts, pick another c-part and continue with step D. (If all c-parts have been examined, a match is not possible--exit this invocation of recursive-match-logic, reporting NO MATCH). If step D resulted in a special match, continue processing with step H. Otherwise, step D must have resulted in an ordinary match, so apply the get-parts-logic to the c-part in order to build a list of "candidate.sub.-- grandchildren". F. if the list of meaning.sub.-- grandchildren is not empty, invoke the recursive-match-logic on the meaning.sub.-- grandchildren and candidate.sub.-- grandchildren lists and save the boundary.sub.-- list that was generated. If the list of meaning.sub.-- grandchildren is empty, apply the get-parts-logic to the c-part in order to build a boundary.sub.-- list. Exclude dashed-connectors from this list. G. add any parts in the boundary.sub.-- list build in step F to the result.sub.-- list being maintained for this invocation of the recursive-match-logic. H. move all parts in the list of unmatched c-parts back onto the candidate.sub.-- list (this will allow them to be paired with other parts from the meanings.sub.-- list). Advance to the next pair of m-parts and c-parts, and continue with step C. When all m-parts have been matched, continue with step I. I. add any c-parts that remain on the candidate.sub.-- list to the result.sub.-- list except for: (i) any dashed-connectors or (ii) solid-connectors whose target property references a part in the candidate-cluster explored so far. J. exit, report a MATCH, and return the result.sub.-- list as the boundary.sub.-- list computed by this invocation of recursive-match-logic. Appendix C contains a pseudo-code representation for Recursive-match-logic. 1.3.4. Get-parts-logic: build a list of parts which are referenced by a given part, subject to given constraints. The list is built via the following procedure: A. loop through the properties of the given part. B. for each source-of or target-of property, examine the referenced connector. If it is a solid-connector or if the given constraints permit any style of connector, then add this connector to the list. C. for each source or target property, examine the referenced part. If the given constraints permit, examine the text property of the part. If the text starts with a word that begins with two "*"s, search the current circumstances for the most recent circumstance-item containing this word. Add to the list the part that is associated with this word in the circumstance-item (this how a part-substitution is performed). If the text does not start with two "*"s, add the part to the list. D. examine each part that has been added to the list and eliminate any part which has already been matched in this instance of meaning analysis. E. exit, returning the list as the result of the get-parts-logic. Appendix D contains a pseudo-code representation for Get-parts-logic. 1.3.5. Match-loop-control-logic:process a new result-item each time through the cluster-match-loop. There are two cases: (1) when the result-item indicates failure, and (2) when the result-item indicates success. In the first case, when the result-item indicates failure, the next-meaning-logic is activated to see if there are more matches to be attempted. If another meaning is found, match-loop-control-logic returns to meaning analysis. If all meanings have been tried and no match has been found, activate the primitive-action-logic for the candidate-part. Once the primitive-action-logic has finished, it returns to match-loop-control-logic who copies the boundary-list from the result-item into the working-pool (doing this in a way which ensures that there are no duplicates). Finally, all circumstance-items built during the unsuccessful match attempt are discarded, and the match-loop-control-logic returns to meaning analysis with an indication that all meanings have been examined. If, in the second case, a result-item indicates success, the definition-cluster associated with the matched meaning will be immediately analyzed by a new instance of meaning analysis. Once this separate instance of meaning analysis has concluded, it returns here to match-loop-control-logic who now (1) copies the boundary-list from the result-item into the working-pool (ensuring no duplicates), (2) discards all circumstance-items built during the (successful) match just processed, (3) marks the current candidate part as having been matched in this instance of meaning analysis and (4) returns to meaning analysis with an indication that the match-loop is finished with the current candidate-part. 1.4 Primitive-Action-Logic The text property of the part subjected to primitive-action-logic is examined, word-by-word. If a word does not start with a "*", it is simply copied to an output file If a word starts with a "*" the circumstances data structure is accessed for information associated with the word. If there is only one "*" at the start of the word, a textual substitution is made and the substitute text is copied to the output file. If the word begins with "**", the part associated with the word (via a circumstance-item stored in the current circumstances) is subjected to meaning analysis. Once this part has been fully processed, the primitive-action-logic continues processing with the word following the one beginning with "**". Best Mode The best mode of the invention is executed on a commercially available IBM/PC-compatible microcomputer and makes use of the following commercially available software products: 1. The "Microsoft MS-DOS" operating system, version 3.3 from Microsoft Corporation, One Microsoft Way, Redmond, Wash. 98052-6399. 2. The Microsoft Windows graphical Environment, version 3.0, also available from Microsoft Corp. 3. The "Microsoft System Development Kit for Windows"; also from Microsoft. 4. "Borland C++" and its associated windows libraries, object files, and Dynamic Link Libraries (DLLs) from Borland International, Inc., 1800 Green Hills Road, Scotts Valley, Calif. 95067-0001. 5. The "TIER C++ Class Library for MS-Windows" and its associated object files and DLLs from Sturmer Hauss Corp. 685 W. Long St., Stephenville, Tex. 76401. System Decomposition into "Files" Clearly, systems constructed according to the invention have the potential to incorporate a very large number of individual parts. As a practical expedient, the current embodiment allows the collection of parts which make up a single system to be decomposed into a number of individual "files" (as defined by the MS-DOS operating system). The most fundamental type of file used by the prototype is known as a "rendition" or "rendition file". A rendition file is a collection of individual parts. Concurrently, the embodiment's diagram editor (also called the "rendition editor") permits only one file at a time to be edited. Another type of file known as a "library file" can be used to group together one or more other files in order to provide for more convenient file management. A library file can make reference to other library files as well as to rendition files. At the basic conceptual level, the decomposition of a large system into separate library and rendition files has little significance other than to limit the scope of diagram editing and to impose a restriction on the specification of contexts. This restriction has to do with the way that contexts other than the default context are diagrammatically defined. In the current embodiment, a default (or global) context is presumed to exist despite the fact that the user has not constructed a part to represent the default context. This context represents a special case because, in effect, every other part in a system is considered to be encompassed by this default context. The diagram editor permits the user to create additional contexts by drawing a solid, bold rectangular box. Meaning triangles placed within such a solid, bold box are deemed to be meanings contained within the context associated with the box. This approach has the effect of limiting all contexts other than the default context, to the file in which the box that represents the context appears. This limitation is largely mitigated by the "::import" facility that was described in the example. This facility makes use of the text property of a context (or rather the solid, bold box that represents a context) to specify: 1. A Name: which is the textual identifier associated with the context; and 2. An Import-List: which is a list of the identifiers of other contexts whose meaning-lists are to be added to this context's meaning-list. An alternate means of specifying a context-switch The example has described a means of specifying the definition-context component for a meaning. In the example, the text property of the meaning-triangle is used to specify the name of the context that is to be used as the definition-context. The sole purpose of a meaning's definition-context component is to identify the context that will be used by the meaning analysis procedure when evaluating the individual parts which make up the definition-cluster. The definition-context field is one way to provide the system with the ability to perform a "context-switch". Using this method, a context-switch is permitted whenever a new instance of the meaning analysis process is created. An alternative, and somewhat more general, method of providing the ability to change contexts can be achieved by adding this capability to one or more of the primitive-action-logic components used within a system. The existing embodiment uses such a technique. Specifically, the primitive-action-logic component of every context can recognize a text property of "::set.sub.-- context". Whenever primitive-action-logic is applied to a part whose text property equals "::set.sub.-- context" the system will switch to the smallest context which encloses this part. Note that only contexts which occur in the same file as the ::set.sub.-- context part are considered here. If a ::set.sub.-- context is encountered for which no explicitly enclosing context can be found, the global (or default) context is selected and a switch to this context occurs. One consequence of this approach is that the definition-context field of the meaning data structure is not required. Instead, the job of specifying a new context is left to the definition-cluster itself. While this is more burdensome and tedious to describe, it might be considered more flexible because it permits a single definition-cluster to switch to more than one context in the course of its evaluation. Optimization: Storing Match Information There are many opportunities to apply techniques which are well-known to computer science and whose application can result in significant improvements in the operational efficiency of the invention. One class of improvement involves generating supplemental information during the meaning analysis process and storing it for later use. An example of this class of improvement is implemented in the current embodiment. The basic approach is to store extra information with each part that has been evaluated as "current candidate-part" and subjected to cluster matching. This extra information is stored in such a way that it can be retrieved the next time the part becomes the current candidate-part. The information is then used to eliminate or reduce the search-time associated with finding the meaning or meanings which can be said to match this candidate-part. The embodiment calculates this information when it has finished processing a given candidate-part. It stores with this part additional properties which indicate whether or not a match occurred and, if so, what meaning was matched and in what context. The next time this part becomes the current candidate-part, these properties are accessed by the meaning analysis process prior to entering the match-loop and, in many cases, can be used to eliminate (or at least reduce) the cluster-matching that would otherwise need to occur. There are a variety of sophisticated compiler optimization techniques, for example, which can be readily applied to the invention. Optimization: Storing Primitive-Action Information Another type of optimization is based on the observation that systems will often be constructed in such a way that there are certain candidate-clusters which are repeatedly evaluated in the same context and in light of the same circumstances. There is a certain degree of processing required to discover all of the primitive-actions which will be executed as a result of a full meaning analysis of a given candidate-cluster. There are cases in which it is possible to avoid repetitive meaning analysis processing by storing a representation of the sequence of primitive-actions which result from a previous analysis. Such cases would be recognizable to an experienced compiler writer. In general, a sequence of primitive-actions can be stored as a property of the primary part of the candidate-cluster which generated that sequence. The next time this part becomes the current candidate-part, this sequence of primitive-actions can be executed instead of repeating the full meaning analysis. This should be thought of as an optimization because its purpose is not to alter the flow of primitive-actions performed by a system, but, rather to eliminate unnecessary and time-consuming processing. It should be noted that proper implementation of this optimization is not as easy as it sounds because, for example, it is possible that a match between a given candidate-cluster and a given meaning-template might depend upon the state of the circumstances data structure at the time that the match occurs. If this were to be the case, the sequence of stored primitive-actions might not be valid for a later match that took place under different conditions. A catalog of "match-dependencies" can be constructed by carefully considering the various situations under which circumstance-items are constructed and exactly how they contribute to a successful match. Given such a catalog for any particular implementation, one can analyze any particular match and determine its specific dependencies. The building of such "dependency graphs" is familiar to compiler writers. In many cases, it may be less costly to test for such dependencies than to unconditionally | ||||||