CA2427400A1 - A universal parser to relate user's specified program and data objects for any application system written in any programming language(s) - Google Patents

Abstract

Changes and/or expansions to an application system are inevitable. An application system is modified and expanded many times during its lifetime. Today's application systems are complex. They can contain code that is written in more than one programming language. Data definitions may exist out of the domain of an application system; however, these very data are manipulated by an application system. Thus, there are many relationships among these data and the programs of the application system; one affects the other. The modification of one of these components triggers silently a series of changes. These changes are not apparent and not in sequence. A network of computers (or network) is a set of related computers, and a computer may contain one or more application systems or part of an application system. The affected components can be anywhere in the network. To guarantee the integrity of the network all the affected components must be found and corrected; else this change can and will have disastrous results. To fix this problem an army of sophisticated programmers is needed, a resent example is the Y2K bug, because the required information is not readily available, it has to be extracted from the application systems as they exist in its current format. This is expensive, time consuming andnext to impossible if it has be done on daily basis. To solve the problem, a diagnostic system is required to convert the format of an application system to a format that a user can draw immediate knowledge of the relations and the affects of the program objects and the data objects. The terms program and data objects are subjective, and thus a user must determine what these objects are. Since part of an application system can be written in different programming languages we must find a way to allow the user to describe the required objects in many different programming languages. In other words, a universal grammar is required -that can recognize the syntax of program and data objects in any programming language- and to construct an engine (called parser) that can recognize the user's specified objects and relate them in the required way to achieve the application system's objectives

Description

A UNIVERSAL PARSE TO RELATE USERS SPECIFIED
PROGRAM AND DATA ~JECT'S FOR ANA' APPLICATION
sysTEM wRITTEN IN A PROG M~IING LANGUAGE(s) 1. FIELD OF INVENTION
The present invention relates to a selective, minimal, and object oriented parser that is necessary and sufficient to recognize and relate user's specified program objects and data objects for any application system(s), which exist in a network and contain code written in any and many programming languages.

2. BA~KGROITNI? OF THE INVENTION
Programming languages do not offer the logistics required for development, management, maintenance, and logical data independence of application systems.
This is the function of a diagnostic system, called E-2002. The terms development, management, maintenance and logical data independence may be defined as:
Development: E-2002 assists a programmer to develop new programs on top of existing ones. For example, the programmer would know ifthe program already exists, or if the table exists and has the required attributes.
Management: E-2002 assists a programmer to know as to how the various program and data objects (from now on, the word 'object' if not otherwise specified means program and/or data object) are organized in the entire network. For example, what modules an application system contains, what methods/functions (from now on the word method will be used to imply method/function) these modules have, what methods are called by a method, etc. Reverse relations are stored automatically, as well.
For example, given a method's or function's name, E-2002 identifies uniquely its absolute path and in which line of the source code exists;
i.e. under which schema, under what application system, and under which module this method exist and in which line number in the source code.

Maintenance: E-2002 allows a programmer to modify or delete existing things and to add new ones. The data and the relations of E-2002 are automatically updated to reflect these changes. Moreover, it gives information to the user that was not available before.
For example, the user can know the times an attribute is used in a schema;
this can be used to tune-up the database system.
Logical data independence: in I7~MS logical data independence means the application programs to be immune (to a certain extend) to schema changes.
This notion is expanded to include any application system (no just database applications).
This term may be generalized as "all the affected stateanents of the application systems existing in the network to be identifeed when a data object definition changes" (more detail description follows).
The main function of a diagnostic system is to determine rules that can be openly used to specify the objects of any application system; that is, there is no preexistent knowledge as to what an object may be. They must be specified prior the parsing time in a diagnostic language. These objects are related to determine where they exist, what they contain, how they are related, and what a~'ects an object may have to the other objects, if any. Thus, one may say that the best diagnostic system is the application system itself.
This may be true, but is not practical. 1=Iere is why:
1. It is not apparent where the parts of an object exist and how to be combined; they do not exist in sequence, they are scattered and hidden in the programs. For example, a table or a view name may be substituted using many different alias names even in the same SQL program. A variable name in an argument list can be changed in the parameter list of the corresponding method definition.
2. These objects must be related to convey meaning and information that is useful for the entire network (global relations), not just local. For example, a program that is not needed any more cannot delete the tables) that is using. This can be done if and only if the tables) was used by this program only; if this were the case the table must be deleted, else the schema and the database would contain many dormant tables, views, and attributes.

3. Objects may exist in a form that is not known prior to runtime. For example, the table name may be defined as a string in an SQL program.

