Uniform Software Modules
Conventional operating systems support a wide range of software structures, such as programs, subroutine libraries, operating system modules and files. This considerably complicates an operating system, not only because each different structure has to be implemented separately but also because a multiplicity of mechanisms is needed to allow these to be linked to each other.
Together with several research students Prof. Keedy defined a module structure capable of supporting all kinds of software resources in a uniform way. This is based on David Parnas's information hiding principle. In the persistent memory of the Monads systems every major system resource is defined as a code module with multiple entry points and an optional persistent data structure.
A conventional program is simply a code module with a single entry point. However, since entry points are defined as normal procedure calls, a program can receive parameters and can be called directly from other programs using the standard inter module call mechanism.
A conventional subroutine library is structurally identical to a program, except that it typically has multiple entry points. The following diagram shows how a graphics library might appear.
A file in Monads is not a free standing data structure but is an information hiding module consisting of a code module and a hidden persistent data structure, which can be only be accessed indirectly via the entry points of the associated code module, which is its type manager. The following diagram illustrates how a bank accopunts file might appear.
Operating system modules of all kinds can be implemented in the same uniform structure. For example a process scheduler has entry point routines such as "create process", "claim", "release", etc. and a persistent data structure in which the state of processes is recorded, as is shown in the next diagram.
Similarly a directory is simply a file module holding information about other files.The following diagram illustrates a directory module as an information hiding file.
Other kinds of operating system modules (e.g. a command language interpreter) are simply programs. Thus there is no difficulty in treating an operating system, like all application modules, simply as information hiding modules with a uniform module structure.
It also becomes possible, given such a uniform structure, to implement "mixed" modules which under a conventional system do not easily fit into a standard category. As an example consider the following compendium of games, which consists of several "programs" that can take advantage of using a single chess board structure and also allows user preference settings to be stored simply as an integrated "file".
Among the advantages of this approach are
- that the system supports a modular structure conducive to good software engineering techniques
- a considerable simplification of the operating system through the need to support only one structuring mechanism and only one linking mechanism
- flexibility for the user because any module can be linked to any other in a simple uniform way
- that all software resources can be protected in a single manner, based on the right to call the entry points of the module by presenting a module capability.
These ideas were first formulated in the design of the Monads I system:
Keedy, J.L. "The Influence of the Information-Hiding Principle on the MONADS Operating System", Proc. Australian Universities Computer Science Seminar, Sydney, 1978, pp. 1-7.
Keedy, J.L. "The MONADS Operating System", Proc. 8th Australian Computer Conference, Canberra, 1978, pp. 903-910.
Richards, I. and Keedy, J.L. "Subsystem Management in the MONADS Operating System", Proc. 8th Australian Computer Conference, Canberra, 1978, pp. 1520-1529.