Figure 5-1The segmentation of both the operating system and applications into many domains with explicit control of the communication paths between them results in a significant reduction of the effort required to develop and maintain reliable systems. This increased productivity is manifested throughout the testing and maintenance phases of the product life cycle. As an additional benefit, application programs may become simpler since much of the complexity of conventional applications is to overcome operating system limits that do not exist in KeyKOS.
Debugging occurs at two levels in KeyKOS. When testing a single domain, the tester will usually run in an environment where the domain can be completely controlled. This mode is often called unit testing. When unit testing is complete, and all of the domain's inputs and outputs have been tested, the domain may be integrated into the application. At this time, it may be desirable to install transaction logs or transaction debuggers between objects. Debugging of interactions between domains is often called integration testing.
A major maintenance problem with systems that have long lifetimes, is the tendency of old code to get "dirty". A once splendid design architecture gets cluttered with expedient fixes resulting in a large number of implicit linkages between "unrelated" components. An innocent modification to a component of such a system, that operates perfectly in unit test, may cause the system to fail when it is installed. This process results from maintenance programmers' failure to understand the implications of certain changes.
Because KeyKOS enforces structured programming principles at execution time, there is no possibility of such implicit interactions between components. If a problem is entirely within one component, it can be fixed without danger of inflicting damage upon other components. As long as the interface protocols between the components remain unchanged the effects will be localized to the fixed component. If the problem is the result of a failure of communication between components, then a formal communication path must be established or modified. Since these interactions are explicit, rather than implicit, the future maintainers will be aware they exist, and will be able to react appropriately.
Between 50 and 80 percent of a typical data processing shops' programming resources go into maintenance and enhancement of existing applications. In this environment there are often two incompatible goals: eliminating bugs to achieve consistent reliability, versus incorporating new function or enhancing performance. Minimal change reduces the risk of introduced bugs, while change is necessary for new features. This dilemma occurs at all levels of the computing system. Constant tradeoffs must be made, not only for installation written code, but also for vendor supplied code. For example, the decision to upgrade to a new release of an operating system or compiler is an agonizing one for many. It is well known that when it is installed, some number of operational programs will probably fail. At the application level, conversion has similar exposures. On the other hand, failure to upgrade has significant costs. Installations that choose to freeze either their applications or operating systems will continue to experience bugs that were fixed years earlier. KeyKOS offers the flexibility to allow a system to be upgraded at the domain level. It also allows a new version of a module to be backed up by an older, more reliable version.
Segmenting an application into a number of self-contained domains is a form of structured design. KeyKOS enforces such structured methodologies at execution time, insuring that the architecture is not compromised in the implementation. The previous discussions of debugging, separation of function, and carefully controlled change have exact parallels in structured design. KeyKOS represents that theory at an operating system level.
Distributed processing is much easier to implement in KeyKOS than in other systems. Since applications are constructed as a number of independent domains, it is a simple matter to move some of the domains to another system. A domain that implements a general KeyKOS import/export function is spliced into the connection between domains on different machines.
Note that this operation is completely transparent to the domains in question (with the possible exception of performance). All of the complex protocols for remote access of data are in the import/export mechanism, not in the application programs. It is easy to develop and test the application on one system without remote systems for debugging. Applications may also be developed for a single system and distributed at a later date without reprogramming.
Figure 5-1