Source: http://www.google.com/patents/US5640576?ie=ISO-8859-1&dq=6,757,682
Timestamp: 2014-03-15 06:17:06
Document Index: 445984065

Matched Legal Cases: ['arts 511', 'arts 521', 'arts 511', 'arts 521', 'arts 521', 'arts 521', 'art 523', 'arts 511', 'art 52']

Patent US5640576 - System for generating a program using the language of individuals - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA program generating system uses the language of an individual to write a program in expressions with words of the programmer himself which can easily be understood from the side of an application object, and to generate expressions according to a designated programming language from the program written...http://www.google.com/patents/US5640576?utm_source=gb-gplus-sharePatent US5640576 - System for generating a program using the language of individualsAdvanced Patent SearchPublication numberUS5640576 APublication typeGrantApplication numberUS 08/244,561PCT numberPCT/JP1993/001331Publication dateJun 17, 1997Filing dateSep 17, 1993Priority dateOct 2, 1992Fee statusLapsedAlso published asWO1994008290A1Publication number08244561, 244561, PCT/1993/1331, PCT/JP/1993/001331, PCT/JP/1993/01331, PCT/JP/93/001331, PCT/JP/93/01331, PCT/JP1993/001331, PCT/JP1993/01331, PCT/JP1993001331, PCT/JP199301331, PCT/JP93/001331, PCT/JP93/01331, PCT/JP93001331, PCT/JP9301331, US 5640576 A, US 5640576A, US-A-5640576, US5640576 A, US5640576AInventorsTakahisa Kimura, Kaname KobayashiOriginal AssigneeFujitsu LimitedExport CitationBiBTeX, EndNote, RefManPatent Citations (6), Referenced by (21), Classifications (5), Legal Events (6) External Links: USPTO, USPTO Assignment, EspacenetSystem for generating a program using the language of individualsUS 5640576 AAbstract A program generating system uses the language of an individual to write a program in expressions with words of the programmer himself which can easily be understood from the side of an application object, and to generate expressions according to a designated programming language from the program written with the words of the programmer himself. The program generating system has a first processor for transforming a user's linguistic expression into an initial role tree, a second processor for detailing and transforming a vocabulary expression of said initial role tree into a beginning role tree, a third processor for detailing and transforming said beginning role tree into an ending role tree, and a fourth processor for generating a source code of a programming language from said ending role tree. The first processor transforms the user's linguistic expression into a description in the form of the role tree. The second processor applies vocabulary transformation rules to the initial role tree to detail the vocabulary expression. The third processor applies role tree transformation rules to the beginning role tree to detail the beginning role tree. The fourth processor applies a set of patterns and a set of vocabularies to the ending role tree to generate a source code of a programming language.
FIG. 6 shows an example of the content of an initial document file in which an initial document 30 is described. The example shown in FIG. 6 illustrates a situation for calculating a change. The initial document 30 comprises a symbol string composed of delimiter symbols and a row of characters separated by delimiter symbols that belong to the symbol string. The delimiter symbols are defined by being sandwiched between meta delimiters ".box-solid." at the beginning of the file, and characterized by the relative position in the symbol string and by being uniquely identified in the string of delimiter symbols. Insofar as the above conditions are satisfied, delimiter symbols can be selected with freedom. A file in which a string of delimiter symbols is defined at the beginning and which is processed by being signified depending on the order of appearance of the delimiter symbols is referred to as a "delimiter file".
FIG. 17 is a diagram showing an example of the content of a vocabulary transformation rule file. The vocabulary transformation rule file has a file name "tst.ivr". A row of characters up to a delimiter symbol ".tangle-solidup." represents one rule. The row of characters from the beginning to the delimiter symbol "→" in one rule represents the left-hand side of the rule, and serves as a pre-conditional part. The row of characters from the delimiter symbol "→" to the delimiter symbol ".tangle-solidup." represents the right-hand side of the rule, and serves as a post-conditional part. The row of characters sandwiched between the delimiter symbols "" and "", with these delimiter symbols inclusive, represents a variable. The variable as a whole is regarded as a delimiter symbol, and the rows of characters on the left-hand side of the rule, which are separated by the variable, are called keys, respectively. The keys are used as a clue for determining the value of the variable by matching the left-hand side of the rule with the vocabulary view. If the matching is successful, then a certain character string is obtained as the value of the variable. The value of the variable obtained by the matching is substituted in the position of the variable on the right-hand side of the rule, thus generating a character string from the right-hand side of the rule. The generated character string is used as a character string for replacing the vocabulary view.
A matching variable which is not present in a preconditional part may appear in a post-conditional part. For example, " 24 is such a matching variable. In this case, a system sharp is used to automatically generate a totally novel character string (a character string with a system sharp at its beginning).
FIGS. 25(A) through 25(D) are diagrams showing various variables that can be contained in role tree transformation rules. In FIGS. 25(A) through 25(D), rows of characters preceded by the symbol " positions of a view name, a role pattern name, a rule name, and a subview name, are variables for matching one value. As shown in FIG. 25(B), the symbol "�" at the beginning of the view name represents "existence negation", i.e., indicates that there is no view definition of part, it means deletion.
A block variable preceded by the symbol "@" may be placed in the subview. The symbol "@" is a matching variable which takes its value from a row of successive subviews of an indefinite-length pattern. Whereas the variable " elements in a row. While the variable " pattern variable, and a role variable, the variable "@" matches only a row of successive subviews of an indefinite-length pattern. In FIG. 25(C), a row of subviews preceding " following " empty subviews.
A pattern and a role can simultaneously be represented by "*", and can be handled as a blank variable. The blank variable has its value taken from a path on a role tree which interconnects a view and a subview of the view definition which contains the blank variable. In FIG. 25(D), this corresponds to the condition that "there is a role path from a view "
The role tree transformation rules for generating a program structure have 15 delimiter symbols ".box-solid.=(:,)#{�→} .box-solid.". The delimiter symbol ".box-solid." is a meta delimiter. The delimiter symbols "=(:,)#" are the same as those used in a role tree. Among the remaining delimiter symbols "{�→} are peculiar to these transformation rules.
FIG. 32 is a diagram showing a process of expressing a role tree transformation rule in the third processor. As with the role tree table, a role tree transformation rule table tabulates view conditions which constitute a rule, as units each composed of four items, i.e., a view name, a pattern name, a role name, and a subview name, which constitute view conditions. The role tree transformation rule table also has a set of additional information per unit of four items, the additional information including a matched status recording a matched position at the time a unit of four items is compared with a role tree, a matching condition indicative of whether there is a negating operation "�" relative to a matching/adding process, etc. For example, if the role tree transformation rule is given as "{ action(condition:failure, content: then the role tree transformation rule table contains two roles "condition", "content" and two roles "content" "label" for pre- and post-conditional parts of the role tree transformation rules, and furthermore information regarding whether there is a negating symbol "�" and a matched status with respect to each of the above four roles.
FIG. 40 is a diagram showing a set of patterns inherent in problems. The set of patterns has a file name "tst.pat". In the illustrated example, those character strings which are representative of patterns related to the calculation of change are collected from role patterns. Those character strings on the left-hand sides of the delimiter symbols "=" are character strings representing pattern names. Those character strings on the right-hand sides of the delimiter symbols "=" up to the delimiter symbols ".tangle-solidup." are character strings representing the contents of patterns. The delimiter symbol "=" assigns a character string to a role pattern of fixed length. A character string which is sandwiched between "" and "" indicates a role name. A character string which is not sandwiched between "" and "" describes an inter-object relationship which defines a role. A row of characters separated by a role name sandwiched between "" and "" is called a "key". If a key is indicated by k and a role name by r, then a general format of a character string assigned to a fixed-length role pattern is given as:
FIG. 41(A) and FIG. 41(B) are diagrams showing a set of common-use patterns by way of example. The set of common-use patterns has a file name "begin.pat". In the illustrated example, those patterns which are related to the expressions of source codes of a macro assembler programming language are collected from role patterns. As with the delimiter symbol "=" the delimiter symbol "→" assigns a character string to a pattern. However, this delimiter symbol assigns a character string to a role pattern of indefinite length. A character string assigned to a role pattern of indefinite length is arranged as assigning a repeated portion successively to subviews. The repeated portion is indicated by sandwiching a repeated character string with delimiter symbols "&lt;", "&gt;", and has a general format of k.sub.1 r.sub.1 k.sub.2 . . k.sub.n r.sub.n k.sub.n+1 &gt;K.sub.1 R.sub.1 K.sub.2 . . K.sub.m R.sub.m K.sub.m+1 &gt; κ. A character string ahead of the delimiter symbol "&lt;" is referred to as a head, a portion sandwiched between the delimiter symbols" &lt;", "}" as a repeated portion, and κ is called a tail. In a character string assigned to an indefinite-length role pattern, a character string sandwiched between the delimiter symbols "", "" does not have a meaning as a role name, but is simply indicative of a position to which a character string generated with respect to a subview is assigned. In an expression generating operation with respect to an indefinite-length role pattern character string, a key output and an expression character string generation with respect to a subview are repeated taking care of the following points: First, since a role name in a role pattern character string does not give a clue to obtain a subview name, a subview name is determined from the side of a role tree. To this end, the position on a role pattern character string and the position on a row of subviews of a role tree are used for determining an output status. Secondly, a key immediately before the delimiter symbols "&lt;", "&gt;" has no subview. Therefore, when a key is outputted at this position, the position of a subview on a role pattern is not updated. Thirdly, a status indicating the generation of a key output immediately before the delimiter symbols "&lt;", "&gt;" is established in order to determine whether a key output is immediately before or after the delimiter symbols "&lt;", "&gt;".
FIG. 42 is a diagram showing a set of vocabularies representative of a collection of object names inherent in problems, by way of example. The set of vocabularies has a file name "tst.voc" In the illustrated example, those character strings which are explanatory of objects related to the calculation of change are collected from vocabulary view character strings. Character strings on the left-hand sides of the delimiter symbols "=" are character strings indicative of view names, and those on the right-hand sides of the delimiter symbols "=" up to the delimiter symbols ".tangle-solidup." are character strings indicative of the contents of views.
The delimiter definition parts 511, 512, 513 are composed of respective trains of all delimiter symbols (two delimiter symbols in this embodiment) extracted from at least the data parts 521, 522, 553 and arranged in a predetermined order (e.g., "" after ""), the delimiter symbol trains being sandwiched between symbols (delimiter symbols ".box-solid." provided to distinguish the delimiter definition parts 511, 512, 513 from the data parts 521, 522, 523) which are not used in the data parts 521, 522, 523. It is assumed that the data parts 521, 522, 523 employ different delimiter symbols, per every document file of 501, 502, 503, i.e., the document file 501 employs delimiter symbols "", "" for the document file 502, the document file 503 employs delimiter symbols "[", "]", and data part 523 employs delimiter symbols ".left brkt-top.", ".right brkt-bot.".
The delimiter symbol processor 51 which has started reading the document file 50i reads a symbol train from the first delimiter symbol ".box-solid." to the next same delimiter symbol, adds numbers to the delimiter symbols in the order in which they are read, and registers them in the delimiter symbol storage unit 53 in a processing step S16.
FIG. 58 is a diagram illustrative of symbol identifiers registered in the delimiter symbol storage unit 53. In FIG. 58, the delimiter symbol processor 51 reads a symbol train from the delimiter symbol ".box-solid." at the beginning of a file to the next same delimiter symbol, i.e., for the document file 501, for example, the delimiter symbol processor 51 reads the delimiter symbols "", "", adds numbers to them in the order in which they are read, that is, adds "1" to the delimiter symbol "" and adds "2" to the delimiter symbol "", and registers them in the delimiter symbol storage unit 53.
In FIG. 57(A) and FIG. 57(B), when the delimiter symbol processor 51 reads the next delimiter symbol ".box-solid.", it recognizes that it has completed the reading of the delimiter definition parts 511, 512, 513, and then starts reading the data part 52i (i=1, 2, 3) in a processing step S17.