GDPA  
E-Type Systems  

A-B-C- D-E-F- G-H-I- J-K-L- M-N-O- P-Q-R- S-T-U- V-W-X- Y-Z

Identification

E-Type Systems

Definitions/Uses

1997
Reference /Lehman, 1985a/ Software Evolution - Processes of Software Change
/Lehman, 2000b/ Rules and Tools for Software Evolution and Management
Definition/
Use
E-type systems are those actively used and embedded in a real-world domain /Lehman, 1985a/. Once operational they are judged by the results they deliver and the degree of satisfaction of their stakeholder with them. In addition to functionality, factors such as quality (however defined), behaviour in execution, performance, ease of use, changeability and so on will be of concern.
In this they differ from S-type programs.
1993
Reference William Aspray interviews M. M. Lehmann
Definition/
Use
The third type of program I called E-type where E stands for "Evolutionary." It is the study of the E-type programs that has been my concern for 25 years. E-type programs address a problem or an application in the real world. In this domain the concept of correctness has no meaning whatsoever for two reasons. Firstly because the real world is infinite and continuous, and therefore you cannot come up with an exact or complete specification.
When you build an E-type program, you construct a finite model of an unbounded or infinite real world. The program has to be finite because you only have a finite time to produce it, and a finite memory in which to store it. Moreover, the program and the process it controls are discrete since that is the only way we can represent information and execute instructions in a digital computer. But the real world is essentially continuous. Thus the programmer's model is an approximation of the real world. It is not a precise representation of the real world. It cannot be. Inherently not. In order to represent an infinite, continuous world by a discrete finite model, one has to make assumptions. And those assumptions are imbedded in the design and implementation of the program. But the real world is always changing. In fact, creating or using the program accelerates that rate of change. Therefore some of the assumptions that are made and embedded in the program make will become invalid in the course of time, and you may not know that. These observations lead to a principle known as Lehman's Uncertainty principle, which says, "No E-type program can ever be relied upon to be correct" in the sense that one cannot know that all the assumptions you made explicitly or implicitly while creating the program and which are embedded in the design, the code and the documentation are still valid, even though they may have been valid when you took them. So you cannot know that the program is correct. It may be correct, but you can't know it. One has to accept that the outcome of any execution of any E-type program is, at an absolute level, unpredictable. That's only one of three aspects of uncertainty.

See also

Glossary S-Type Systems

GDPA Online Last Updated 29.May.2002 Updated by Webmaster Last Revised 29.May.2002 Revised by Webmaster