Project requirements specification

Project requirements specification
SchemeStation documentation

1 Introduction

The SCHEMESTATION project involves designing and implementing a prototype of a new distributed agent-oriented operating system carrying the name of the project.

The main use of the finished prototype is to be scientific research. The prominent objective of creating the prototype is to provide an environment for experimenting with distributed agent-based operating systems.

This document is structured as follows.

1.1 Terminology

Some of the terms appearing in this document are defined in Terminology specifications.

2 Overview

The SCHEMESTATION operating system is a proposed agent/actor-based distributed operating system featuring:

In this project, a prototype of this operating system is built on the top of a UNIX environment. More specifically, a simulator is designed that runs as a set of UNIX user-level processes. The UNIX system to be used for development is not specified. However, the system should be easily portable to most major UNIX systems in order to make the system useful for research in heterogenous environments.

Any tools available are allowed to be used during development. However, it must be possible to build the resulting, final system using standard or other common UNIX tools also. Common GNU tools are included in this set, for example the GNU C compiler and GNU make.

2.1 SCHEMESTATION operating system architecture

The general architecture of the SCHEMESTATION operating system is presented here. The unit of execution is an actor (or agent). Actors are contained in domains. Inside one domain every actor must have a unique address (name). This restriction does not apply to actors in different domains. Because actors inside one domain share an address space, domains are expected to correspond often to logical or physical computers or CPUs. One workstation running the SCHEMESTATION operating system could be one domain.

The actors communicate using asynchronous message passing. Communication can happen inside one common domain (intra-domain communication) or across domain boundaries (inter-domain communication). These two forms of communication do not have any fundamental differences, though.

Actors are able to migrate from one domain to another. Migration is transparent. This means that other actors communicating with the migrating one do not need to know about the migration act nor to respond to it in any special way. This all is illustrated in Fig. 1.


Fig. 1. Actors and domains in SCHEMESTATION

Communications between domains are cryptographically secured. This is not enough, however, for ensuring a secure computation environment as some domains might be malicious or just untrustworthy. For this reason trust relations can be maintained between domains, and these relations can be used as a basis for deciding upon certain acts. For example, in Fig. 2 three domains are shown which have the following trust relations: Domain 1 trusts Domain 2 to be a good source and good target for migration (i.e. it is safe to move actors to run in Domain 2, and also to receive actors from Domain 2 to be executed locally). Domain 2 trusts Domain 1 similarly. However, between Domain 2 and Domain 3 migration can happen only from Domain 2 to Domain 3 as Domain 3 does not trust Domain 2 to be a good target for migration; nor does Domain 2 trust Domain 3 to be a good source. These trust relations are use by the domains to control actor migration.


Fig. 2. Trust relationships between domains

3 Functionality

The developed prototype must contain the following functionality:

  1. It can be run in a supported UNIX environment.
  2. It can be used to simulate multiple domains and the communications between them. Some objectives are to be able to simulate communication faults easily and to observe the amount of data transferred between distinct domains.
  3. It is possible to observe the internal workings of a domain to some extent (system debugging).
  4. Domains are able to run multiple actors that execute byte code instructions.
  5. The memory model for individual actors is a list-structured heap. Every actor has one heap that is read and modified by the byte code program.
  6. Actors are able to send and receive messages.
  7. There is simulation for some I/O facilities, at least for a text-based terminal, in order for the user(s) to be able to communicate with the system.
  8. A cross-compiler exists for generating byte code programs from a dialect of Scheme.
  9. The notions of trust relationships and cryptographic authentication are considered and support for them exists.
  10. Actors are persistent over multiple simulator executions as long as the simulator is started and terminated using procedures defined by the system designers.
  11. Some example applications are developed in order to demonstrate system use. These applications could include:
    • some kind of a shell
    • electronic mail system between SCHEMESTATION users
    • distributed games
    • compiler running in the SCHEMESTATION system itself

4 User Interface

There are actually two user interfaces in the system. First, there is the interface between the user and the simulator; second, there is the simulated interface between the user and the SCHEMESTATION system (i.e. the simulated terminal).

The choice of the nature of both of these interfaces is free as long as the other requirements specified are fulfilled.

5 Non-Functional Features

5.1 System Performance

The project is about creating a simulator, and the performance issues concerning simulators are to some extent secondary. However, the following rough limits for acceptable system performance are set:

  1. It must be possible to run hundreds of actors inside one domain.
  2. It must be possible to simulate tens of mutually communicating domains simultaneously.

5.2 Usability

The issue of usability is divided into two subrequirements.

  1. It must be able for an average computer science student to learn to use the system in reasonable time.
  2. A computer scientist should be able to understand the design and implementation details of the system in reasonable time, and to extend and modify the simulator when necessary.

