[go: up one dir, main page]

EP1196846A1 - Meta-language for c++ business applications - Google Patents

Meta-language for c++ business applications

Info

Publication number
EP1196846A1
EP1196846A1 EP99937436A EP99937436A EP1196846A1 EP 1196846 A1 EP1196846 A1 EP 1196846A1 EP 99937436 A EP99937436 A EP 99937436A EP 99937436 A EP99937436 A EP 99937436A EP 1196846 A1 EP1196846 A1 EP 1196846A1
Authority
EP
European Patent Office
Prior art keywords
script
recited
stack machine
user
language
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP99937436A
Other languages
German (de)
French (fr)
Inventor
Andreas Hohmann
Erik Duymelinck
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CGI Technologies and Solutions Inc
Original Assignee
American Management Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by American Management Systems Inc filed Critical American Management Systems Inc
Publication of EP1196846A1 publication Critical patent/EP1196846A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/31Programming languages or programming paradigms
    • G06F8/315Object-oriented languages

Definitions

  • microfiche appendix having 3 microfiche and 262 frames is included herewith containing the detailed design specification for the present invention.
  • the present invention is directed to a meta-language for C++ business software applications. More particularly, to a C++ metalanguage that can access C++ objects and interface to a run-time type identification mechanism that enables the changing of a C++ meta- language scripts without the need to recompile C++ source code or for the user to be familiar with a programming language.
  • Meta-languages were developed to eliminate the programmer from the loop, but did not offer access to C++ objects.
  • CML C++ Meta- Language
  • CML C++ Meta- Language
  • CML C++ Meta-Language
  • the CML provides a scripting layer on top of and interfacing to a C++ layer.
  • the use of a meta-language allows to control the functionality at run-time, using conditions and processing rules, stored in reference data or plain text files.
  • Business functionality, implemented using the CML can be changed without recompilation of C++ code and due to the higher level of abstraction of the CML, non-technical staff can maintain meta-language scripts.
  • Figure 1 is an overall software configuration of the present invention.
  • Figure 2 is a diagram showing the interaction between the CML source script, the CML Framework and the business application in the present invention.
  • Figure 3 is a flowchart showing the method of creating and executing a CML script as shown in figure 2 as practiced by an embodiment of the present invention.
  • Figure 4 is a diagram showing the architecture of the stack- machine in the present invention.
  • a scripting language is a high-level language providing basic programming constructs.
  • a meta-language is a high-level language that is directly tied to a specific application.
  • Reference data is usually stored on a permanent storage such as a database and is used by processing the data as reference values for validation or conditional logic.
  • Business logic is the implementation of a business process using rules and processing logic. If a business process or associated rules need to be changed, the business logic must also be modified.
  • a class is a program module that combines logic and state.
  • An example of a « class is the Event class that is used to represent telephone calls.
  • An object is a specific instance of a class.
  • An example of an object is the instance of a Event object that represents a specific telephone call.
  • the Event object is an instance of the Event class, its state represents the data of the specific telephone call.
  • An attribute is part of an object's state and defines some property of the class.
  • An example of an attribute in an Event object is the originating phone number of the telephone call that is represented by the object.
  • a method is part of a class or object and performs specific operations. Methods can be called by other objects or by the object itself.
  • An example of a method in an Event object is a method providing the call duration. The duration can either be calculated (from start and end time) or simply provide access to a duration attribute in the Event object.
  • a reflection layer provides a mechanism to browse objects at runtime for their type, attributes and methods. This facilitates late binding where it is determined at runtime what operations are executed.
  • a strongly typed system allows the use of typed data in programs to be checked when the program is compiled. For example it can be verified whether a return value of a certain type can be assigned to a variable of a certain type.
  • a type inference in a language providing type inference, the types of literals, values, and expressions in a program do not have to be declared by the programmer but are calculated once the program is compiled.
  • the C++ Meta-Language (CML) framework 34 shown in Figure 2 comprises compiler 120 and stack machine 100 and provides applications with tools necessary to compile and execute metalanguage scripts.
  • the CML framework is coupled with a C++ reflection layer, also referred to as run-time type identification ("RTTI")
  • meta-language layer 10 without the existence of the metalanguage layer 10, all business application logic would be traditionally implemented in the application core layer 20 in form of C++ business objects. In order to change to the business logic, C++ code would have to be modified, the application core layer would have to be recompiled and re-tested. Non-technical staff, familiar with the business process, could not perform these modifications. However, with meta-language layer 10, business logic can be implemented in the meta-language layer 10 by the non-technical staff. The metalanguage 10 provides a higher level of abstraction than C++ and can more easily be maintained by non-technical staff. Business logic contained in meta-language 10 can be modified without the extensive effort of rebuilding the application. A drawback of the meta-language layer 10 is performance. Processing implemented in meta-language 10 is executed more slowly than processing implemented in application core 20 C++ objects. Therefore, a balance of flexibility and performance needs to be considered when planning where to place business logic.
  • meta-language layer 10 contains the specification of the business logic. This meta-language layer 10 covers the functionality that is subject to frequent change such as the output formats or processing rules. The meta-language layer 10 is based on building blocks provided by the application core 20. Most of the complex logic of the business functions is contained in the meta- language layer 10.
  • the application core layer 20 includes application-specific C++ classes. This application core layer 20 also contains the hard-coded business functionality that is not embedded in the meta-language layer 10. The application core layer 20 is built on top of the infrastructure layer 30 for the particular kind of application (batch, online, server) intended. Performance critical processing has to be carried out by low level C++ objects and is implemented in the application core layer 20.
  • the infrastructure layer 30 provides services that can be used by all applications.
  • the infrastructure offers a standard interface to the operating system 40 including additional services such database access, logging, messaging, and profiling.
  • the infrastructure layer 30 provides common services that can be used by ail applications built on top of the infrastructure.
  • the infrastructure layer 30 also provides a reflection layer (RTTI) 32 that allows for access to attributes and methods of C++ objects by name as required by the scripting layer.
  • RTTI reflection layer
  • a reflection layer is a conventional mechanism for changing structure and behavior of software systems dynamically.
  • the reflection layer provides information and access to system properties and makes the software self-aware.
  • Programming languages, such as JAVA contain reflection layers as a feature of the language itself. Implementation of reflection layers is described in A SYSTEM OF PATTERNS, by Frank Buschman et. al., Wiley and
  • CML C++ meta-language
  • the CML framework 34 shown in Figure 1 uses a combination of techniques to provide the meta-language layer 10 on top of application core layer 20.
  • the main features of the CML framework 34 comprises:
  • CML is a strongly-typed compiled language, as illustrated in the discussion of table 1 below.
  • the target of the compilation is not machine code, but a sequence of instructions for a small virtual machine (stack machine 100 shown in Figure 2).
  • this stack machine program 80 (SMP 80) is contained in a C++ structure and executed by a stack machine 100 realized in C++ when executing the program.
  • This approach ensures that most of the burden of translating the CML source script 60, shown in Figure 2, can be carried out before actually executing the program.
  • the compiler 120 shown in Figure 2, can check the types of all operations avoiding type errors during the execution of the program.
  • the compiler can generate typed operations for the stack machine 100 that can be executed much faster than dynamically typed operations.
  • Table 1 below depicts a simple CML script 60, shown in figure 2, provided for illustrative purposes only dealing with a very simple example of bill formatting.
  • the purpose of this script is to print all events contained in the given document sorted by start time. It also has to compute the total duration as well as the total charge grouped by "event group”. As a final operation the sample program prints the results.
  • C++ classes In the sample program shown in table 1 , it is assumed that three C++ classes have been defined with run-time type information using the RTTI mechanism. These three C++ classes are the Document class, Invoice class, and Event class.
  • the Document class contains a list of events which is simply called events.
  • the Invoice class extends the Document class by an integer attribute number.
  • An Event class has four attributes, the start time, the duration, the charge, and the group. Moreover, it provides a method getDestination which returns the destination (called number) as a string.
  • Lines 2-4 of table 1 define the first program printEvent which contains the print commands for a single event.
  • the argument type declaration uses a Pascal-like style.
  • Event is the C++ class supplied with run-time type information so that its attributes and methods can be used from CML as shown in Line 3.
  • Lines 7-8 of table 1 show how the Invoice number attribute can be used.
  • a type-check condition such as "is Invoice” automatically changes the type of the variable within the associated block (here, the "then” block of the if-statement). In this way attributes of derived classes can be accessed without any additional type casting.
  • Line 11 of table 1 introduces a new variable. Variables do not have to be declared. They are created with the first assignment, and their type is the type of the value which is assigned to it (here an integer).
  • Line 12 of table 1 defines another new variable which is a list of events. The right hand side of the assignment creates this list.
  • container types such as lists, vectors, tuples and maps, the contained types have to be specified to allow for compile-time type checking.
  • Line 13 of table 1 defines a map (also called associative array) of decimals indexed by strings. For maps, both, the type of the keys and the type of the values, have to be provided.
  • Line 15 of table 1 shows the sort statement for lists. It is one of the CML commands which have been built in for convenience.
  • Line 17 of table 1 starts a loop through the list of event contained in the document.
  • the syntax for the control statements has been chosen to be short but readable (no begin-end, no curly brackets as in some programming languages).
  • Line 18 of table 1 calls the first program printEvent with the current event.
  • Line 19 of table 1 shows the with statement which (as in most scripting languages) allows for using attributes names directly ("duration” instead of "event.duration”).
  • Figure 2 is a diagrams illustrating the data and processing flow in the present invention as well as illustrating the different phases of compilation and execution.
  • Figure 3 is a flowchart showing the method of creating or modifying and executing a CML source script. Both figures will be discussed together to illustrate the processing flow of the present invention.
  • the CML source script 60 is stored on a Datastore (e.g. database or file system) 55 external to the CML source script 60 .
  • a Datastore e.g. database or file system
  • the CML source script 60 can be created and modified with standard text editing tools.
  • An Application intending to execute a CML program contained in a CML source script 60 loads the corresponding CML source script 60 from the Datastore 55 in operation 210 of figure 3.
  • the Compiler 120 is invoked which is part of the CML Framework 34. Compilation is organized into two operations within operation 220.
  • the syntactical analysis of the CML source script 60 is performed that transforms the source text into a parse tree 70, shown in figure 2, reflecting the syntactical structure of the program and the actual translation of the parse tree into the stack machine program 100.
  • Second, a translation process transforms the parse tree 70 into a Stack-Machine Program SMP 80.
  • the implementation of the CML translation uses a set of translator objects, one for each type of parse node (not shown) (e.g., a translator for if-statements, another one for assignments, etc.).
  • a translator for if-statements, another one for assignments, etc.
  • An essential part of the translation process is the handling of types.
  • the CML compiler 120 uses bindings and environments.
  • a binding gives a path (such as "event.duration") a specific meaning (such as "field of type int"). More precisely, a binding maps a path to a variable, field (attribute of an object variable), method, or a CML program that is part of another CML module.
  • An environment manages the bindings during the compilation process. Besides keeping the bindings, the environment also handles the scope of variables and the logic for "with" statements.
  • the environment changes during the compilation as new variables are created or existing ones go out of scope. Those changes are kept in a history that allows for recovering the state of the environment. The history is implemented as stacks (detailed further below) for each bound variable and another stack containing the paths that have been changed.
  • the application calls the stack machine 100 with the SMP 80 and the input data 90.
  • the stack machine 100 executes the SMP 80 and returns the output data 110 to the application. If the CML source script 60 was modified, the application loads the modified version of the script and recompiles it before executing it.
  • the CML framework uses a stack 160 to hold temporary values and a frame 150 to hold variables accessible by an index.
  • the virtual stack machine 100 operates by copying data between stack 160 and frame 150 or act on the stack 160 itself as depicted in Figure 4.
  • frame 150 and stack 160 use vectors of generic values.
  • a stack machine program (SMP) 80 is a sequence of operations 140 which determine the actions carried out with stack 160, frame 150, and output stream 110.
  • the stack 160 is a LIFO system (Last-In, First-Out). Values are retrieved (or popped) from the stack in the reverse order they were added (or pushed) onto it.
  • LIFO system Last-In, First-Out
  • the frame 150 is an indexed storage system, i.e., it can be viewed as a set of numbered cells. Moving a value from or to the frame requires to know the index number of the cell from which a value is read or to which it is written. From the CML point of view, the frame manages the variables used in a program.
  • a called program will always have its own local Frame 150.
  • a Frame 150 is associated with one instance of a SMP 80 only. At startup, it only contains the objects that are the parameters of that program (Input Data 90 shown in figure 2).
  • the output stream 110 is the piace where text is sent to for output. From a CML program, the output stream 110 is the target of print statements. Alternate Embodiments
  • any number of computer languages may be used.
  • Java may be used instead of C++.
  • Different version of UNIX may also be used as well as any comparable operating system.
  • Almost any processor or computer may be used such as a Sun computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)

