Appendix H |
Guidelines for Choosing a Computer Language: Support for the Visionary Organization |
Appendix H: 4GL or 5GL
4GLs are typically used to meet special needs of data processing, with such applications as databases, spreadsheets, and program generators for use by non-expert programmers [Ghezzi 87]. 4GLs typically have properties such as [Appleby 91]:
The intent of 4GLs is to "make languages easy to use so that end users can solve their own problems and put computers to work" [Martin 86]. However, a 4GL must be selected to fit the particular application, unlike 3GLs, which tend to be more general purpose. 4GLs are essentially non-procedural, whereas 3GLs tend to be procedural, but there is no standard definition. The term 4GL is actually very imprecise, and it is used for marketing reasons to describe many modern application development tools. [Appleby 91] [DoD 87] [Glass 91] [Martin 86] [Misra 88] [Verner 88] [Wojtkowski 90] A 5GL is essentially a 4GL that uses a knowledge-based system [ANSI/IEEE 90], although some such systems are also called 4GLs. A 5GL tends to be a more complete development environment than a 4GL, and its concept is for all code to be automatically generated. Then a system is maintained by modifying the 5GL statements, rather than manually changing the generated code. [Connors 94] Language CriteriaIt is impossible to assess every possible 4GL or 5GL of interest because these language applications are numerous, and more are appearing all the time. It is important to note that these languages vary widely in capabilities and intended purpose. Some newer ones, such as Visual Basic and Powerbuilder, are particularly powerful with respect to ease of programming and prototyping capabilities. Others, such as SQL and Oracle, have been around for a while but continue to provide powerful capabilities for interfacing with databases. All languages in this category also share many concepts. A specific language should be examined in terms of how its specific purpose matches the current need, and its particular characteristics should be assessed with respect to the language criteria. The general category of 4GL and 5GL languages is considered in this appendix. The assessments can be used to guide the assessment of a specific language. Hence, the following assesses the category of 4GLs and 5GLs with respect to the language criteria presented in the Criteria for a Good Language section in the main document:
In this section, 4GLs and 5GLs are rated with respect to the language characteristics used in Table 2 in the main document [Appleby 91] [DoD 87] [Glass 91] [Martin 86] [Misra 88] [Verner 88] [Wojtkowski 90]. The given ratings are for this category of languages, rather than a specific language. Hence, a given rating is intended to be typical of a 4GL or 5GL, but a rating may not be representative of every product. The ratings range from 0 to 10, where 0 means the language provides no support for the characteristic, and 10 means it provides extensive support. The ratings given below are those provided in Table 2. The reader must bear in mind that the support for a good characteristic in a language does not necessarily mean that it is always used, or used appropriately. Unskilled programmers can write bad code in any language, but a good language facilitates the production of good code by skilled programmers. Clarity of source code – the extent to which inherent language features support source code that is readable and understandable and that clearly reflects the underlying logical structure of the program. For this characteristic, the source code consists of the commands used by the programmer, and this varies greatly with different 4GLs and 5GLs. Many use graphical interfaces or menus that require very little typing. The higher the language level, the better the code clarity tends to be because of the nature of the commands used. However, to the extent that the commands are text-based, they tend to be full of abbreviations and not completely descriptive. This rating will vary with different products, with the given rating considered typical. Rating: 5 Complexity management (architecture support) – the extent to which inherent language features support the management of system complexity, in terms of addressing issues of data, algorithm, interface, and architectural complexity. A 4GL or 5GL tends to target a relatively small application, and complexity management is not one of the development considerations. Complexity is usually managed only through the use of abstraction. Rating: 2 Concurrency support – the extent to which inherent language features support the construction of code with multiple threads of control (also known as parallel processing). Support for concurrency is not usually represented in 4GLs or 5GLs. Rating: 0 Distributed system support – the extent to which inherent language features support the construction of code to be distributed across multiple platforms on a network. In general, 4GLs and 5GLs provide no support for distributed systems. Rating: 0 Maintainability – the extent to which inherent language features support the construction of code that can be readily modified to satisfy new requirements or to correct deficiencies. If the 4GL or 5GL is used as intended, maintenance is performed on the high-level commands provided by the development system, rather than on the low-level code intended to be understood by the computer. To the extent that this concept is used, the maintainability is generally good. Understanding the program from the high-level commands facilitates maintainability, and small changes will usually not impact more than a small number of the high-level commands. However, the low-level code tends to be very difficult to understand, and making changes at that level is not easy. Since most current 4GL development systems cannot automatically generate all of the necessary code for many applications, and the ability of a 5GL to generate all necessary code is still in doubt, maintenance must consider working with some low-level code. Rating: 5 Mixed language support – the extent to which inherent language features support interfacing to other languages. 4GL and 5GL systems are not usually concerned with interfacing with other languages, although other languages are often concerned with interfacing with a 4GL such as SQL. When procedural commands are needed, a language is usually provided for that purpose by the 4GL or 5GL, rather than relying on a conventional 3GL. This is an inherent weakness because the procedural language provided is typically not as rich or expressive as a conventional 3GL [Misra 88]. Rating: 0 Object-oriented programming support – the extent to which inherent language features support the construction of object-oriented code. Although a 4GL or 5GL uses high-level commands, and it is possible for these to be object-oriented in nature, they usually are not. Constructing object-oriented code is rarely an issue. Rating: 0 Portability – the extent to which inherent language features support the transfer of a program from one hardware and/or software platform to another. Since a 4GL or 5GL is used more like an application than a language, portability is not a major goal. SQL is portable to a certain extent because it is standardized (an exception rather than a rule in a 4GL or 5GL), but since most applications use non-standard features, its portability is also limited. Rating: 1 Real-time support – the extent to which inherent language features support the construction of real-time systems. Real-time systems are not usually a concern of 4GLs or 5GLs, although there are a few exceptions for which the given rating should be changed accordingly. Rating: 0 Reliability – the extent to which inherent language features support the construction of components that can be expected to perform their intended functions in a satisfactory manner throughout the expected lifetime of the product. Reliability is not usually a primary concern for a 4GL or 5GL application. Rating: 3 Reusability – the extent to which inherent language features support the adaptation of code for use in another application. Since a 4GL or 5GL is used more like an application than a language, reusability is not usually a goal. Only a widely-used and standardized language, such as SQL, could be reasonably considered for reuse. However, SQL does not have inherent characteristics, such as encapsulation, which lends itself to reusability. Rating: 1 Safety – the extent to which inherent language features support the construction of safety-critical systems, yielding systems that are fault-tolerant, fail-safe, or robust in the face of systemic failures. Safety systems, those concerned with putting human lives in jeopardy, are not supported by current 4GLs or 5GLs. Rating: 0 Standardization – the extent to which the language definition has been formally standardized (by recognized bodies such as ANSI and ISO) and the extent to which it can be reasonably expected that this standard will be followed in a language translator. Since 4GLs and 5GLs are more like applications than languages in the way they are used, only a few have been concerned with standardization. Of these, SQL is probably the most popular because it is widely used as a database query language. The SQL ANSI and ISO standard provides a baseline language, and implementations are likely to provide additional language features as well. Rating: 1 Support for modern engineering methods – the extent to which inherent language features support the expression of source code that enforces good software engineering principles. Since a 4GL or 5GL is used more like an application than a language, specific support for engineering good software is not usually a concern. The emphasis is on making the development system easy to use. However, some types of poor practices are discouraged or prohibited because of the high-level mechanisms provided for the user to interact with the system. Rating: 3 |
< Previous Page | Search | Contents | Tables | Next Page > |
Sections
1 | 2 | 3 | 4 | 5 | 6 | 7 |
Appendices
A | B | C | D | E | F | G | H | J |
K | L | M | N | P | Q | R | S |