Data processing: presentation processing of document – operator i – Presentation processing of document – Layout
Reexamination Certificate
2000-11-27
2004-07-27
Shah, Sanjiv (Department: 2176)
Data processing: presentation processing of document, operator i
Presentation processing of document
Layout
C715S252000, C717S147000
Reexamination Certificate
active
06769095
ABSTRACT:
FIELD OF THE INVENTION
The present invention is directed toward a system and method for editing source code templates in a target language utilizing a graphical user interface. More particularly, the present invention is directed to a system and method in which a programmer parameterizes target source code with contextual meta-data provided by the application domain. He determines the repetitive and nesting structures of the code which is visually clear, easy to maintain and fully consistent.
BACKGROUND OF THE INVENTION
It is commonly said that object-oriented techniques help model the real world more closely than conventional techniques and it is mostly done using modeling tools. While building a complex system, software programmers and clients can easily establish their common vocabulary, which helps them refine system requirements effectively. Object-oriented techniques also help them build a system that is easily extensible, especially when frameworks are used.
Modeling tools are used by programmers or analysts to depict the business purpose of an application in a logical way that is abstracted from the “physical implementation” of the specific programming language, operating system and the hardware that the application runs on.
One of the reasons that object-oriented programming is becoming more popular is that software reuse is becoming more important. Developing new systems is expensive, and maintaining them is even more expensive. A recent study by Wilma Osborne of the National Bureau of Standards suggests that 60 to 85 percent of the total cost of software is due to maintenance (Ware Meyers. Interview with Wilma Osborne. IEEE Software 5(3): 104-105, 1988).
Programmers traditionally use “cut and paste” techniques to facilitate the implementation of repetitive and near-repetitive methods. A kind of template is a block of target source code annotated where the change is needed, saved in a common location and reused by a programmer with some manual interventions. The programmer who created that block of target source code or another programmer can then re-use these lines by copying and pasting the appropriate lines into the code he is working on and making the appropriate changes for that particular usage. This method is error-prone and time-requiring since, in addition to copying the right lines of codes, sometimes repeatedly, the programmer has to replace all appropriate components' names by their appropriate equivalents. This is called coding with annotated source code template.
Some generation software tools allow the programmer to use textual generation templates, which consist of parameterized lines of source code, to create new operations or components. These textual generation templates enable programmers to specify the selected components for which they want to generate code by using filter variables, as well as to define the complete specifications of the operation using target source code that is parameterized by context variables. Component and attribute filter variables are used by the code generator as selection criteria to filter information from the modeling tool and to populate its dynamic generation context. Context variables refer to a component or attribute property name that the code generator replaces with the actual property value associated with the current component or attribute found in its dynamic context.
These code generators are used to deliver generation-time control and customization for integrating frameworks with components developed using today's modeling tools and programming languages. Textual generation templates are created with programmer's instructions that are given using a rigorous syntax and are used by the source code generator to replace any context variable in the provided parameterized source code. For example, a line of code could be: “persistenceSchema=new PersistenceSchema(“%001”); with (&class name)”, in which “%001” is a parametric symbol representing where the value of the context variable would be put by the generator, for example, the context variable “<class name>”. The programmer has to create textual generation templates using these symbols. A mental list of such symbols must be built up in order for the programmer to stay consistent in naming the components, especially when there is more than one parametric symbol from %001 up to %999 that needs to be respectively associated with a context variable. A parametric symbol can appear more than once in the parameterized source code since it is always associated with the same context variable. Such symbols are not user-friendly in the sense that they do not enable the programmer to type code, as he would normally do in a non-parameterized form. In addition, these symbols have to be defined within the lines of codes to ensure proper interpretation by the generator. In the previous example, the instruction “with (&class name)” has to be added in order to instruct the generator that the parametric symbol “%1” would be replaced by the current value of the context variable associated with the current class found in the dynamic context of the generator. Also, when certain portions of the code have to be repeated more than once for attributes of a component that address the selection criteria provided by filter variables, an instruction of the kind “repeatForEach &attribute private instance using (&attribute name; &attribute attributeClassName;” would have to be included to ensure the near-repetitive operation. The code generator, in this case, will take the templates and transform then into source code using a model declaration for the system and filter variables that are defined in order to specify which templates are used for which components.
Instead of using such a syntax relying on keywords (i.e. %001) and definitions of such keywords (i.e. repeatForEach . . . using . . . or with . . . ), a programmer could decide to concatenate the parameterized code with the result of an instruction performed by an algorithm implemented in a given programming language. For example, like is taught in U.S. Pat. No. 5,675,801 to Lindsey, the software would solve the expression in parameterized form with the result of another operation. More specifically, in an example of the declaration source code template in the C language for data-oriented object known as the NumericDataItemObject and representing the C variable called “IdNumber”, an instruction of the kind “int <self VarName>;” could be used, in which “int” and “;” are the source code fragment portion of this source code template and the directive for the generator is “<self VarName>”. In this example, the “<” and “>” are arbitrary delineators indicating the beginning and the end of a generator directive. In this case, the object identifier is the token “self”, which refers to the object being asked to generate itself, namely “IdNumber”, its variable name. The message identifier is the token “varName” which will be the message sent to the object “self”. This message tells the object “self” to return the string representing itself when used in a variable declaration. In this example for Lindsey, the NumericDataItemObject, whose name is “IdNumber”, will return the string “idNumber”. The resulting target language source code fragment is “int idNumber;”, which is a C language source code fragment.
The use of colors and other display artifacts have been used in source code editors to increase the understanding of the procedural flow of an algorithm but never used to describe the structure of the information provided, such as repetitive and/or nested Context Blocks. For example, an If-then-else statement using different colors for its condition expression, its true-expression and its false-expression that have to be executed based on the result of the conditional expression. Display artifacts have never been used to illustrate the fact that the same if-then-else expression is repeated within a given component algorithm for every attribute meeting a set of selection criteria.
SUMMARY OF THE INV
Brassard Michel
Shingarov Boris
(Ogilvy Renault)
Chabot Isabelle
Codagen Technologies Corp.
Shah Sanjiv
LandOfFree
Hierarchically structured control information editor does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Hierarchically structured control information editor, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Hierarchically structured control information editor will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3215541