Abstract

A C++ meta-language ('CML') scripting language implemented on top of C++ providing direct coupling to C++ using a reflection layer. This CML scripting language provides for a high-level object-based scripting language with simple syntax. It also provides for a strongly typed with type inference capability. Using this CML scripting language compilation into internal representation for a stack machine is first accomplished. A Reflection framework (RTTI) allows for direct access to C++ class attributes and methods by name and makes possible for the script to interact with business objects programmed in C++.

Description

META-LANGUAGE FOR C++ BUSINESS APPLICATIONS
Reference To Microfiche Appendix
A microfiche appendix having 3 microfiche and 262 frames is included herewith containing the detailed design specification for the present invention.
BACKGROUND OF THE INVENTION
Field of the invention
The present invention is directed to a meta-language for C++ business software applications. More particularly, to a C++ metalanguage that can access C++ objects and interface to a run-time type identification mechanism that enables the changing of a C++ meta- language scripts without the need to recompile C++ source code or for the user to be familiar with a programming language.
Description of the Related Art
In the past in order to improve the coding, debug and maintenance of business logic high level languages such as COBOL were developed specifically for business applications. However, a skilled programmer in consultation with a person knowledgeable with the application was needed. Development and debug times were long and modification of programs was difficult and expensive.
Meta-languages were developed to eliminate the programmer from the loop, but did not offer access to C++ objects.
Therefore, what is needed is a meta-language that someone without computer programming skills can use and run without recompilation of core C++ application software. Further, what is needed is a C++ meta-language that can be used to configure business logic at run time and which can utilize logic implemented in
C++ business objects.
Existing scripting languages include JavaScript, Tel, Python, ML (Meta Language), VisualBasic and Perl. However, no existing scripting language provides the features of being compiled, strongly typed, type inference, object oriented with direct access to C++ objects along with a reflection layer bound to the C++ language which allows for modification of business logic without recompilation being necessary.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a C++ Meta- Language ("CML") capable of directly interfacing to C++ objects and thereby use the full power and flexibility of an object oriented language. It is also an object of the present invention for a person with no programming skills or limited programming skills to be able to generate a CML script that can perform complex business applications.
It is still a further object of the present invention to allow for scripts to be changed and executed without the need for recompilation of the C++ source code.
It is also an object of the present invention to allow for fast execution of generated scripts. The above objects can be attained by a system and method that provides a C++ Meta-Language ("CML") for C++ business applications. The CML provides a scripting layer on top of and interfacing to a C++ layer. The use of a meta-language allows to control the functionality at run-time, using conditions and processing rules, stored in reference data or plain text files. Business functionality, implemented using the CML, can be changed without recompilation of C++ code and due to the higher level of abstraction of the CML, non-technical staff can maintain meta-language scripts. These together with other objects and advantages which will be subsequently apparent, reside in the details of construction and operation as more fully hereinafter described and claimed, reference being had to the accompanying drawings forming a part hereof, wherein like numerals refer to like parts throughout.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is an overall software configuration of the present invention.
Figure 2 is a diagram showing the interaction between the CML source script, the CML Framework and the business application in the present invention.
Figure 3 is a flowchart showing the method of creating and executing a CML script as shown in figure 2 as practiced by an embodiment of the present invention.
Figure 4 is a diagram showing the architecture of the stack- machine in the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
Before discussing the features of the present invention a summary of the terms used in the discussion herein will be provided.
A scripting language is a high-level language providing basic programming constructs.
A meta-language is a high-level language that is directly tied to a specific application. Reference data is usually stored on a permanent storage such as a database and is used by processing the data as reference values for validation or conditional logic.
Business logic is the implementation of a business process using rules and processing logic. If a business process or associated rules need to be changed, the business logic must also be modified.
A class is a program module that combines logic and state. An example of a« class is the Event class that is used to represent telephone calls.
An object is a specific instance of a class. An example of an object is the instance of a Event object that represents a specific telephone call. The Event object is an instance of the Event class, its state represents the data of the specific telephone call.
An attribute is part of an object's state and defines some property of the class. An example of an attribute in an Event object is the originating phone number of the telephone call that is represented by the object.
A method is part of a class or object and performs specific operations. Methods can be called by other objects or by the object itself. An example of a method in an Event object is a method providing the call duration. The duration can either be calculated (from start and end time) or simply provide access to a duration attribute in the Event object.
A reflection layer provides a mechanism to browse objects at runtime for their type, attributes and methods. This facilitates late binding where it is determined at runtime what operations are executed.
A strongly typed system allows the use of typed data in programs to be checked when the program is compiled. For example it can be verified whether a return value of a certain type can be assigned to a variable of a certain type.
A type inference, in a language providing type inference, the types of literals, values, and expressions in a program do not have to be declared by the programmer but are calculated once the program is compiled.
In a compiled language, the program text has to be compiled before execution. This results in a performance improvement and the execution is less prone to contain errors. All syntactical and type related information can be verified by the compiler to prevent errors at execution time.
The C++ Meta-Language (CML) framework 34 shown in Figure 2 comprises compiler 120 and stack machine 100 and provides applications with tools necessary to compile and execute metalanguage scripts. The CML framework is coupled with a C++ reflection layer, also referred to as run-time type identification ("RTTI")
32 mechanism shown in figure 1. All components of the CML framework are located on an application server and are implemented in portable C++. The operating systems used are HP-UX, Linux, and Windows NT. However, as would be appreciate by someone of ordinary skill in the art, any general purpose computer operating system may be used. Using another high level program language other than C++, would also require the implementation of the RTTI system and the CML compiler/stack machine libraries, since they are tightly coupled to C++.
Software layers
Referring to Figure 1 , without the existence of the metalanguage layer 10, all business application logic would be traditionally implemented in the application core layer 20 in form of C++ business objects. In order to change to the business logic, C++ code would have to be modified, the application core layer would have to be recompiled and re-tested. Non-technical staff, familiar with the business process, could not perform these modifications. However, with meta-language layer 10, business logic can be implemented in the meta-language layer 10 by the non-technical staff. The metalanguage 10 provides a higher level of abstraction than C++ and can more easily be maintained by non-technical staff. Business logic contained in meta-language 10 can be modified without the extensive effort of rebuilding the application. A drawback of the meta-language layer 10 is performance. Processing implemented in meta-language 10 is executed more slowly than processing implemented in application core 20 C++ objects. Therefore, a balance of flexibility and performance needs to be considered when planning where to place business logic.
Meta-Language Layer 10
Still referring to Figure 1 , meta-language layer 10 contains the specification of the business logic. This meta-language layer 10 covers the functionality that is subject to frequent change such as the output formats or processing rules. The meta-language layer 10 is based on building blocks provided by the application core 20. Most of the complex logic of the business functions is contained in the meta- language layer 10.
Application Core 20
The application core layer 20 includes application-specific C++ classes. This application core layer 20 also contains the hard-coded business functionality that is not embedded in the meta-language layer 10. The application core layer 20 is built on top of the infrastructure layer 30 for the particular kind of application (batch, online, server) intended. Performance critical processing has to be carried out by low level C++ objects and is implemented in the application core layer 20.
Infrastructure Layer 30
The infrastructure layer 30 provides services that can be used by all applications. The infrastructure offers a standard interface to the operating system 40 including additional services such database access, logging, messaging, and profiling. The infrastructure layer 30 provides common services that can be used by ail applications built on top of the infrastructure. The infrastructure layer 30 also provides a reflection layer (RTTI) 32 that allows for access to attributes and methods of C++ objects by name as required by the scripting layer.
Any C++ class can export its attributes and methods to be visible for CML, under certain names by which the attributes and methods can be accessed from CML. A reflection layer is a conventional mechanism for changing structure and behavior of software systems dynamically. The reflection layer provides information and access to system properties and makes the software self-aware. Programming languages, such as JAVA, contain reflection layers as a feature of the language itself. Implementation of reflection layers is described in A SYSTEM OF PATTERNS, by Frank Buschman et. al., Wiley and
Sons, ISBN 0 471 95869 7, incorporated by reference herein. Further, the C++ meta-language (CML) framework 34 is part of the infrastructure layer with its compiler 120, shown in figure 2, and stack machine 100, shown in figure 2. The CML framework 34 shown in Figure 1 uses a combination of techniques to provide the meta-language layer 10 on top of application core layer 20. The main features of the CML framework 34 comprises:
1. High-level object-based scripting language with simple syntax;
2. Strongly typed with type inference (less type declarations);
3. Compilation into internal representation for a stack machine ("virtual machine"); and 4. Integrated with a Reflection Layer (RTTI) 32 allowing access to C++ class attributes and methods by name. CML is a strongly-typed compiled language, as illustrated in the discussion of table 1 below. The target of the compilation is not machine code, but a sequence of instructions for a small virtual machine (stack machine 100 shown in Figure 2). Referring to Figure
2, this stack machine program 80 (SMP 80) is contained in a C++ structure and executed by a stack machine 100 realized in C++ when executing the program. This approach ensures that most of the burden of translating the CML source script 60, shown in Figure 2, can be carried out before actually executing the program. Since CML is strongly typed, the compiler 120, shown in Figure 2, can check the types of all operations avoiding type errors during the execution of the program. Moreover, the compiler can generate typed operations for the stack machine 100 that can be executed much faster than dynamically typed operations.
Sample Program
Table 1 below depicts a simple CML script 60, shown in figure 2, provided for illustrative purposes only dealing with a very simple example of bill formatting. The purpose of this script is to print all events contained in the given document sorted by start time. It also has to compute the total duration as well as the total charge grouped by "event group". As a final operation the sample program prints the results.
In the sample program shown in table 1 , it is assumed that three C++ classes have been defined with run-time type information using the RTTI mechanism. These three C++ classes are the Document class, Invoice class, and Event class. The Document class contains a list of events which is simply called events. The Invoice class extends the Document class by an integer attribute number. An Event class has four attributes, the start time, the duration, the charge, and the group. Moreover, it provides a method getDestination which returns the destination (called number) as a string.
Table 1 - Sample CML Program.
The following is a brief description of the functions performed by the CML script shown in table 1. Line 0 of table 1 imports another CML package called "usage". This package contains a program called "process" which is called in line 4.
Lines 2-4 of table 1 define the first program printEvent which contains the print commands for a single event. The argument type declaration uses a Pascal-like style. Event is the C++ class supplied with run-time type information so that its attributes and methods can be used from CML as shown in Line 3.
Lines 7-8 of table 1 show how the Invoice number attribute can be used. A type-check condition such as "is Invoice" automatically changes the type of the variable within the associated block (here, the "then" block of the if-statement). In this way attributes of derived classes can be accessed without any additional type casting.
Line 11 of table 1 introduces a new variable. Variables do not have to be declared. They are created with the first assignment, and their type is the type of the value which is assigned to it (here an integer).
Line 12 of table 1 defines another new variable which is a list of events. The right hand side of the assignment creates this list. For container types such as lists, vectors, tuples and maps, the contained types have to be specified to allow for compile-time type checking.
Line 13 of table 1 defines a map (also called associative array) of decimals indexed by strings. For maps, both, the type of the keys and the type of the values, have to be provided. Line 15 of table 1 shows the sort statement for lists. It is one of the CML commands which have been built in for convenience.
Line 17 of table 1 starts a loop through the list of event contained in the document. The syntax for the control statements (loops, conditional statements, etc.) has been chosen to be short but readable (no begin-end, no curly brackets as in some programming languages).
Line 18 of table 1 calls the first program printEvent with the current event.
Line 19 of table 1 shows the with statement which (as in most scripting languages) allows for using attributes names directly ("duration" instead of "event.duration").
Line 24 of table 1 demonstrates another feature which has been introduced to reduce the CML code size: the += operator for maps. If the key (here "group") does not exist in the map, the entry is automatically created and initialized with zero before adding the right hand side of the += statement.
As demonstrated in this small example shown in table 1 , the CML syntax has been designed to be easy to learn with the idea of
"executable pseudo code". Therefore, a conventional syntax (in contrast to Lisp, Smalltalk) has been chosen. Since CML sits on top of the object-oriented language C++, attribute and method access are supported using a syntax similar to C++. Referring to Figures 2 and 3, the execution of the CML script
60 in figure 2 and operation 200 in figure 3 relies on the use of a stack machine 100 that introduces a significant overhead when compared to direct machine instructions. However, the advantage provided is run-time configurability which makes possible the ability of changing business functionality without recompiling C++ code. This overhead is unavoidable unless techniques like just-in-time compilation are employed. Just-in-time compilation refers to a technique where interpreted code is translated into machine code as it is executed. This technique is used in Java development environments available today.
Figure 2 is a diagrams illustrating the data and processing flow in the present invention as well as illustrating the different phases of compilation and execution. Figure 3 is a flowchart showing the method of creating or modifying and executing a CML source script. Both figures will be discussed together to illustrate the processing flow of the present invention.
Referring to figures 2 and 3, the CML source script 60 is stored on a Datastore (e.g. database or file system) 55 external to the
Application 65. As provided in operation 200 of figure 3, the CML source script 60 can be created and modified with standard text editing tools. An Application intending to execute a CML program contained in a CML source script 60 loads the corresponding CML source script 60 from the Datastore 55 in operation 210 of figure 3. In operation 220 of Figure 3 the Compiler 120 is invoked which is part of the CML Framework 34. Compilation is organized into two operations within operation 220. First, the syntactical analysis of the CML source script 60 is performed that transforms the source text into a parse tree 70, shown in figure 2, reflecting the syntactical structure of the program and the actual translation of the parse tree into the stack machine program 100. Second, a translation process transforms the parse tree 70 into a Stack-Machine Program SMP 80.
Still referring to figures 2 and 3, in order to simplify future extensions of the language, the implementation of the CML translation uses a set of translator objects, one for each type of parse node (not shown) (e.g., a translator for if-statements, another one for assignments, etc.). When translating the parse tree 70, the actual translation is delegated to the corresponding translator. An essential part of the translation process is the handling of types. The CML compiler 120 uses bindings and environments. A binding gives a path (such as "event.duration") a specific meaning (such as "field of type int"). More precisely, a binding maps a path to a variable, field (attribute of an object variable), method, or a CML program that is part of another CML module. An environment manages the bindings during the compilation process. Besides keeping the bindings, the environment also handles the scope of variables and the logic for "with" statements. The environment changes during the compilation as new variables are created or existing ones go out of scope. Those changes are kept in a history that allows for recovering the state of the environment. The history is implemented as stacks (detailed further below) for each bound variable and another stack containing the paths that have been changed. Once the Compiler 120 has finished compiling the CML Source Script 60, it passes the SMP 80 back to the Application 65. The Application 65 keeps this SMP 80 obtained from the compiler 120 in memory. As provided in operation 230 shown n figure 3. Whenever data needs to be processed, the application checks 240 whether the CML source script 60 was modified since it was compiled last. If it was not modified, the application calls the stack machine 100 with the SMP 80 and the input data 90. The stack machine 100 executes the SMP 80 and returns the output data 110 to the application. If the CML source script 60 was modified, the application loads the modified version of the script and recompiles it before executing it.
Virtual Stack Machine 100
Referring to Figure 4, like most virtual machines, the CML framework uses a stack 160 to hold temporary values and a frame 150 to hold variables accessible by an index. The virtual stack machine 100 operates by copying data between stack 160 and frame 150 or act on the stack 160 itself as depicted in Figure 4. For ease of implementation, frame 150 and stack 160 use vectors of generic values.
A stack machine program (SMP) 80 is a sequence of operations 140 which determine the actions carried out with stack 160, frame 150, and output stream 110.
The stack 160 is a LIFO system (Last-In, First-Out). Values are retrieved (or popped) from the stack in the reverse order they were added (or pushed) onto it.
The frame 150 is an indexed storage system, i.e., it can be viewed as a set of numbered cells. Moving a value from or to the frame requires to know the index number of the cell from which a value is read or to which it is written. From the CML point of view, the frame manages the variables used in a program.
In the context of a CML program calling other CML programs, a called program will always have its own local Frame 150. In fact, a Frame 150 is associated with one instance of a SMP 80 only. At startup, it only contains the objects that are the parameters of that program (Input Data 90 shown in figure 2).
The output stream 110 is the piace where text is sent to for output. From a CML program, the output stream 110 is the target of print statements. Alternate Embodiments
The procedures presented herein are not inherently related to any particular computer. In particular, various general-purpose machines may be used with programs described herein. The recommended configuration is a general purpose computer running a UNIX operating system.
Further, any number of computer languages may be used. For example, Java may be used instead of C++. Different version of UNIX may also be used as well as any comparable operating system. Almost any processor or computer may be used such as a Sun computer.
The many features and advantages of the invention are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the invention which fall within the true spirit and scope of the invention.
Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope of the invention.

