Rebel Science News
11/28/2012
Jeff Hawkins Is Close to Something Big
 
8/26/2012
The Myth of the Bayesian Brain
 
8/23/2012
The Second Great AI Red Herring Chase
 
8/15/2012
Rebel Speech Recognition Theory
 
8/8/2012
Rebel Speech Update
 

Project COSA

To Drastically Improve Software Reliability and Productivity

 

 

 
Rebel Science Home
Why Software Is Bad
Project COSA
Operating System
Software Composition
Parallel QuickSort
The Devil's Advocate
COSA Discussion Forum
Not Associated with V.S. Merlot, Inc.
Contact Me

 

Abstract
The Problem
The Cause
The Solution
What Is COSA?
Basic Principles
  Complementarity
  Change-Driven
  Temporal Consistency
  Passive and Active Objects
  Cells and Components
  Extreme Simplicity
  Causality
  Visual Software Construction
  Total Vision
  Programming by Design
The COSA Reliability Principle
Disadvantages
  Slower Performance
  Unfamiliarity
  Legacy Systems
Advantages
  High Dependability
  Parallel and Distributed Systems
  High Productivity
Synchronous Reactive Systems
   

Abstract: COSA is a reactive, signal-based software construction and execution environment. A COSA program is inherently concurrent and ideally suited for fine-grained parallel processing. The two main goals of Project COSA is to enable the creation of bug-free software applications and to improve software productivity by several orders of magnitude. COSA is based on the premise that unreliability is not an essential characteristic of complex software systems. The primary reason that computer programs are unreliable is the age-old practice of using the algorithm as the basis of software construction. Switch to a synchronous, signal-based model and the problem will disappear (see The Silver Bullet page for more information on this topic).

Join the Project COSA Discussion Forum.

The Problem

The software industry is in trouble. Several decades of process improvements and innovations in testing procedures have failed to tame the twin beasts of unreliability and low productivity. The widely perceived severity of the problem is justified by a legitimate concern over human safety and the risk of economic loss, security breaches, liability lawsuits and other misfortunes. As the world becomes more and more dependent on computers and as the complexity of software systems continues to rise, the crisis can only get worse. It is particularly severe in vital segments of the economy such as the health and financial services, and the transportation, manufacturing, communication, power generation, and defense industries. The expensive custom systems used by these sectors account for more than 85 percent of the software market. Their failure rate, i.e., the percentage of projects that are started but are never deployed, is reported to be over 50 percent, a staggering figure considering the high cost of software development.

The Cause

The main reason for the crisis is the lack of a sound software construction methodology with which to manage the high complexity of modern applications. There are those who blame engineering incompetence and lack of discipline for the problem. They are not seeing the whole picture. The truth is that software engineering is bad mainly because the development tools and operating systems are bad. The tools are bad because there is something wrong with the way we construct and run our software, something that no amount of quality assurance measures can ever cure. Software is unreliable because of the practice of using the algorithm as the basis of software construction. This is not to say that there is anything wrong with the algorithm. It just should not be the basis of software. See the Silver Bullet page for more on this.

The Solution

We must abandon the algorithmic model and embrace a new paradigm. Objects in the real world behave synchronously and causally. Why should software objects be any different?

Algorithmic Model  

COSA Model

Implicitly Sequential Explicitly Sequential
Explicitly Parallel Implicitly Parallel
Procedural Reactive (signal-based)
Latency Immediacy
Function calling Message passing
Asynchronous processes Synchronous processes
Monolithic Compositional
Chaotic Systematic
Textual Graphical
Hard to predict Causally ordered/deterministic
Hand-coded Automated

The list above shows characteristics of both models for comparison. The solution will require a strong commitment to deterministic causal principles. It can only be done by adopting a software model based on reactive concurrency. However, the required discipline and the commitment to these principles should not be the responsibility of the application developer but that of the operating system and tool vendor. Unless we can create tools and systems that automatically enforce the new model painlessly and transparently, the world will continue to pay a heavy price for unreliable software.

Note: Synchronous processing is not the same as synchronous messaging. Synchronous processing means that all elementary operations in a system have equal durations and are synchronized to a master clock. Deterministic timing is a must for reliability. The COSA model supports asynchronous messaging and signaling. It also supports fine-grain parallelism.

What Is COSA?