4. Objects are related. The deletion or modification of any object affects many other objects, and perhaps in many ways. For example, the deletion of an attribute affects many application systems and in different ways. For example, this attribute was related to a host variable, or it exists in different SQL
commands, or it occurs in the parameter list of a method definition and under a different name.
A diagnostic system is a subset (or a miniature) of the application system having different components and in a different format. Yet, there are times that the user's needs may defy this definition.
For example, it is insuff=icient for a user to know that an SQL program (in a method) is using the attributes 'E' and 'C'. Perhaps the user wishes to see as to how exactly these attributes are used in the SQL program at the time the need occurs. In an essence, a user wishes a subset (the diagnostic system) to represent the entire set (the application system), as the user may wish and at the time of conception. That is, on the fly.
3. IIETAiLEI) DESC1~IPTI~N OF TI3E INVENTION
Changes and/or expansions to an application system are inevitable. An application system is modified and expanded many times during its lifetime. Today's application systems are complex. They can contain code that is written in more than one programming language. Data definitions may exist out of the domain of an application system, as well.
These data are manipulated by an application system. Thus, there are many relationships among these data and the programs of the application system; one affects the other. The modification of one of these components triggers silently a series of changes.
These changes are not in sequence. A network of computers (or network) is a set of related computers, and a computer may contain one or more application systems or part of an application system.
The affected components can be anywhere in the network. To guarantee the integrity of the network all the affected components must be found and corrected; else this change can and will have disastrous results. To fix this problem an army of sophisticated programmers is needed, a resent example is the Y2I~ bug, because the required information is not readily available, it has to be extracted from the application systems as they exist in its current format. This is next to impossible for today's application systems; they are complex and they involve servers, clients, and code in many programming languages.
Although, complex and sophisticated application systems have been developed, the area of developing diagnostic systems for them remains empty. A diagnostic system may be defined as a system that describes the runtime logistics of the program objects and the data objects of any application system written in any programming languages) in such a way that a user can derive better knowledge of the relations and the affects of these object for the entire network; moreover, the integrity of the network to be preserved aside ofthe structural changes of the objects which can be generated by the user and at runtime by the user's programs.
For example, an ASP application system contains methods based in VBScript and Jscript; moreover, any of these methods can contain AI~ISI SQL programs) static or dynamic in any number (including none) and in any combination. An object may exist in several statements or in the same statements of a method; a method can exist in many different modules and in many different computers. Changes in a data object without determining the exact affects can and will have disastrous results. A network can have hundreds of application systems (written in different programming languages), tables, and views (a table and view can have tenths of attributes). A string can represent a subset of an SQL program and its value is known at runtime, only. The same table and/or a view can be used by many applications under a schema. Moreover, a view cannot have its own existence;
it depends on other tables) and or view(s). The deletion of a table and/or view determines a chain of changes in the structures of the DDL and the application system.
Thus, an army of programmers is needed just to determine these objects, their relations, and their affects to guarantee a correct and reliable network. These programmers must be sophisticated because the domain of the problem is extensive. For example, a variable name in the argument of a method call can be a host variable and can have a different name in the parameter list of the called method. Along the same lines, an alias can be used many times and under different names instead a table or a view name even in the same SQL program.
The problem becomes more complex if networks must be merged, based on different programming languages and DBMS. The work is immense because these systems are heterogeneous; the database applications are based on different DBMS and programming _ . .~.. ,~ ... . , , _ :,.. . .. . ,,. " ,.,. .

languages. There are no systems to help the soft wear personnel with the required diverse information. There are systems that relate the logical descriptions of a database; they are falling short to offer the big picture, because they cannot express relations of data and programs. This invention (hereinafter referred to as E-2002), can relate the logical data descriptions of any DBMS with the application systems. Data objects coexist within program objects and one can manipulate the other. E-2002 recognizes and uncovers these hidden relationships and affects.
The same thing is true when non-database application systems must be merged.
The only difference is the data object declarations coexist within the application systems, as opposed to an autonomous external system (the DDL).
E-2002 can be used as a general searching or pattern recognition engine. This will require some minor changes to a group and not the structures of the selective grammar. That is, we may have to add to a group arithmetic, relational, and Boolean operators to express rich conditions as to how a syntactic unit (for short su) or token can exist in the source code.
Part of this engine is necessary for E-2002 to offer the logical data independence; thus, one has to be built.
In addition, E-2002 may be used as a pipeline to convert the output of an application system to the required input of another application system.
A diagnostic system must recognize and manage user's specified comments. It would be counter productive to store all the comments of an application system. The question is as to which objects would they be related to. A user can specify the letter 'e' or 'E' immediately af$er the symbols) that determine the beginning of a comment in a programming language. This determines to the system E-2002, that this comment must be stored. These comments can be a single line or multiple line comments. In a multiple line comment the letter 'e' or 'E' must be specified once. Some examples are given for clarif cation.
//E this work is dedicated to Eymor~a or /*e My daughter Eymowfaa was called prematurely to receive her wings.
My mother's name was Eymorfia, too. */

A comment is stored by default to the following program or data object. If a comment is not stored, and E-2002 frnds a new comment for storage, then the previous one is lost forever.
A diagnostic system is a subset (or miniature) of the application systems of the network. A diagnostic system cannot and should not represent directly the entire system; it is not necessary to represent directly each small detail. Many details of the application system can be derived which are not represented directly by E-2002. These indirect details are offered to the user at the time of perception. These details, usually, require a statement or statements that are isolated from any other code of a method. Thus, a diagnostic system may be also interpreted as it offers to the user undefined things with the necessary code pertained with the undefined thing. For example, a user may request to know the code that all the 'if statements contain within a method. In this case, we do not have to display the entire code of the method.
If an application system can be said to be the processor of data values of ~n enterprise, then E-2002 is the processor of the changes of the objects of the enterprise.
This invention includes the method of specifying open objects of any application system(s), written in any programming language(s), that are scattered in a network; also included is a method for relating these program and data objects to achieve the independence of affects, or any other relations as the application system may require.

4. DEFINITIONS ANI3 RECOGNITIONS OF PROGRAM OBJECTS ANI) DATA OBJECTS
4.1 A PROGRAM OBJECT
A program object is a subjective term dependent on the user, and it may be defined as a set of selective words of a programming language that identify code. The words below may define program objects:
1. Schema names, 2. Application systems names, 3. Modules names, 4. Method names,

5. control statements ~i.e. if, else, while, do, for), etc.
To consider a label as a program object is also correct.
For example, diflFerent users may require different interpretations on an 'if statement. A user may define an 'i~' statement as the relational or the Boolean expressions it contains. Another user may define an 'il' statement as the method calls it contains. Another user may define an 'ii' statement the compound statements that are included.
~'et, another user may define as an 'ifi statement as all the above.
Although extensive, the above list is not exhaustive.
4.2 A DATA OBJECT
A data object is, also, a subjective term dependent on the user, and it may be defined as a set of selective words of a programming language that identify data. The words below may define data objects:
1. Structures, 2. Classes, 3. Arrays, 4. Variables, S. Tables.

6. Views,

7. Attributes,