Claims

What is claimed is:
1. A meta-ianguage for generating scripts used to execute business logic, comprising: a script to execute business logic implemented in an object oriented programming language having a plurality of class attributes, methods, type inferences, and strongly typed data structures; and a reflection layer interfacing to the script to access the plurality of class attributes and methods by name.
2. A meta-language as recited in claim 1 , wherein the object oriented programming language is C++.
3. A meta-language as recited in claim 1 , wherein the script is a high level language providing basic programming constructs.
4. A meta-language as recited in claim 1 , further comprising: a parser to scan and parse the script for grammatical and data typing errors and report any errors to a user.
5. A meta-language as recited in claim 4, further comprising: a compiler to compile the script after it has been scanned and parsed by the parser for grammatical and data typing errors and has been found to be error free and generate a stack machine program.
6. A meta-language as recited in claim 5, further comprising: a stack machine to execute the stack machine program using data input by the user and generating output data for the user.
7. A meta-language as recited in claim 6, wherein the script may be modified by the user and executed by the stack machine without the need of recompilation by the on any application code due to the reflection layer accessing the plurality of class attributes and methods by name.
8. A meta-language as recited in claim 7, wherein the stack machine retrieves operations from the stack machine program and translates the operations for execution.
9. A meta-ianguage as recited in claim 5, wherein the compiler generates a plurality of bindings that maps a path to a variables, fields, or methods in an operation of the stack machine program.
10. A meta-language for generating scripts used to execute business logic, comprising: a script to execute business logic implemented in C++ object oriented programming language having a plurality of class attributes, methods, type inferences, and strongly typed data structures; a reflection layer interfacing to the script to access the plurality of objects, class attributes and methods by name; a parser to scan and parse the script for grammatical and data typing errors and report any errors to a user; a compiler to compile the script after it has been scanned and parsed by the parser for grammatical and data typing errors and has been found to be error free and generate a stack machine program; and a stack machine to execute the stack machine program using data input by the user and generating output data for the user, wherein the script accesses objects, class attributes and method in the C++ object oriented programming language.
11. A method of generating, modifying and executing a metalanguage program that performs business logic, comprising: creating a script to execute business logic implemented in an object oriented programming language having a plurality of class attributes, methods, type inferences, and strongly typed data structures; and generating a reflection layer interfacing to the script to access the plurality of class attributes and methods by name.
12. The method as recited in claim 11 , wherein the object oriented programming language is C++.
13. The method as recited in claim 11 , wherein the script is a high level language providing basic programming constructs.
14. The method as recited in claim 11 , further comprising: scanning and parsing the script for grammatical and data typing errors and reporting any errors to a user.
15. The method as recited in claim 14, further comprising: compiling the script after it has been scanned and parsed by the parser for grammatical and data typing errors and has been found to be error free and generating a stack machine program.
16. The method as recited in claim 15, further comprising: executing the stack machine program using data input by the user and generating output data for the user.
17. The method as recited in ciaim 16, wherein the script may be modified by the user and executed without the need of compilation due to accessing the plurality of class attributes and methods by name.
18. The method as recited in claim 17, further comprising: retrieving operations from the stack machine program and translating the operations for execution.
19. The method as recited in claim 15, further comprising: generating a plurality of bindings that maps a path to a plurality of variables, fields, or methods in an operation of the stack machine program.
20. A method of generating, modifying and executing a metalanguage program that performs business logic, comprising: creating a script to execute business logic implemented in a C++ object oriented programming language having a plurality of class attributes, methods, type inferences, and strongly typed data structures; generating a reflection layer interfacing to the script to access the plurality of objects, class attributes and methods by name.; scanning and parsing the script for grammatical and data typing errors and reporting any errors to a user; compiling the script after it has been scanned and parsed by the parser for grammatical and data typing errors and has been found to be error free and generating a stack machine program; executing the stack machine program using data input by the user and generating output data for the user; retrieving operations from the stack machine program and translating the operations for execution; and generating a plurality of bindings that maps a path to a plurality of variables, fields, or methods in an operation of the stack machine program.
21. A computer program stored on a computer readable medium for generating scripts used to execute business logic, comprising: a script to execute business logic implemented in an object oriented programming language having a plurality of class attributes, methods, type inference, and strongly typed data structures; and a reflection layer module interfacing to the script to access the plurality of class attributes and methods by name.
22. The computer program as recited in claim 21 , wherein the object oriented programming language is C++.
23. The computer program as recited in claim 21 , wherein the script is a high level language providing basic programming constructs.
24. The computer program as recited in claim 21 , further comprising: a parser module to scan and parse the script for grammatical and data typing errors and report any errors to a user.
25. The computer program as recited in claim 24, further comprising: a compiler module to compile the script after it has been scanned and parsed by the parser module for and grammatical and data typing errors and has been found to be error free and to generate a stack machine program.
26. The computer program as recited in claim 25, further comprising: a stack machine to execute the stack machine program using data input by the user and generating output data for the user.
27. The computer program as recited in claim 26, wherein the script may be modified by the user and executed by the stack machine without the need of compilation by the compiler module due to the reflection layer accessing the plurality of objects, class attributes and methods by name.
28. The computer program as recited in claim 27, wherein the stack machine retrieves operations from the stack machine program and translates the operations for execution.
29. The computer program as recited in claim 25, wherein the compiler module generates a plurality of bindings that maps a path to a variables, fields, or methods in an operation of the stack machine program.
30. A computer program stored on a computer readable medium for generating scripts used to execute business logic, comprising: a script to execute business logic implemented in a C++ object oriented programming language having a plurality of class attributes, methods, type inference, and strongly typed data structures; a reflection layer module interfacing to the script to access the plurality of objects, class attributes and methods by name.; a parser module to scan and parse the script for grammatical and data typing errors and report any errors to a user; a compiler module to compile the script after it has been scanned and parsed by the parser module for grammatical and data typing errors and has been found to be error free and to generate a stack machine program; a stack machine to execute the stack machine program using data input by the user and generating output data for the user;
EP99937436A 1999-07-15 1999-07-26 Meta-language for c++ business applications Withdrawn EP1196846A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US35339499A 1999-07-15 1999-07-15
US353394 1999-07-15
PCT/US1999/016770 WO2001006357A1 (en) 1999-07-15 1999-07-26 Meta-language for c++ business applications