Currently there exist hundreds of programming languages, operating systems and development tools competing against one another, not counting custom proprietary technologies. A veritable tower of Babel. Worse, the complexity of many of the tools is often greater than that of the applications. Becoming proficient in their use often requires years of training and experience. This is a sign of the chronic immaturity of the software industry. Software engineering will not come of age until a single software construction and execution model is universally adopted. Even computer processors must eventually be redesigned to support the new software model. This is part of the motivation behind Project COSA.

COSA stands for Complementary Objects for Software Applications. It is a reactive, signal-based software construction and execution environment. The word 'Cosa' means 'thing' in several languages. It is a fitting label for a software model in which the computer is viewed, not as a machine for the execution of instruction sequences, but as a collection of synchronously interacting objects or things. An object in COSA is a simple virtual software entity that resides in computer memory, waits for a signal to perform an elementary operation, and then emits an output signal. Software creation consists of connecting elementary objects (cells) together using a graphical software composition environment. Cells can be combined into high-level, plug-compatible components and/or applications. There are no procedures, no subroutines and no compile/run cycles. Best of all, there is no programming language to learn.

Basic Principles

One of the ideas behind COSA is that software should not be radically different than hardware. Software should be an extension of hardware. It should emulate the functionality of hardware and add only what is lacking: flexibility, random data access and ease of modification. COSA is guided by the following principles:

Complementarity

First and foremost, every object or concept in COSA has a complement or opposite. Examples of complementary pairs are: sensor/effector, cause/effect, departure/arrival, start/stop, input/output, male/female, source/destination, mouse-up/mouse-down, component/constituent, etc... Complementarity is the single most powerful organizing principle in existence. Any system, regardless of complexity, can be effectively and efficiently managed by applying this principle at every level of abstraction. This can be argued on the basis of natural evidence ranging from the elementary particles and antiparticles of physics to the complementary base pairs of DNA.

Change-Driven

All COSA objects are concurrent and synchronous. That is to say, they are always active, in the sense that a neuron is always active and ready to fire upon receiving a signal. A signal-driven system is a change-driven system. This means that no action or operation can take place unless something has changed. A change (aka event) can be anything from a key press to a change in a data variable. The primary advantage of this approach is that causes and effects are clearly identified.

Temporal Consistency

Strict temporal determinacy is crucial to long-term reliability. The relative temporal order of every action must be guaranteed to always be consistent. Nothing must be allowed to happen before or after its time. COSA guarantees that a software component will have a deterministic temporal behavior during its entire life cycle regardless of the environment in which it is used. This is a natural consequence of the synchronous nature of COSA objects.

Passive and Active Objects

The old object-oriented philosophy of looking at every software object as an encapsulation of methods and data is flawed, in my opinion. Every operation (method) should be viewed as an object in its own right: it waits for a signal to perform an action and emits an output signal immediately afterwards. The principle of complementarity forces us to classify software objects into active (e.g., sensors and effectors) and passive (properties, data variables) categories. Even data should be classified into complementary types (e.g., positive and negative numbers, true and false values, etc..). The right metaphor draws a clear distinction between behaving entities (active objects) and their environment or domain (passive objects).

Cells and Components

In COSA, an active object is called a cell and a cell can be either a sensor or an effector. A passive object is just a data operand, i.e., a variable property or a constant. A group of passive objects is called a domain or territory. A component is analogous to a country. It encapsulates the active objects and their territory. Passive objects can be shared among several active objects belonging to the same territory but are never shared across territories, except when passing messages. This is described in detail in the Software Composition page

Extreme Simplicity

If it is not simple, it is wrong. Simplicity is a natural consequence of applying the principle of complementarity. Every object or concept in COSA is stripped of unnecessary complexity. No algorithmic construct (e.g., IF/THEN/ELSE, WHILE, GOSUB, GOTO, DO WHILE, DO UNTIL, etc…) is allowed.

COSA Program

Active Objects

Passive Objects

Sensors Effectors

Data Operands

As seen above, a COSA program or component is just a collection of active objects (sensors and effectors) on the one hand, and the environment (data or passive objects) on the other. Nothing more and nothing less. As will be seen later in the discussion of the COSA operating system, these objects are represented graphically with a minimum number of icons. An active object's type (sensor or effector) is immediately recognizable. This, in effect, does away with a major part of the "essential complexity" of software that Dr. Brooks alluded to in his "No Silver Bullet" paper.