8 8. COnstantS, etC.
To consider a string as a data object is also correct.
For example, different users may assign dii~Ferent interpretations on a structure.
A user may define as a 'structure' all the structure variables associated with a structure declaration. Another user may define as a 'structure' the substructures members it contains.
Another user may define as a 'structure' all the members of the structure.
Yet, another user does not care about 'structures', because the user has a Java program.
Although extensive, the above list is not exhaustive.
The idea of an open object is a subjective one determined exclusively by the user. The only requirement is a program object to identify program words and a data object to identify data words. Thus, we must find ways to identify recognize these objects.
4.3 HOW A PROGRAM OR DATA OB.IECT IS RECOGNIZED
There are three general rules that can be used to identify any open object.
1. ~Ve must find a way to determine the beginning of the object, 2. ale must find a way to determine the things that belong to this object, and 3. ~Ve rnust find a way to determine the end of the object.
These objects exist in an application systems) that contain code in different programming languages. Programming languages are based on grammars, which define the rules as to how programs can be written. Thus, the only way to recognize these objects is to duplicate the parts of the grammars of the programming languages that recognize these objects. This is nonsense. These rules (called productions) involve other productions. Thus, pretty well we may have to duplicate these exact grammar(s). Imagine, having coexisting a Java grammar and an SQL grammar plus the diagnostic rules on top!
The only solution is to device a grammar that can recognize user's defined objects based in the above three rules. This way, we can recognize objects in any programming language, as long as we know the required syntax to describe the objects in this programming language. Thus, we require a smaller and selective syntax as opposed to a syntax that describes everything by default. This selective syntax is described in a selective grammar; then a parser must be written that recognizes any selective language, generated by this selective grammar.

9 A parenthesis about the rule (2), described previously. A hasty reader may think that this rule is not necessary. This is not true; it would be true if the elements of an object were in sequence. Let us assume, that the user wishes to know the variables in an 'if statement.
Let us further assume that an 'i~ statement is as:
if(C =3 ~&E =5) The su for this 'lf Statement are. ' ', 'C,', 6=9, G39, G&~', 6E', '__~ '5~, and G)'. The user needs to know only the variable 'C', and 'E'. Without the rule (2), the components of this '9f Statement would be. '(', GC', '--', G3', '~l~', 'E', ' -', '~', and ')' which are qlllte different.
5. A DESCRIPTION ABOUT PROD MMING LANGi.IAGES AND IIOW A
UNIVERSAL. SELECTIVE GRAMMAR CAN BE DEV1CED
There are many programming languages in the market. Every programming language is based on a grammar. A grammar determines the rules as to how words of an alphabet can be combined to write acceptable programs in the corresponding language.
These words of the program must be interpreted by a compiler to determine their meaning. The objective of a compiler is to generate the object code of the program.
Let's as assume we have the 'if statement in Java:
if(x == 0) ...
The same statement in C++ can be, exactly the same, or it can be written as:
if(!x) ... (the choice of C++ programmers).
Let us assume there is a new programming language coming in the market under the name NEW. Under NEW the above statement may be written as:
iff{ x is equal 0} ...
One way to assign meaning in the above 'if statements is to apply a similar interpretation that the corresponding compilers do: If this was the case, and we assume that we have to parse 'n' languages, then we would require 'n' different interpretations for one statement.
As far as a diagnostic system is concerned, we do not care about all the things that a compiler cares. Instead, we care as to how to recognize the objects and what relations to IO

apply to achieve development, management, maintenance, and logical data independence of the application system(s), or what other objectives may be. Thus, it would be meaningless to care about all the words of the 'if statement. That is, we do not care if the number l, or the number 2, or the number 1000 exists in an 'if statement.
Instead, a user may care about the variables that are included in the 'if statement. It could be also true that the user cares about the numbers 1, 2, or 1000. That is OK; it can be done if the user specifies it. We do not accept object by default; they have to be explicitly specified by the user.
From the above description, it would be unwise to use similar syntactic rules of a Java grammar, or a C++ grammar, or the I~EW grammar. Actually, it would be impossible to apply diagnostic concepts using these grammars. These grammars describe how to generate the object code of a source program, whereas a diagnostic system assumes that a program has been correctly compiled.
The only solution would be to develop a special language that can understand specified objects of the used programming language.
The things we would need in this case are:
1. The same user's source programs) to be available for reading, 2. The alphabet of this programming language, and 3. The syntax of the words that we care about.
It would not be a problem about the alphabet (a set of characters); it is easy to recognize any alphabet.
Words are abstract things (a set of characters of the alphabet). This definition is universal, and not a property of any particular programming language.
What remains, is to develop a special language that can recognize the specified words that identify objects within the user's programs and then to apply semantics to these words to achieve the user's objective(s).
For example, if the user cares as to what variables are contained in the relational expression of the above 'if statements the answer is 'x'. We came to this conclusion by recognizing the 'i~ statement and then selecting the variables included in the relational expression of the 'iF statement, eliminating ail the other things. Why should we care about '__', or '!', or 'is', etc.? The user does not care about these. If we could define II

