BDL(ID:3970/bdl002)High-level IBM database language for describing business applicationsfor Business Definition Language High-level IBM database language for describing business applications Part of Business Definition System (BDS) People: Structures: Related languages
References: in Clemens Hackl (Ed.): Programming Methodology, 4th Informatik Symposium, IBM Germany, Wildbad, September 25-27, 1974. Lecture Notes in Computer Science 23 Springer 1975 view details in Clemens Hackl (Ed.): Programming Methodology, 4th Informatik Symposium, IBM Germany, Wildbad, September 25-27, 1974. Lecture Notes in Computer Science 23 Springer 1975 view details in Clemens Hackl (Ed.): Programming Methodology, 4th Informatik Symposium, IBM Germany, Wildbad, September 25-27, 1974. Lecture Notes in Computer Science 23 Springer 1975 view details An example of these is the Business Definition System (BDS) being developed at IBM Research. In this system the application definer describes the operation of a firm in Business Definition Language (BDL). A complete description involves five substeps. First, the graph of information flow in the system is specified; that is, one lists the points at which information is processed, the documents that flow into each point, and the documents that flow out. Next, one specifies the transformations applied to inputs at each point to produce the necessary outputs. Third, one specifies the formats of the particular documents that will be used in a computerized version of the system being described. Fourth, the points at which manual interactions are required are specified. Finally, one specifies the specific devices for instance, point-of-sale terminals which support the various manual interactions that are needed. These specifications are supplied by filling in English phrases in a tabular blank, a form of input that should be comfortable for businessmen. Once a BDL specification has been completed and corrected as necessary, it should be possible to generate the system it describes automatically. using standard program modules. Abstract: DOI Extract: Structure of the Language Structure of the Language The view we take of business data processing manifests itself in the four kinds of objects recognized by BDL: Documents are the fundamental data items with which a BDL program transacts. They are organized structures of primitive values and serve as input and output to a program as well as internal representation of information. Steps are the basic objects in the program, corresponding to the organizational units of the system being described. Steps may be composite (formed from more primitive steps) or irreducible, in which case they describe how their output documents are created from their input documents. The computation of the program is captured in the descriptions of the steps. Paths connect steps and indicate the flow of data within the program. Documents created as output by one step flow over paths to serve as inputs to other steps. Files are permanent repositories of documents. They are stores for documents that must persist between different parts of the program or between different activations of it. There are several components of BDL which together describe the nature and relationships of these objects for a particular system and provide a complete specification of the computations to be performed. The major three of these components are known as the Form Definition Component (FDC), the Document Flow Component (DFC), and the Document Transformation Component (DTC). FDC defines the forms on which the documents appearing in the program are filled out; DFC defines the overall application organization and the structural relationships of the steps; DTC specifies how an irreducible step computes its output documents from its inputs. Each component has its own "language" in which the relevant information is expressed. The BDL application specialist does all his program development using a highly interactive system [8] currently under development. As will become clear, the terminal for use with this system must have modest graphic capability. This interactive system and its terminal will not be described here, but the basic idea must be kept in mind for some of the specifics of BDL to be credible. Extract: Form Definition Component Form Definition Component As we have said, the basic data structure of BDL is the document. Documents in BDL mirror very closely those in the real world: simply data filled out on a form. Forms are the templates with which specific documents are produced. They consist of preprinted information plus specifications about the data used to fill them out. In FDC [9], the user describes the forms that are needed in the program. At any point, there may be many documents filled out on the same form, (i.e. order documents for different customers on the same order form), but they will all conform to the organization and restrictions imposed by that form's definition. The initial step in defining a form is to give its name and its width and height in character positions. This is followed by specifying its preprinted information: what a blank document would look like. Preprinted information consists of column headings, boxes, and the like. This information is represented directly by drawing it on a graphic device over an array of rectangles used to show character positions. The remainder of a form's definition consists of several definitions of the various properties of the form. Each property has its own method of definition, but all are done by adding information to the form shown on the screen. A description of these form definition properties follows. Field definition The form is filled out with the names of the fields. Groups of fields are shown by repeating the name at least once; groups of collections of fields are shown by repeating the entire structure of names at least once. (In BDL, a group is a collection of homogeneous elements.) Field names may not be longer than the field they name; if they are shorter, they are extended with a special extender character. Thus a field name specifies not only the location of the field but also its size. Data type definition The form is filled out with data type names for each field. The data types provided are richer than is the case for many programming languages: specific data types such as ADDRESS, DATE, INCHES, and DOLLARS are available. This permits better error detection and automatic conversion between fields of like dimension but different units. Data format definition The form is filled out with sample data generated by the system to show an example format for each field. The format of any field can be changed by the programmer by selecting an alternative from a list of samples generated by the system. This sample data is chosen from a list of values generated according to the data type and field length. For example, the list of data values for an eight character field of type DATE would be 1/31/56, 1-31-56, 31/1/56, and 31-1-56. Other possible formats for DATE fields, such as 31 JAN 1956, are not shown since they are too long. Field aggregate definition Any group of fields on a form must be given a name. Also it is sometimes desirable to give a name to structure, which is a number of fields with different names. Names of repeating groups and structures are defined by starting with a form filled out with field names. -The field names forming an aggregate are replaced with the aggregate name just as though it were a field itself: the field name plus any needed extender characters. Group ordering definition-All groups in BDL are unordered from a computational point of view. However, when documents are produced as output, it is clearly necessary to have groups ordered correctly. Any number of fields within a group which are not within a contained group may control that group's ordering. This is defined by filling out a form with order symbols: one order symbol for each field controlling some group's ordering. The order symbol can specify ascending or descending as well as the precedence of ordering. Float control definition Float control is the description of what to do with the fields following a group when that group is smaller than the maximum size defined. It might be required that a field immediately follow the group if it were, say, a total of the group. On the other hand, it might be required that the field remain fixed; the field might bear no relationship to the group for example. This specification is accomplished by drawing lines called float control lines on a form. These lines are barriers over which fields are not permitted to float. Whenever a group takes fewer character positions than its maximum, all following fields are moved upward and leftward to the extent permitted by the float control lines. Any character positions defined to be between fields are, of course, preserved. Not described here is the control of form overflow: what to do if the information on a document does not fit on a single form. This essentially involves two form definitions, one for the first or only form and one for any necessary overflow forms. in [ACM] CACM 20(11) November 1977 view details Application Specification Media and Aids The direction that work in the DPS-type based approach has taken is toward making it easy for the user to describe his application. Simple and concise descriptive media for describing the user's processing requirements and the data his application uses and generates have been developed. The ISDOS APS uses the ADS, SSL and PSL languages, all of which involve RPGlike forms to be filled out by the user. Protosystem I makes use of HIBOL, an English-like statement language (like COBOL, but at a higher level of abstraction). The power and simplicity of these languages is most easily Illustrated by a short HIBOL fragment. If PAY, HOURS_WORI indicates that for each employee for which there is a record in the HOURS_WORKED file, the PAY file will have a corresponding record with an associated value obtained by multiplying the number of hours the employee worked by his hourly rate. The iteration through the files involved, the file i/O, record generation, EOF checking, and so forth, which would have to be explicit in a PL/I program equivalent to this statement, are all implicit here. The development of simple descriptional facilities for the full range of more complicated common data processing activities such as summation and the maintenance of running totals is the subject of continuing research. At USC/ISI a research effort is currently underway that is aimed at allowing the user to express his application specification in English. This promises the ultimate in user convenience, but natural language comprehension by machines is difficult. It is conjectured, however, that the usually formidable problems of ambiguity and detail suppression (e.g. anaphoric reference) will be mitigated to, some degree by the highly constrained nature of the processing described. That is, it is felt that tentative program attempts will act as effective filters of possible alternative interpretations of the English specifications. Another way in which the developers of APS's are seeking to make the description process easy for the user involves the use of consistency and completeness checks. Whenever parts of a user's description are inconsistent (e.g. he associates different keys with the same file in different places) the clever system will point this out and demand resolution. Completeness checking (e.g. is the source and destination of all data specified?) can be used to guide the user in his specification effort, too. The ISDOS and MODEL systems provide such aids to the user. Abstract: To meet the burgeoning software demands of the future the computer will have to take a more active role in the writing of its own software. Many computer tools have been developed that enable the machine to help human software developers. It would be preferable, and in the not too distant future it will be necessary, for the machine to actually take over a substantial part of software development. Automatic programming seeks to do this by moving the human developer up from the implementation level of programming (e.g. COBOL, where the human has to include such details as data and control structures), to a level of programming that is less specific, where it is left to the computer decide the best way to fill in implementation. This article provides a survey of current research and development in automatic programming and a dlscussion of future directions in this field. in [ACM] CACM 20(11) November 1977 view details |