Causality

One of the strengths of hardware logic is the clear distinction it makes between cause and effect, i.e., between events and reactions. The same distinction must exist in software. The essence of software is this: a computer program is a reactive entity that detects changes in its environment and acts on it. This makes it easy for the developer to determine which actions are taken and why. The upshot is high program comprehensibility.

Total Vision

Unresolved dependencies are the leading cause of software failures in complex systems: A critical property or variable is changed by one part of a program, unbeknownst to the other parts. Blind code is the bane of programmers and managers who are given the task of maintaining complex legacy algorithmic systems. Even a minor modification is likely to introduce one or more unforeseen side effects. By contrast, a COSA system has what I call 'total vision.' It is a mechanism based on complementarity that automatically resolves all data dependencies, leaving nothing to chance. The identification and resolution of dependencies must be effected both at the cell level (in-memory data) and at the component level (mass storage data). Total vision makes it possible to eliminate unwanted side effects and opens the way to the creation of extremely complex yet robust systems.

Visual Software Construction

COSA supports the notion that software should be composed from a few simple, visually-depicted objects as opposed to being written in a syntactic language. Developers should concentrate on application design and requirements and should not have to worry about syntax and spelling. They certainly should not have to learn to decipher keywords based on a language (usually English) that may not be their native language. Software construction should consist almost entirely of using a small number of simple graphical icons to connect objects together to form higher level components. Pre-built, plug-compatible components can be effortlessly selected from a repository and joined together to form larger applications. Just click, drag and drop. Automating a large part of programming is guaranteed to do wonders for both productivity and reliability.

Programming by Design

Software development traditionally goes through several phases such as requirement analysis, design, programming (including compiling) and testing. Project COSA proposes to combine all phases into one. Good software design under COSA means bug-free code that fulfills requirements from the start. When the design is finished , i.e., when all requirements are met, the application is ready for deployment. There is no distinction between the application development tool and the application design tool. In addition, a COSA application under development is always "running." Most additions and modifications can be tested instantly without the need to recompile and re-launch the application.

The COSA Reliability Principle

The promise of the COSA software model is as simple as it is revolutionary. A COSA program is guaranteed to be completely free of internal defects regardless of its complexity. I call it the COSA Reliability Principle or CRP. The principle is based primarily on the knowledge that a COSA program works essentially like a logic circuit. More details on the CRP can be found in the COSA operating system page.

Disadvantages

Slower Performance

The main disadvantage of COSA will be slightly slower performance than pure assembly or compiled code. This is because the objects are interpreted. But this is not such a big problem nowadays, as the performance of processors continues to obey Moore's law. For now, the COSA model must use an interpreter but only because current CPUs are optimized for conventional algorithmic software. Eventually, when the COSA model becomes widely adopted by the computer software industry (hopefully the software reliability crisis will make sure of that), chip manufacturers will have to follow suit by designing their CPUs to embrace the new paradigm. As an added bonus, only the COSA model makes it possible to design a fine-grain multicore CPU in an MIMD execution environment. See How to Design a Fine-Grain, Self-Balancing, Multicore CPU.

It is possible to create a COSA compiler that generates fast optimized compiled code to be run as a standalone embedded program or as an application to be run in an existing OS. Performance would be at least on a par with if not better than hand-written code. This is fine for embedded systems and as a bridge solution for legacy systems but it is inadequate for a full-blown operating system which will have to run multiple synchronous applications concurrently.

Note that the COSA execution kernel described in the next page will be no slower than other code interpreters. FORTH is a case in point. FORTH interpreters have certainly proven their performance adequacy for all sorts of real time applications, especially in embedded and robotic systems. Dedicated FORTH processors also exist that can execute FORTH code directly, resulting in unparalleled increases in performance. My hope is that the same thing will happen with COSA.

Unfamiliarity

Another disadvantage of COSA is unfamiliarity. COSA is a radically different environment than what most people (with the exception of hardware designers) are used to. Most programmers are trained to use traditional programming languages and may have a hard time switching to a development system that discards all the familiar algorithmic constructs. There is also the problem of programmer prejudice. Many wrongly feel that visual development systems can never be powerful enough to suit their needs. The other side of the coin is that non-programmers will have no problem learning COSA.

Legacy Systems

