PREVIOUS
Chapter 5. Productivity in KeyKOS
The 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
NEXT