Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1997-06-11
2002-07-16
Jung, David (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C709S241000, C709S241000, C709S241000, C717S114000, C706S045000, C706S047000, C706S056000, C706S050000
Reexamination Certificate
active
06421667
ABSTRACT:
FIELD OF INVENTION
The invention relates generally to computer-based process execution systems, and more particularly, to the optimized representation of processing logic.
DESCRIPTION OF THE RELATED ART
In the earliest days of electronic data processing, jumper wires on plugboards contained the definition of the process a machine was supposed to execute. Humans could not easily read this processing logic contained on the plugboards, and that processing logic represented only a very small and very low-level portion of the rules used to conduct a business enterprise. For example, the entire processing logic contained on a plugboard may have said little more than that numeric values contained in punched cards read by the machine should be summed, but only for those cards having an “X” in the first column of the card.
As tabulating machinery gave way to general purpose, stored-program computers, the processing logic moved from plugboards to application programs. The application programs had both machine-readable and human-readable forms. Making the processing logic easily accessible to people, as well as to the computer, was a major advantage over the plugboard—responsible people need to continually create, identify, understand, and maintain the processing logic, and the computer needs to continually execute it.
Processing logic in an application program generally comprises both the functional data manipulations for the computer to perform and the conditions under which those manipulations should be performed. For example, the processing logic may state that under the condition a payment is being made late, then the amount of the payment should be calculated at 103% times the invoiced amount, otherwise the amount of the payment should be calculated at 100% times the invoiced amount.
The ability to evaluate a condition and then determine which, if any, course of action to take dependent on the outcome is known as conditional branching. The computer's ability to perform conditional branching is a key to its widespread success and its application to problems diverse in nature and complexity. Computer programming languages, e.g., FORTRAN, COBOL, BASIC, and C, provide a variety of means to achieve conditional branching and the sophistication of a programming language may be judged on the conditional branching alternatives it provides. For example, the C language provides IF . . . THEN, SWITCH . . . CASE, FOR . . . NEXT, and other statement constructs for achieving conditional branching. Newer languages, such as C++, are not designed to simplify conditional branching but may include features to further facilitate or refine conditional branching mechanisms. Examples include the private and protected methods of classes in C++ that may restrict the courses of action targeted by a conditional branch.
Regardless of the conditional branching construct used, the purpose is to associate a condition with a course of action. These associations fundamentally represent the processing logic embodied by the application program. Unfortunately, the many possible constructs available for representing these condition-to-action associations obscures their underlying similarity.
The lack of similarity in the representations of the processing logic in traditional programming languages makes it difficult to collect and analyze the processing logic as a whole. For example, a business enterprise may have its manufacturing software, contained in hundreds of individual program modules, written in C, BASIC, and FORTRAN. The same business enterprise may have its accounting software, also containing hundreds of modules, written in COBOL and BASIC. Moreover, the manufacturing software may reside and execute on machines and operating systems from one vendor, while the accounting software resides and executes on machines and operating systems from another vendor. Furthermore, the BASIC language used for accounting programs may be a different variant than the BASIC language used for manufacturing program. Considering the dissimilar languages employed, the dissimilar ways to represent condition-to-action associations within each language, the dissimilar locations where the application programs may reside, and the dissimilar operating systems and hardware, it would be very difficult to programmatically collect and analyze the processing logic contained in all of the manufacturing and accounting application programs together. The same may be true within either of the manufacturing software or accounting software systems, by itself.
So, in a collective sense, the processing logic of the business cannot be readily collected and analyzed with the aid of the computer, despite the fact that the processing logic embodied in application programs is machine-readable. Such analysis of the collective processing logic is highly desirable for performing business modeling and for identifying contradictions, conflicts, and relationships among individual elements of processing logic. Business modeling involves the symbolic representation of the objects, entities, and processes involved in the operation of the business for planning, analysis, modification, simulation, and reporting.
The lack of similarity in the representations of the processing logic in conventional programming languages also has disadvantages despite its being human-readable. At the core of the problem is that fact that the business people responsible for determining the processing logic for the operation of the business enterprise, e.g., supervisors, managers, and directors (managers, or management), generally do not have the technical training required to understand and use computer programming languages. Consequently, management relies on intermediaries, i.e., computer programmers, to translate its intentions into a programming language that the computer understands. For example, if an appropriate company manager decides that a new class of employee needs to be created that earns benefits according to a different set of criteria than other existing classes of employees, then the manager must relate the new criteria to a programmer who modifies an application program or programs accordingly. Besides the inherent delay, this brings with it the possibility that “something gets lost in the translation.” Disconnects frequently result between the business model intended by the management and the business model embodied in the processing logic in the application programs.
One potential solution to the above problems may be to develop software tools allowing management to directly manipulate the application programs written in traditional programming languages. Such a tool could provide an interface that translates between the traditional programming language and some intermediate level of representation more easily understood by managers. Again, because of the diversity of programming languages, a generalized tool would be difficult to develop and any such tool would likely be restricted as a practical matter to particular programming languages, hardware, and operating systems.
Another potential solution to the above problems appears to be standardization on a single computing language within the business enterprise. First, this may not be practical because of a need to use multiple computing platforms, some of which may be incapable of supporting the standard language. Further, the business enterprise may purchase some of its applications from software vendors and have no control over the language in which it is written. Even if standardization is possible, representation of the condition-to-action associations may be dissimilar within the language, e.g., IF . . . THEN vs. SWITCH . . . CASE; and managers are unlikely to have or obtain the technical training required to understand and use the language.
Furthermore, traditional computer languages are targeted for representing only the detailed levels of business processing logic, e.g., the calculation of a particular value to be printed on a particular line of an invoice. The management, however, a
Codd Edgar F.
Codd Sharon B.
Jung David
Morrison & Foerster / LLP
LandOfFree
Delta model processing logic representation and execution... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Delta model processing logic representation and execution..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Delta model processing logic representation and execution... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2821187