such syntax independent of any programming language, then this syntax would be universally applied to any programming language including the programming language NEB.
This is the foundation of a selective grammar:
"a selective grammar determines the syntax as to how words of any programming language ~i.e. procedural, object oriented, special, or...) can be combined to form user's defined program objects and data objects".
By converting the words of the selective grammar to specific ones, a selective language is generated. A selective language is used to represent the programming language that an application system is written. If an application system contains code written in n different programming languages, then we need n selective languages. Each selective language can represent one and only one programming language. A
selective grammar is universal and can generate any selective language we wish.
5. THE SELECTIVE GRAMMAR
The selective grammar, as all grammars, is a set of productions. °The objective of the selective grammar is to allow the user to specify open objects as the user views them.
There are differences as to what the productions of the selective grammar are compared to the productions of other programming grammars. These differences may be summarized as:
1. The su of a selective grammar is a group.
2. A group is a nonempty set of elements, and has the same format independently of the Iefl part of the production; that is to say, all the right parts of any production are exactly the same, and for any programming language; the only differences would be the number of groups in a production.
3. A group is uniquely identified by the left pau of the production and by its first element; that is, no two or more groups can have the same first element in a production. If this is not the case, we can break a production to two productions.
4. The first element of a group can represent a set of su, instead of one (quite unusual and usefirl concept; a detail description follows).
5. The order of the groups in a production can be irrelevant or relevant.
If in a production the order of the groups is irrelevant the mete-symbol '~' is used to express this 'OR' relation. For example, group ~ group ~ group.
If in a production the order of the groups is relevant the mete-symbol '->' is used to express this 'A~1D' relation. For example, group -> group -> group A selective grammar can be expressed using Selective F'oo°m ~T~tati~n (or SFI9T) (based on the same spirit as the ~l~TF), as:
FIRST ::= group ~ group ( . .. ~ group SECOND ::= group ~ group LAST ::= group -> group I ... I group A line of SFN represents a production. FIRST, SECOl~tD, and LAST are the nonterminls of the productions. 'group' (a set of ordered variables) represents a partial replacement of a nonterminal. All the variables, in the same position of any group express the same meaning; generally speaking, a group defines a su, the syntactic rules, and the required runtime semantics for the su.
Many productions may be required in a selective language to recognize an object in a programming language.
6.1 TFIE STRUCTURE GF A GROUP ~NID ITS SEMANTICS
Any group aside of the selective language and the production that it belongs to, has the same format. A group is an ordered set of five elements, and can formally be represented as:
G = {element', element, element, element4, element5~

1, elements it identifies a specific su (i.e. string, i~, create, +, ...).
I~owever, the first su of a group can represent at the same time a set of heterogeneous su. For example, it can represent at the same time a 'string', and an 'if , and a 'create', and a '+', etc.(this property, as we will see later is used to minimize the number of groups in a production, hence minimal grammar).
2. element2 it identifies the runtime semantics associated with this su, hence object grammar. Thus, no semantic stack is required. This makes the runtime semantic analysis smaller, simpler, and clear.
3. elertr ~ent~ it identifies the nonterminal that follows this group.
4. element4 it is a flag that identifies as to how the next group is related with the current one. If it has the value I, then the relation is 'and' and the incoming su must match the one in the group; if not we have an error.
The default relation among groups is 'or' which means any group of the production can follow any group; there is no order.
5. elements it is reserved.
Thus, in analytical terms a group is described as:
G = {su, runtime semantics, f~li~wing prnductic~n, relati~n to the next group, free}
This is the format of a group in the selective grammar. For a selective language, all the variables of a group must be specified. They are substituted with integer numbers, and this integer number must be present even if the corresponding element is irrelevant within a group. The value 0 is used to represent this irrelevance. The first element cannot have the value 0; all the other elements can. The fifth element has always the value 0.
For example, a group may have the values 5,3,2,0,0, and another group may have the values 7,0,9,1,0 (note that no semantics are associated with the su number 7; however the next group is related with the 'and' condition (or '->' symbolically).
In reality, a group is an object that identifies a su, all the syntactic rules, and runtime semantic associated with the su. That is:

1. I-iow a group is related with the net group in the same production (order or not order), 2. The runtime semantics associated within the group, and 3. The nonterminal that can follow this group.
7. A COMPLETE EXAMPLE OF A SiIBSET OF SELECTIVE LANG~1AGE TO
RECOGNIZE TJEIE PROGRAM ANI) DATA OBJECTS OF T1JE
SQL STATEMENT 'ALTER' The command 'alter' of an SQL program is written in a selective language (whereas for short some variables are replaced with specifc values) to recognise the program and data objects of this SQL command. The program objects 'alter', 'table', 'add', and 'modify' are generated along with the data objects 'table' and 'attributes' that may be modified or added.
The first production of the selective language for an SQL program has:
SQL_PR~GRAM :: ..., 'alter', l, ALT_F~LL~WS ,0, 0, ... (the dots represent other first groups) ALT_FOLL~WS ::_ 'table', ~, ALT_FOLL~WS, 0, 0, 'variable', 7, ALT_F~LL~WS, 0, 0, 'add', 1, ALT_ADD, ~, 0, 'mo gfy', I, ALT M~D, 0, 0 ALT ADD ::_ 'variable', 2, ADD_I~EXT, 0, 0 ~~T .. ',', ~, ALT ADD, ~, ')', 4, ALT ADD, 0, ~, '(' 0, ADD LD~P, 0, ADD L~~P ..-- ')', ~, M~D NEXT, ~, ALT M~D ::_ 'variable', 2, IvI~D I~1EXT, 0, 0 M~D_NE?~T ::_ ',', 4, AL'T-MC~D, 0, 0, ')', 4, ALT MOD, ~, ~, '(', ~, MOD L~OP, ~, MOD LOOP ::_ ')', 0, MOD NEXT, 0, 0 Programming languages are used for humans. Their form has to be changed to be suitable for computers. That is, we have to replace all the words that appear in the right part of the symbol '::-' with numbers. Thus, the 'parsing matrix' or 'parsing table' is generated.
8. THE PARSING TA~I_,E ~R PARSING 1VIATRLX
If we replace all the variables of a group with specific values, we get the parsing table. The nonterminals ALT FOLLOWS, AL'T-ADD, ADD NEXT, ADD L~OP;
ALT MOD, MOD NEXT, and MOD L~OP are used to represent the row numbers of the parsing table. Let us, again consider the production:
ALT FOLLOWS ::_ 'table', l, ALT FOLLOWS, 0, 0, 'v ble', 7, ALT FOLLOWS, ~, ~, 'add', l, AL'T-ADD, 0, 0, 'modify', I, ALT MOD, ~, Let us assume that we assign for the word 'table' the value 1, for the word 'variable' the value 2, for the word 'add' the value 3, and for the word 'modify' the value 4.
Let us further assume that the production ALT FOLLOWS is the 10 row of the parsing table, then the production AL'f~ADI7 is the 11 row of the parsing table, and the production ALT- MOD is the 12 row of the parsing table.

Then the nonterminal ALT FCDLL~WS or the 10~' row of the parsing table would be:
1,1,10,0,0,2,7,10,0,0,3,1,11,0,0,4,1,12,0,0 The parsing table is a two-dimensional integer array. The meaning of these integer numbers must be interpreted by a processor. This processor is called a parser.
9. THE PARSER
The parser processes the parsing table by using some unusual and unique rules that are applied to any selective language. To simplify the matters, in some cases, a group will be represented by its su; this does not change anything.
Initially, the parser is idle. As soon a su is return from the lexical analyzer to the parser, the parser becomes active and puts the very first row of the parsing table for process.
The first row contains all the su that identify the beginning of all the program and data objects we care about from the user's application system. The algorithm for the parser is:
1. get the next su from the lexical analyzer (or lex-su); if no more lex-su the parsing process finished.
2. if there is a locked group then lex-su must match the su of the locked group (or gr-su). If not announce error and stop.
2.1 if the gr-su determines runtime semantics then call these semantics and determine the required processes; else ignore the semantics.
~.2 if the gr-su identifies the end of the current object, store the object permanently, relate it with other objects and put the parser in the idle state.
2.3 store the next row of the parsing table to be in process.

2.4 if the current group determines order then lock the next group and go to 1.
3. match the lex-su with the next gr-su of the current parsing row. If all gr-su have been exhausted go to 1.
3.1 if a match found or an EE (see definition below) gr-su found then repeat the steps 2.1, 2.2, 2.3, and 2.4.
3.2 else go to ~.
A parsing table implies the rules:
1. every row of the parsing table determines an infinity loop. This loop ends when the lex-su matches a gr-su or all the gr-su of a row have been exhausted.
2. if the current iex-su does not match any gr-su of the parsing row, this is not an error; simply we do not care about this su, and the loop on the current row continues.
3. The order of the groups within the row of the parsing table is irrelevant, if no order is defined. For example, if we say a row of the parsing table COntalns 'lf I 'else'' 'do', Or 'do' I 'lf I 'else', Or any otllC'.r combination is the same thing. This structure may be a bit slower but it gives the highest degree of modifiability.
4. there is a su that matches the value of any other su. This su is called 'everything else (EE)' or 'anything else (AE)' and matches the value of any su of the used programming language. 1 hat is a '+', '<', 'variable', 'select', or any imaginable word and/or symbol matches this value. This property is necessary and is used to minimize the number of groups required to represent the groups of the nonterminals. I-lere is the prove.
Let us assume that a user specifies as data objects the variables of a relational expression in an 'if statement; here are some 'i~ statements:
if(e+c == 8) ...
if(e*c > 10) ...
if(e/2*c <= 9) After the variable 'e' the arithmetic operators '+', '*', 'I', etc. can follow.
Obviously these operators must be ignored. To represent them explicitly, we would require a very large number of groups. All the things that can follow a variable can be represented as 'EE'. This property makes the terminals of a production to be minimal. A parsing row implies tacitly that the last group of a row is 'EE', which does not have to be stored. There are two reasons that an 'EE' must be present.
"when every other su mast switch to another row of the parsing table, or when every other su implies semantics."
Coming back to the previous 'if examples. The semantics associated with the 'EE' su would be "store the stacked variable as a data object, if the variable is not the name of a function". That is, if we have an 'if as, 'if(e(c) < 8), then 'e' is the name of a function; only 'c' is a variable.
It is obvious that if there is an 'EE' su in a row it must be the last one.
9.1 THE REQUIRED STRUCURES F~R THE SYNTAX ANALYS1S
This parser requires no syntactic stack or syntactic stack pointer to recognize correct syntax of the source program. There is also, no need to describe the expansion or the reduction of nonterminals by using extra tables. All these things are stored and exist in different format in the parsing table.
Thus, the only required data structure for the parsing process is the parsing table.
The parser of a selective language is simpler, and must be simpler, because we know in advance that the source programs are correct. Certain words of these source programs are recognized and processed.
The group is an object that determines all the syntactic rules, and the runtime semantic of a su. They all have the same format and can be used for any programming language including the NEW. The only thing that can change for any programming language is the content a group and nothing else.

9.2 THE SEMANTICS ~F A SELECTIVE LANGUAGE
There are two kinds of semantics in the selective language, the nantime semantics, and the file storage semantics. The runtime semantics mainly determine as to how elements of an object can be combined to form the object. The file storage semantics determine how an object can be stored, and to be combined with other objects in the Logical Data and Programs Base (for short LDPB). The LDPB is a set of files to store the objects and their relations of the application system(s).
Although the syntax of objects can be described, the semantics cannot. We can automatically identify as to what runtime semantics required in a group;
however, their process must be explicitly defined. For example, the runtime and the LDPB
semantics may be different for AI application systems, or database application systems, or for simulation application systems, etc.
Any application system (never mind as to what it does) is a set of open program objects and open data objects that may require a different kind of relations.
These relations are the semantics of the selective language. They have to be carried out by non-descriptive rules to achieve the system's objectives. That is, these rules cannot be described in a table using general rules. There are no semantics driven compilers or parsers; they are all syntax driven.
The system E-2002 can be used for any application systems) written in any programming languages) to recognize user's defined program objects and data objects belonging to these application systems) and to relate them according to the requirements by using non descriptive rules. These requirements may change depending in the domain of the application system and its objectives.