The ideal environment is one in which everything, from the operating system components to the applications, works according to COSA principles. Unfortunately, the world has already invested trillions of dollars and countless man-hours in legacy systems. There is a huge algorithmic infrastructure already in place, one which will not go away overnight. Regardless of how great the advantages of the new paradigm are, it will take much time and effort to displace the old systems. Fortunately, standalone COSA applications can easily be made to work within an existing OS. These applications can migrate to pure COSA environments at a later date, when these become common place.

Advantages

High Dependability

The primary advantage of COSA is the COSA Reliability Principle. Every COSA program is guaranteed to be 100% free of internal defects. Application areas that come to mind are simulations, video games, virtual reality, neural networks, etc... But safety and mission-critical applications are where COSA will really shine. Examples are: air traffic control, avionics, transportation automation, collision avoidance systems, power generation, high-traffic communication systems, real-time embedded software, discrete signal processing, medical and financial systems, multi-sensor network management software, instrumentation, robotics, factory automation, etc...

Parallel and Distributed Systems

Since a COSA system consists exclusively of synchronous (parallel-activated) objects, it is ideally suited for parallel/distributed computing and clustering. COSA is an ideal environment for the simulation of physical phenomena that require huge numbers of synchronous entities. If an application needs higher real-time performance than can be obtained with a single CPU, processing power can be increased simply by adding new CPUs to form a cluster and redistributing some of the components so as to lighten the overall CPU load. This can be done automatically with the help of clustering and load balancing tools. In COSA, the parallelism of objects is implicit. Thus the software designer is not forced to use special language constructs to access or create parallel (concurrent) objects. Furthermore, the mechanism that maintains and manages object concurrency is completely transparent to the user/designer.

High Productivity

As everyone knows, the average programmer's time is spent mostly in debugging. Software that is bug-free from the start is COSA's main forte. This goes a long way toward improving productivity. First off, COSA eliminates all problems resulting from incompatible software components via the use of plug-compatible connectors. Second, the COSA software construction environment automatically resolves all data dependencies automatically. See the discussion on blind code on the Silver Bullet page for more on this topic.

There is more to rapid application development than the creation of reliable programs. One of the best aids to productivity is program comprehensibility. The complexity of an application must not get in the way of comprehension. Managing complexity is one COSA's strengths. COSA adds clarity to software development in several ways:

Complementarity
  COSA uses a simple but powerful organizing principle which stipulates that every object or concept must have a complement.
Extreme Simplicity
  This is a direct result of the rigorous enforcement of the principle of complementarity.
Extreme Information Hiding
  Components are treated as black boxes with well-defined interfaces and behaviors. Implementation details (data operands, arithmetic operations) are kept separate and hidden from organizational and behavioral structure such as cell connectivity and activation logic.
Active and Passive
  There is a clear demarcation between active objects (cells) and passive objects (data). This is analogous to organisms and the environment.
Sensors and Effectors
  Active objects are divided into two complementary subcategories: sensors and effectors. What an object does and when and why it does it is easy to understand.
Sensor/Effector Associations
  Data comparison sensors are instantly and automatically associated with pertinent effectors upon creation. This way, a developer can immediately identify every effector object that can potentially affect a comparison. This is a must for program comprehension.
Simple Graphical Interface
  Objects and components are displayed graphically through the use of a minimum number of simple graphical icons.
One-way Signal Pathways
  Activation order (cause and effect) is always clear and explicit.
Male and Female Connectors
  No confusion or mix-ups.
Plug-compatible Components
  Automated and flawless software composition.
Visual Software Composition
  Click, drag and drop. Instant depiction of control pathways. No syntax or spelling errors to worry about.

Last but not least, there are no compile cycles in a COSA development environment. As mentioned earlier, a COSA program is always running even while under development. This may not be such a big thing when developing small applications but very large and complex programs may sometimes take hours and even days to compile. Although new tools can distribute the make process among many machines running simultaneously, even an order of magnitude improvement can still mean a 1-hour compile or more in some situations. Eliminating compile cycles improves productivity not only because it saves computer time, but also because it enables an interactive environment free of distractions and interruptions.

Synchronous Reactive Systems

COSA belongs to a class of software systems called synchronous reactive systems. Here is a quote from an article by Axel Poigné of the German National Research Center in Information Technology (GMD):