Publications (1)

Publication Number Publication Date
EP1196846A1 true EP1196846A1 (en) 2002-04-17

Family

ID=23388903

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99937436A Withdrawn EP1196846A1 (en) 1999-07-15 1999-07-26 Meta-language for c++ business applications

Country Status (4)

Country Link
EP (1) EP1196846A1 (en)
AU (1) AU5227599A (en)
CA (1) CA2302306A1 (en)
WO (1) WO2001006357A1 (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE50111361D1 (en) * 2001-04-11 2006-12-14 Alstom Technology Ltd Method and computer program for the static simulation of nonlinear relationships in thermodynamic networks
US7392237B2 (en) 2001-04-26 2008-06-24 Siemens Medical Solutions Usa, Inc. Identifier code translation system
US20020196295A1 (en) 2001-06-26 2002-12-26 Siemens Medical Solutions Health Services Corporation System and user interface supporting use of customizable expressions by applications
US7873592B2 (en) 2007-04-20 2011-01-18 Microsoft Corporation Type inference for object-oriented languages
US10565315B2 (en) 2012-09-28 2020-02-18 Cerner Innovation, Inc. Automated mapping of service codes in healthcare systems
US10318635B2 (en) 2012-09-28 2019-06-11 Cerner Innovation, Inc. Automated mapping of service codes in healthcare systems
US10403391B2 (en) 2012-09-28 2019-09-03 Cerner Health Services, Inc. Automated mapping of service codes in healthcare systems
US10490306B2 (en) 2015-02-20 2019-11-26 Cerner Innovation, Inc. Medical information translation system

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996002033A1 (en) * 1994-07-12 1996-01-25 Jr East Japan Information Systems Co., Ltd. Method of writing program for specific business
GB2320111A (en) * 1996-12-06 1998-06-10 Jba Holdings Plc Data processing system and method for software development/configuration

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0106357A1 *

Also Published As

Publication number Publication date
WO2001006357A1 (en) 2001-01-25
CA2302306A1 (en) 2001-01-15
AU5227599A (en) 2001-02-05

Similar Documents

Publication Publication Date Title
Clifton et al. MultiJava: Design rationale, compiler implementation, and applications
US5586328A (en) Module dependency based incremental compiler and method
US8850409B2 (en) Notification-based constraint set translation to imperative execution
US7272821B2 (en) System and method of universal programming language conversion
US6823504B1 (en) Method and apparatus for interfacing a javascript interpreter with library of host objects implemented in java
Snyder CommonObjects: an overview
US20040268301A1 (en) Adding new compiler methods to an integrated development environment
US6951014B1 (en) Method and apparatus for representation of a JavaScript program for execution by a JavaScript interpreter
Gries et al. Some ideas on data types in high-level languages
US6898786B1 (en) Javascript interpreter engine written in Java
US20040268307A1 (en) Representing type information in a compiler and programming tools framework
Buro et al. On multi-language abstraction: Towards a static analysis of multi-language programs
Biboudis et al. Recaf: Java dialects as libraries
EP1196846A1 (en) Meta-language for c++ business applications
Brandis et al. The Oberon system family
US20070074185A1 (en) Identifier expressions
Zeigler et al. Ada for the Intel 432 microcomputer
Ghuloum An incremental approach to compiler construction
Holt et al. The Turing language report
Gregor et al. Concepts for C++ 0x (revision 1)
Cardelli The quest language and system
Marevac et al. Design and Implementation of a Virtual Machine for a Dynamic Object-Oriented Programming Language
Hicks Types and Intermdiate Representations
Van Rossum et al. Python frequently asked questions
Di Giacomo Metacasanova: a high-performance meta-compiler for domain-specific languages

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20010720

AK Designated contracting states

Kind code of ref document: A1

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

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20040203