10. A DESCRIPTION OF AN ACTIVE SERVICE PAGE (ASP) SYSTEM
An ASP system is a complex one. It contains commands for the server and for the client. A user can write programs in 'Script and in Jscript. Moreover, these programs can contain static or dynamic SQL programs in any number (including none) and in any combination.
These commands, the VBScript programs, the Jscript programs, and the SQL
programs have a different syntax. A selective language has been developed for every programming language of the ASP. I-lowever, the structure of a selective language, and the structure of a group are the same for every programming language. That is, they are common for all these commands and the programming languages.
The system E-2002 is used for development, management, maintenance, and logical data independence for any application system from birth to the end.
Thus, we have also to recognize DDL, because they contain the data objects (tables, views, attributes, etc.) of an SQL program. A selective language, as before, is included for the user to specify the required objects from the DDL.

11. THE USED TE%T FILES DY E-2002 FOR AN ASP Sl'STEI~
The system E-2002 uses input and output text files.
The input text files are determined by the user and must be present before E-starts its process.
The output text files are produced by E-2002 to notify the user how the process took place and what has to be done (if any) to preserve the integrity of the database system.

11.1 THE Il~IPUT TE%T FILES
EfileUserDefinitions.ini This text file contains comments and definitions. A comment starts with the symbol '#' and is a single line comment. A comment can start at any column ofthe line.
A definition uses a macro name and the expansion of the macro name, separated by an '=' sign. A definition is case insensitive and can be written using free format. Thus a macro name can contain upper and lower case letters. A macro expansion is an integer number. A definition occupies an entire line. ~1o comment can follow a definition.
The purpose of this text file is to allow a user to specify dynamic storage allocation for the runtime structures, the records, and the files of LDPB.
Thus, a user can customize E-2002 as the user wishes.
Here is an example:
#the number of APPLICATIONS in LDPB
APPLICATions=30 #the number of bytes in an 'application name' APplicatIONNAME=52 EfileCrypto.ini This text file contains a long string defined by E-2002 and is used for security purposes. Every user of the system E-2002 is assigned an id name and a password by the DBA, including the DBA, as well. The user's password, before it is stored, is scrabbled by using this long string and an internal function of E-2002. If a user requests something from E-2002 the user's id and password must match the stored one; else no service offered to this user.
Efilemacro.ini This text file contains comments and definitions, as before. A comment starts with the symbol '#' and is a single line comment. A comment can start at any column of the line.
A definition uses a macro name and the expansion of the macro name, separated by an '_' sign. A definition is case insensitive and can be written using free format. Thus a macro name can contain upper and lower case letters. A macro expansion is string. A
definition occupies an entire line. No comment can follow a definition.
The purpose of this text file is to allow a user to replace strings that can appear in an SQL program with the proper SQL text. Thus a string can contain anything that a user wishes but when it is stored within an SQL program must create a correct SQL, program.
Here is an example:
#this macro is used for the SQL program in the method 'ADC' m3=employeelalame, salary, title from department Here is the SQL program in the method 'ADC' Select 8~m3 This will be expanded to:
Select employeeName, salary, title from department EscriptProEram.ini This text file contains a script program written in the 'Network >C?efinition Language' (for short NDL) by the user.
A script program may contain single or multiple line comments. They have the exact definition as in C++. That is, a single line comment starts with the symbol //. A
multiple line comment starts and ends with the symbols /* ... */. A comment (single or multiple) can be inserted anywhere the user wishes. No restrictions are applied.
A script program, also, contains directives that a user specifies:
~ The names of the schemes the network has, ~ The names of the I~I?L, a schema is using, ~ The names of the application systems a schema has, and The names of the modules an application system has.
Here is an example of a script program.
// the script for 'E-2002'.
// it started on November S, 2002.
/**********************************************************************
this script program has been stored in the text file'EscriptProgram.ini'.

the development started on Nov. S, 2002.
**********************************************************************/
//the first SCHEMA
for the schema CCC 1 use the DDLS 'c:\Easp\Eddll .ini°, °c:\Easp\Eddl2.ini ;
use the applications:
1) application AEC1 having modules: //this application has two modules 'c:\Easp\programs 1 \appl 1. ini ;
'c:\Easp\programs 1 \appl2. ini';
2) application ABC2 having modules: //this application has two modules as well 'c:\Easp\programs2\appl l .ini', 'c:\Easplprograms2lappl2.ini';
3) application ABC3 having modules:
'c:lEasp\programs3lappl 1. ini', °c:\Easp\programs3lappl2.ini ;
//the SECOND SCHEMA
for the schema CCC2 use the DDLS 'c:\Easp\Eddl3.ini', 'c:\EasplEddl4.ini';
use the applications:
1) application ABC1 having modules: //this application has two modules 'c:\Easplprograms4\appl l .ini', 'c:\Easp\programs5\appl2. ini°;
//the THIRD SCHEMA
for the schema CCC3 use the DDLS'c:\Easp\EddlS.ini°, 'c:\Easp\Eddl6.ini';
use the applications:

1) application EC having modules: /*the first module of this application is the same first module used in schema CCC1 application 'ABCI ' */
'c:\Easp\programs 1 \appl 1. ini', 'c:\Easp\programs3\appl2.ini ;
end;
i 1.2 THE OUTPUT TEXT FILES
EfileCreatedIlefinitions.ini This text file describes all the user's definitions with the specified values.
If the user does not like any of these values, the user can change the value in the file EfileUserDefinitions.ini and run the program Einitial.exe again.
Escr~tLinePro~ram.ini This text file is the user's script program that every line is enumerated. In this case line means every line; that is, empty lines, comments, and statements.
This text file helps the user to locate fast the error, if one occurs.
EfileDbaMessa~es.ini Some SQL programs may determine requests that change the content of the schema. For example, the commands 'drop', or 'alter', etc., change the content of the schema. Any change in the schema has ai~ects in the application system, whereas some may be informative and some may require immediate service. If this is the case, a set of messages are stored in the text file EfileDbaMessages.ini to notify the DBA as to what happened, where it happened, and what has to be done to preserve the integrity of the database system.
Here is an example:
***** A MESSAGE FOR IMMEDIATE SERVICE *****
---= it was created at 14:20:57 on Wednesday, 04/09/0:1 =----some rows have been deleted from the table °EIe~IPLOYEE°
(1) the ai~Fected program components:
it exi sts in the schema 'CCC 1 °
in the application °ABC 1 °
in the module °c:lEasp\programsl\appll.ini°
in the method °Echo' at line number'32' (2) these conditions are based on the attributes:
the attribute 'ENIPN° is part of the condition the attribute'Elvff'CODE' is part ofthe condition EfileLo~.ini This text file stores messages as to what has been parsed, and how successful the parsing was. If an error occurred the corresponding error is stored in this text file, as well.