5.3 Failure Situations

The simulator itself should be reliable and work correctly in normal working conditions (i.e. fail only when there is a hardware or software failure somewhere else affecting the system).

Actors failing to perform their tasks due to logical errors in the algorithms they use or due to invalid byte code instructions etc. should be handled by the simulator as specified by the operating system design.

5.4 Documentation

As the resulting tool is directed towards scientific use, the quality of detailed documentation is important.

In particular, the following documentation is required to exist in some form in addition to full source code:

  1. System installation instructions
  2. System design overview
  3. System design details
  4. System implementation documentation
  5. Compiler manual
  6. Compiler design documentation
  7. Instructions for extending and modifying the simulator when necessary
  8. Description of the example programs distributed

5.5 Portability

The system should be easily portable to most major UNIX systems. However, the portability need not to be tested for all of them. Parts of the software that are most likely to have system dependencies should be isolated to modules of their own in order to make their modification as easy as possible, should portability problems nevertheless occur.

6 Quality Plan

The most important of the goals of this project are enumerated below in the order of precedence.

  1. That the implementation of the system is easily understandable for computer scientists, and for at least some computer science students.

    Achieving this goal can be observed during the project by examining the chosen design principles and the written source code. Discussions with the client are held to ensure that the client, who is a computer scientist, is able to comprehend what has been done and agrees with it.

    This goal is tried to achieve by (1) using a well-defined coding policy, (2) making the system design modularly and (3) discussing with the client.

  2. That the system is able to simulate actors running asynchronously, and that a user is able to observe the results of this simulation.

    It is easy to observe whether or not this goal has been achieved at the later parts of the project. If this goal fails, the whole project can be seen as failed. The main method for ensuring that the goal will be achieved is to keep care of that the project schedule is not much late. Small lateness does not endanger this goal, as more project work has been scheduled after this main functionality has been reached. Lateness endangers the work at the end of the project, but not this goal as it should be achieved before the end stages.

    This goal is tried to achieve by completing the main parts of the system, even if some kind of failure causes the project not to achieve all of its goals.

  3. That programming new actors and incorporating them into the system is moderately easy.

    This goal is a high-level quality and usability goal. During the project progress towards achieving it can be observed by examining the implemented and emerging user interfaces of the simulator and the [cross-]compiler. It should be possible to create new types of actors without knowing about the details of the compiler and the simulator.

    This goal is tried to achieve by keeping user interfaces as simple as possible, or at least by allowing the user to use a simple interface if he or she wishes so.

  4. That the performance of the system is on a level that the system is practical to use.

    Achieving this goal can be observed, before the project ends, by measuring the performance of the prototypes created during the project. It is assumed that the final performance of the system does not differ drastically from that of the prototypes due to spiral-like development process. Thus whether or not this goal will be reached can be observed from the prototypes. The problem is that some parts of the system are prototyped only at the later stages of the project. This problem must be solved by using conservative estimates of the complexity of the subparts of the system that are not yet implemented when the prototype performance is measured.

    To elaborate, it is planned that first the operating system kernel is implemented and then a simple user environment and example programs are created on the top of the kernel. Thus the subparts that do not exist at first are those that are programmed on the top of the kernel and use the SCHEMESTATION virtual machine. If the complexity of these high-level subparts can be approximated then the resources they consume can be calculated by projecting the approximations onto the known behaviour of the virtual machine and the other parts of the kernel system.

    This goal is tried to achieve by (1) using algorithms with low asymptotic complexity whenever feasible, (2) optimizing the most time-critical parts of the implementation to an extent and (3) documenting how the practical performance of system is affected by the underlying hardware configuration.

  5. That the system design is well documented.

    This goal is achieved if there exist understandable documents that (1) describe the system so that it is possible to use it without knowing the details of the implementation and (2) describe the implementation so that it is possible to understand parts of it without knowing the details of the other parts.

    This goal is tried to achieve by intertwining the technical documentation process with other development.

  6. That the system is portable to major UNIX systems.

    This goal is assumed to be relatively easily achieved. It is tried to achieve by (1) creating the system so that system dependencies can be easily handled, and then (2) finding out the portability problems via testing and then fixing them before the final product is released.

  7. That the system has some value as an educational tool.

    This goal is a consequence of all the previous goals, plus that its licencing policy allows it to be used for educational use. This is tried to ensure by giving all the rights to the product not only to the project members but also to Helsinki University of Technology, which is a body providing education.

  8. That during the project most people have fun for most of the time.

    Achieving this goal can be observed during the project by measuring the overall happiness of the project members. It is tried to achieve by (1) not imposing unrealistic requirements on the project members and (2) everybody trying to do his best, and a bit but not too much more.