"Synchronous programming reinterprets the basic idea of hardware design, and of discrete engineering formalisms, namely that processes run on a clock; a system reacts to each stimulus of the environment instantaneously meaning that the reaction consumes no (observable) time, or in hardware terms: every reaction terminates before the next 'clock tick'. Software design is less accustomed to this idea which, however, should be the basis of systems with hard real time constraints. For these a reaction must be guaranteed to take place within a specified reaction time."

This means that all reactions to simultaneous events must occur before the next clock tick. In COSA, the clock is virtual and a clock tick represents an execution cycle. There are a few important differences between COSA and other reactive systems, as seen below:

Universal Model
  There is a general consensus in the reactive programming community that so-called classical computations (such as reading and writing to memory, looping and performing arithmetic and comparison operations on data) are to be handled separately from input and output processing. In a reactive language such as Esterel, the environment is defined as being external to the computer. By contrast, in COSA, all sensory events, whether external (I/O interrupts) or internal (changes in data), are treated equally. In other words, there is no process distinction between internal and external sensory phenomena in a COSA program. The same principle is applied to output processing: there is no process distinction between writing a byte to an output register and performing an arithmetic operation on a data variable. Both operations are classified as effects. The COSA model views the environment simply as a collection of data variables. Whether or not these variables are linked to conditions external to the computer is irrelevant.

This realization has far-reaching implications: it brings the reliability and verifiability benefits of the reactive model to all areas of computation, not just to input and output processing. For example, comparisons in COSA are not seen as operations to be contained in an algorithmic procedure but rather, as sensory (input) processes. Likewise, arithmetic operations are viewed as effects, i.e., a type of output or motor processing. This way, classical (i.e., algorithmic) procedures are transformed and organized into a concurrent, reactive network of interconnected sensors and effectors. This approach has three principal benefits. a) It insures that all steps in any given computation are executed in a deterministic order (concurrent or sequential), a must for verifiability and reliability; c) It provides a simple and effective mechanism to identify and resolve data dependencies; and b) It classifies objects in a simple way that enhances comprehensibility. For more information on this new reactive model, please see the description of the COSA system.

Not Just for Mission-Critical Applications
  Most researchers in the reactive programming community (one notable exception that I am aware of, is this music-minded team at Berkeley) seem to be targeting real-time, mission-critical and/or embedded software applications exclusively. The COSA philosophy is that all software development should be based on reactive principles. In order to solve the software crisis, it is imperative that the entire software development industry switches to the synchronous reactive model. The reason is simple. The use of any software model that improves reliability and productivity, benefits all areas of software engineering, not just mission-critical systems.
Visual Composition
  The reactive community seems to have embraced textual development tools as their favorite approach to software construction. Several reactive programming languages already exist: Esterel, LUSTRE, SIGNAL, etc... Even VHDL can be said to fall in the category of reactive programming languages, although it is meant to be a description language for hardware design. The idea seems to be that a conventional algorithmic language is necessary to describe classical computations. This is an unfortunate legacy of algorithmic computing. In order to inherit the full promise of the reactive model, all computations, including so-called classical computations, can and should be reactive in nature.

The COSA philosophy is that the use of visual composition tools is the most intuitive, efficient and safe way to describe and construct reactive programs. An application designer should concentrate on the design at hand and should not have to learn or worry about such things as syntax and spelling. In addition to facilitating program comprehension, a visual environment automatically enforces all necessary constraints in a way that is beyond the capability of text-based development tools.

These and other COSA original ideas will not only go a long way toward solving the software reliability and productivity crisis, but should make synchronous reactive programming much more appealing to the software engineering community at large, as a universal approach to software construction. For more information on reactive systems and languages, click on the links below:

The Esterel Language
Tick, Synchronous Reactive Systems
Syrf Project
Synchronous Programming in Reactive Systems

I found The Foundations of Esterel [pdf] to be a good general introduction to reactive systems.

 

Not Associated with V.S. Merlot Inc.

Please note that COSA, as described in these pages is not related to and has nothing to do with the COSA system or method developed and patented by Gordon Morrison of V.S. Merlot, Inc. Mr. Morrison independently developed and patented his concept years before I published my own ideas on the internet. Likewise, I developed my ideas on COSA without any knowledge of Mr. Morrison's work.

 

Next: The COSA System

©2004-2006 Louis Savain

Copy and distribute freely