12. H~Vf THE SYSTEM E-2002 FUNCT1~NS
12.1 The function 'Einitiai.exe' This function is the first one to be executed. Its purpose is to parse the text file EfileLJserDefinitions.ini to find out the size of the components that require dynamic storage allocation. For example, the number of characters for a table name, or the number of characters for the methods names, or the number of records for the methods in LDPB.
It stores this information (to be available for the parsers) and then initializes all the files of LDPB according to these specifications. If an error occurs the process ends and the user is notified about it.
If everything is OK this function summarizes all the specif ed things and stores them in a different format in the text file EfileCreatedDefinitions.ini for the user to review these values. If the user is not satisfied, the user can change any of the previous specified values and run again Einitial.exe. This program is not part of the parsers.

12.2 The parsers of E-2002 The system E-2002 has many parsers, one for every selective language. These parsers must recognize:
I . NDL program. This program contains descriptive statements to determine the distribution of schemas, DDL, application systems, and modules in the network.
These descriptive statements are written in the NDL language. All the languages, except NDL (the reason although obvious follows), are recognized by a selective language.
2. DDL programs. These programs contain statements written in a language specified by the used DBMS.
3. SERVER'S and CLIENT'S commands. These commands are written in the language specified by the server.
4. VBScript programs. These programs are written in the VBScript language.
5. Jscript programs. These programs are written in the Jscript language.
6. SQL programs. These programs are written in the ANSI SQL language.
The DDL parser has its own lexical analyzer. All the other parsers (SERVER'S and CLIENT'S, VBScript, Jscript, and SQL) use a common lexical analyzer.
Initially the system E-2002 checks if there are any messages for the DBA
(created by the previous parsing). If this is the case, E-2002 locks itself notifying the DBA as to how many messages require service. E-2002 does not functions when there are messages for the DBA regardless of any DBA's or any other user's request.
Then E-2002 expects the DBA to sign in. Upon success, E-2002 gets the users definitions to create the runtime structures and then the parsing ofthe script program begins.
A script program is the only one that is parsed using the classical parsing techniques. This is so, because no body parsed this program before; we have to know whether or not the script program was written using the proper syntax as defined by the NDL. The NDL parser contains a lexical analyzer, a syntactic analyzer, and a semantic analyzer. All the phases of this parser are table driven. The semantics table identifies the required semantic processes and not the processes. The NDL parser parses the script program twice. The first time lexical and syntactical analysis is applied to the script program; if everything is OIL the script program is parsed for the second time and this time semantics are applied. The NDL parser is the driver parser, so to speak.
That is, it starts and ends all the other parsers of E-2002. "The semantics of NDL and the order of occurrence are:
When a schema name found, NDL stores this schema in LDPB if the schema does not exist, else it announces error and the process ends.
When a DDL file name found, then the NDL parser stores the name of this DDL
in LDPB under the schema; if the DDL already exists it announces error and the process ends. Then NDL calls the DDL parser to parse this text file. The DDL parser parses the selective language for DDL. This parser recognizes and stores the names of the tables, the views, and the attributes along with changes, drops and additions that can occur on these objects. It is correct for a DDL file name to follow immediately another DDL
file name.
If an error occurs, the DDL parser stops E-2002. At the end the DDL parser returns control to NDL parser.
When an application name found, and it does not already exist under the same schema, the NDL parser stores this application in LDPB; else it announces error and the process ends.
When a module name found, and it does not already exist under the same application, the NDL parser stores this module name in LDPB; else it announces error and the process ends. These modules are the ones that contain a complete or a partial ASP system. Thus, the NI)L parser calls the SERVER'S and CLIENT'S parser. This parser cares about the commands that specify the beginning and the end of an ASP
system, the beginning and the end of a VBScript program, and the beginning and the end of a Jscript program. This parser works as follows:
When the beginning of an ASP system is recognized everything else is ignored, up to the time we recognize the beginning of a VBScript or a Jscript program.
When a VBScript program is recognized, the SERVER'S and CLIENT'S parser calls the VBScript parser. The VBScript parser parses the VBScript program.
When it finds the specified program and data objects, stores and relates them in LDPB
in such a way to achieve the required system's objectives. When an SQL program is recognized within a VBScript program then the VBScript parser calls the SQL parser. As before, when the specified SQL program and data objects are recognized, they are stored and related in LDPB in such a way to achieve the required system's objectives.
When the SQL parser ends the parsing, it returns control back to the Script parser. If the VBScript parser finds another SQL program, the SQL parser is called again, and the cycle continues. It is OIL for a VBScript method to follow another VBScript method.
When the VBScript parser ends the parsing ofthe Vl3Script program, it returns control back to the SERVER'S and CLIENT'S parser.
When the SERVER' S and CLIENT' S parser recognizes a Jscript program the Jscript parser is called and the previous process is repeated. That is, a Jscript program can contain any number of staticldynamic SQL programs (including none). If this is the case the SQL parser is called, as before. It is OIL for a Jscript method to follow another Jscript method. When the Jscript parser ends the parsing of the Jscript program, it returns control back to the SERVER' S and CLIENT' S parser, and the cycle continues.
When the SERVER'S and CLIENT'S parser ends the parsing returns control back to the NDL parser.
Now the NDL parser may find a schema name, or an application name, or a module name, or the keyword 'end'. If the keyword 'end' found that ends the NDL parser and thus the system E-2002. All the other cases repeat processes that have already been described.
The parser E-2002 parses programs written in many languages and at the same time creates diagnostics to notify the user as to how the parsing went. All this information including any error messages is stored in the text file EfileLog.ini.
Moreover, if at parsing time a change occurs in the schema all the affected programs are stored, including the schema, the application name, the module, the method, the data object, including the line number, with an explanation as to what happened.

13. THE LDPB ST)EtUCTZT>itE
The structures of LDPB are created and customized according to the DBA
needs. These needs describe non-runtime and nantime demands. It would not be wise to determine by default the size of data files and/or the number of bytes a table, or a module, or a method can have.
The LDPB is a complex hybrid structure (a forest of trees) whereas components of the network (i.e. schemas, DDLs, applications, etc.), and the user's objects are stored and related.
Every structure of LDPB follows the same structural rules as far as relations of structures are concerned; they may be summarized as:
~ the root of a tree is the schema name.
~ every structure in a tree has one pointer to identify its siblings.
~ every structure in the tree has one or more pointers to identify its dependent (or child) structure(s); except a terminal structure.
~ every structure has a back pointer to identify the parent structure; except the root.
The above structures represent the required structures a database system.
These structures may change if more or different objectives defined on a database system.
Moreover, other applications, i.e. AI application systems, or transportation systems, or any other application system may require different objectives and thus, these LDPB
structures may have to change.
The structural units of a tree, for this case, are defined. They are described for completeness; no claim is made that these are the only required structures for the system E-2002. Moreover, no claim is made that these exact structures can represent AI
applications, simulation applications, etc. These structural units are:
~ Schema, ~ DDL, ~ Applications, ~ Modules, ~ I~Iethods, ~ SQL programs, ~ SQL commands, ~ Alias, ~ Tables, ~ Views, arid ~ Attributes, The structure 'schertta' The structure of the schema is the highest-level structure in the tree (or root) in LDP13. This structure is represented as a single link list, and each record of this list represents a schema. The totality of these records represents all the schemas in the network.
Each record of this list has many pointers identifying various components, but there are two important ones that identify all the applicatio~a systems and the tables/views that belong to the schema.
The structure 'IDDL' The structure of the DDL is represented by a single link list, and each record of this list represents a DDL name in the schema. A schema can have many DDL. The totality of these records represents all the DDL in the network.
The main pointer of this structure is the back pointer to schema.
The structure 'applications' The structure of the applications is represented by a single link list, and each record of this list represents an application system. A schema can have many applications.
The totality of these records represents all the application systems in the network.
Each record of this list has many pointers identifying various components, but there is an important one that identifies all the modules of this application system.

The structure 'm~dules' The structure of the modules is represented by a single link list, and each record of this list represents a module. An application can have many modules. The totality of these records represents all the modules in the network. A module may contain a complete or a partial ASP system.
A module record has many pointers but there is one that identifies the methods of the module.
The structure 'Meth~ds' The structure of the methods is represented by a single link list, and each record of this list represents a method (internal and/or external). A. module can have many methods. The totality of these records represents all the methods in the network.
Each record of this list has many pointers identifying various program and data objects as the user has specified them. These objects are subjective and as such cannot be precisely determined. Some program objects may be: the names of the called methods, and/or the names of the defined methods, and/or the control statements (i.e.
if, else, do, while, switch, etc), and/or the labels. Some data objects may be: the argument list of a call statement, and/or the parameter list of a method definition, and/or the relational expression of an 'if statement, etc. (if any of these structures is required, it can be represented as a single link list, as they have been presented so far). There is also a pointer that identifies the SQL programs that this method has.
The structure 'SQL~rograms' The structure of the SQL programs is represented by a single link list, and each record of this list represents an SQL program static or dynamic. A method can have many SQL programs. The totality of these records represents all the SQL programs in the network.
An SQL program has many pointers but there is one that identif es the SQL
commands this SQL program has.

The structure 'SOL commands' The structure of the SQL commands is represented by a single link list, and each record of this list represents an SQL command. An SQL program can have many SQL
commands. The totality of these records represents all the SQL commands in the network.
An SQL command has many pointers but there is one that identifies the attributes of the SQL command (if this command identifies attributes), the SQL functions if any, and the tables/views (if this command identifies tableslviews).
The structure 'SOL functions' The structure of the SQL functions is represented by a single link list, and each record of this list represents an SQL function. An SQL command can have many SQL
functions. The totality of these records represents all the SQL functions in the network.
An SQL function has many pointers but there is one that identifies the argument of this SQL function.
The structure 'Tables and Views' The structure of the tables and views is represented as a single link list, and each record of this list represents a table or a view. The totality of these records represents all the tables and views in the network.
Each record of this list has many pointers. There is a pointer that identifies the attributes that belong to a table or a view. Moreover, for a table there is a pointer that identifies which attributes of this table are used to create a view(s). Also, for a view there is a pointer that identifies the attributes of a tables) or views) used to create this view. A
pointer of a table/view identifies the alias names) used for this table/view in the SQL
program.
The structure 'attributes' The structure of the attributes is represented as a single link list, and each record of this list represents an attribute. A table/view has many attributes.
The totality of these records represents all the attributes in the network.
The main pointer of this structure is the back pointer to table/view.

The structure 'alias' The structure of the alias is represented as a single link list, and each record of this list represents an alias name. A table/view can have many aliases names.
The totality of these records represents all the alias names in the network.
The main pointer of this structure is the back pointer to table/view.
13.1 THE 1LTSERS OF 1,DP°B
The LDPB is used by the DBA and by authorized users. Only the DBA can read and write information in LDPB. All the other users can only read information from LDPB. For example, the DBA can store a new application system, or a module, or delete a program component, or a table etc. A user may request which tables) and/or views) are used by a method, etc. Any user, including the DBA, is using ilser Graphical Interface (or GUI) to interact with the LDPB.

14. HOW TFIE 'FLY' PROPERTY OF E-2002 IS GENERATEL7 This property allows a user to see on the fly the code of any program component in isolation. A program component may be a module, method, or an SQL program, etc.
These program components are not specified; they are determined by default by E-2002. Let us say, a user wishes to see the code of an SQL programs) and only this code isolated from any other code of the method that it belongs to. Then E-2002 offers to the user this exact code on demand.
This is how it is done. When a parser recognizes a program component, it stores the program component name and its bound lines (starting and ending line) in LDPB.
When the user request the code of a program component, E-2002 searches the LDPB for the name of this component. When it f nds it, it extracts the bound lines;
next, the source statements with these bound lines are read and displayed.

Claims