Project COSA

Latest News

Temporal Intelligence

The Silver Bullet

Project COSA

The COSA System

Software Composition

COSA Examples

Development Plan

The Problem
The Cause
The Solution
What Is COSA?
Basic Principles
  Simplicity
  Complementarity
  Change-Driven Parallelism
  Timing
  The Essence of Software
  Visual Software Construction
  Programming by Design
Pros and Cons
  Disadvantages
  Advantages
Synchronous Reactive Systems
The COSA System

Abstract: COSA is a reactive, signal-based software construction and execution environment. The goal of Project COSA is to improve software reliability and productivity by at least one order of magnitude. COSA is based on the premise that one of the primary causes of the software reliability crisis is the age-old practice of basing software construction on the algorithm (see The Silver Bullet page for more on this subject). Software creation consists of connecting elementary concurrent objects (cells) together using a graphical software composition environment. Cells can be combined into high-level, plug-compatible components and/or applications. There is no cryptic programming language to learn, no procedures, no subroutines and no compile/run cycles. See the COSA System page for a detailed description of the COSA development and execution environment.

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. 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. 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. The problem is particularly severe in vital segments of the economy such as the health and financial services, 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 main reason for the crisis is the lack of a sound software construction and execution methodology with which to manage the high complexity of modern applications. There exist currently 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 themselves. 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.

There are those who blame bad engineering practices for the problem. They are not seeing the whole picture. Software engineering is bad mainly because the development tools are bad. The tools are bad because there is something fundamentally wrong with the way we think about and construct our software, something that no amount of stop-gap measures can ever cure. The problem has to do with the ancient practice of using the algorithm as the basis of software construction. Why ancient? Because it is a custom as old as Lady Ada Lovelace and Charles Babbage of analytical engine fame. 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.

Understanding the nature of the problem and its cause is half the solution. The other half is to eliminate the cause. We must abandon the old ways and embrace a new paradigm worthy of the twenty first century. In the real world, objects behave concurrently, synchronously and causally. Why should our software objects be any different?

The list above shows characteristics of both models for comparison. The solution will require a strong commitment to deterministic causal principles. These can only be adhered to by adopting a software model based on reactive concurrency and synchronicity. This is the basis of the COSA Project.

COSA stands for Complementary Objects for Software Applications. It is a reactive, signal-based software construction and execution environment designed to address two of the most serious problems in the computer industry: unreliability and low productivity. The goal of project COSA is to improve reliability and productivity by at least one order of magnitude. Unlike other software reliability projects that try to distance themselves as much as possible from the term "silver bullet", the claim for this project is explicit: COSA is intended to be the silver bullet that will slay the werewolf of unreliability and low productivity once and for all. This does not mean that COSA will guarantee that applications are defect free. The definition of the term 'silver bullet', as used in these pages, comes from Dr. Frederick Brooks' famous paper titled "No Silver Bullet --Essence and Accidents of Software Engineering":

But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.

'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 elementary interacting and behaving objects or things. An object in COSA is a simple virtual software entity that resides in computer memory and waits for a signal to do something.

The inspiration for COSA came from my thesis regarding the main cause of the software reliability and productivity crisis. COSA is also heavily inspired by an ongoing project to emulate biological intelligence using a spiking neural network. There is much that can be learned from neurobiological systems especially their reliance on the precise relative timing or ordering of neural spikes. One of the ideas behind COSA is that software should not be radically different than hardware. Software should be an extension to hardware. It should emulate the functionality of hardware and add only what it is lacking: flexibility, random data access and ease of modification. The strength of hardware is the clear distinction it makes between cause and effect, i.e., between events and reactions. In the future, when we develop technologies for non-von Neumann machines that can sprout new physical signal pathways and new auto-executing objects on the fly, the distinction between software and hardware will pretty much disappear. In the meantime, we must do the best we can with what we have. COSA is guided by the following principles:

First and foremost, every object or concept has a complement or opposite. Examples of complementary objects include such obvious pairs as sensor/effector, cause/effect, start/stop, input/output, male/female, etc... Complementarity further divides objects into active (e.g., perceptors, effectors) and passive (e.g., properties, data variables) categories. Complementarity is, by far, the most important of all the principles. Its power is its simplicity.

Every object or concept is stripped of unnecessary complexity.

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. Objects communicate via signals and all operations are signal-driven. No algorithmic coding (functions, procedure calls, etc...) is allowed. A signal-driven system is a change-driven system. No action or operation can take place unless something has changed. This can be anything from a key press to a change in a data variable.

The relative timing or ordering of every action is guaranteed to always be consistent. Nothing is 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. Temporal determinacy is crucial to long-term reliability and stability. This is due to the synchronous nature of COSA objects.

The object-oriented philosophy of looking at a software object as an encapsulation of methods and data properties is somewhat flawed. The right metaphor should draw a distinction between behaving entities (active process objects) and the environment (passive data objects). The essence of software is this: a computer program is a behaving entity that detects changes in its environment and acts on it. A program should be thought of as a collection of perceptors and effectors on the one hand, and the environment on the other. Nothing more and nothing less.

COSA supports the notion that software should be composed from a few simple, visually-depicted parts as opposed to being written in a syntactic language. Software designers 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 visually connecting simple objects to form components. Pre-built, plug-compatible components can be effortlessly selected from a repository and joined together to form larger applications. Automating a large part of programming is guaranteed to eliminate many opportunities to fail.

Software development normally goes through several phases such as requirement analysis, design, programming and testing. Project COSA proposes to combine the design and programming phases into one, and possibly, even the requirement and testing phases. 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 and the programming part is automatic. In addition, a COSA application under development is always "running." New additions or modifications can be tested instantly without needing to re-launch the application.

The main disadvantage of COSA may be slightly slower performance than pure assembly or compiled code. This is because the operations are interpreted. But this is not such a big problem nowadays, as the speed of processors continues to obey Moore's law. Besides, when the COSA model becomes widely adopted by the computer software industry (hopefully the reliability crisis will make sure of that), chip manufacturers will have to follow suit by designing their CPUs to embrace the new paradigm. In other words, future CPUs will be object processors as opposed to instruction processors.

Certainly, 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. It is inadequate for a full-blown operating system which will have to run multiple synchronous applications at the same time. This is a problem especially if applications are launched at odd times and need to make direct synchronous connections to one another. It is practically impossible to guarantee synchronicity between concurrent threads or traditional tasks running concurrently. Only a single optimized kernel that runs everything will do.

Note that the COSA execution kernel described in the next page will be no slower than other code interpreters. FORTH is a good example. 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.

Another disadvantage of COSA is unfamiliarity. COSA is a radically different environment than what most people 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. Many feel that visual programming systems are not powerful enough to suit their needs. The other side of the coin is that is that non-programmers will have no problem learning COSA. A COSA-based software development system is an intuitive environment: signals are uni-directional and the difference between such things as cause and effect, perceptor and effector, or male and female connectors, is clearly delineated.

The primary advantage of COSA will be at least an order-of-magnitude improvement in software productivity, reliability and simplicity. COSA is an ideal environment for the simulation of physical phenomena that require huge numbers of entities behaving simultaneously. Application areas that come to mind are simulations, video games, sound and music processing, virtual reality, neural networks, etc... But safety-critical areas--air traffic control, avionics, power generation, space transportation, real-time embedded software, medical equipment, discrete signal processing--are where COSA will really shine.

Since a COSA system consists exclusively of communicating cells, it is ideal for parallel/distributed computing and clustering. If any application needs higher real-time performance than can be obtained with a single CPU, the required processing power can be obtained simply by adding new CPUs to the cluster and redistributing some of the components so as to lighten overall CPU load. This can be done automatically with the help of clustering and load balancing tools.

The software designer is not forced to use special language constructs to access or create parallel (concurrent) objects because the parallelism of COSA objects is implicit. Furthermore, the mechanism that maintains and manages object concurrency is completely transparent to the user.

I already mentioned in the Silver Bullet page that a concurrent system is much less susceptible to catastrophic failure than a sequential program. This is because malfunctions can be localized to a few objects without affecting the rest of the system. As a result, the system will not terminate abruptly in case of failure. It will degrade gracefully. Fault tolerance alone, is sufficient reason to adopt the COSA software model for mission-critical applications. Note that distributed concurrent objects (the COSA model) should not be confused with redundant objects. A redundant organization is needed mainly in situations where a system's operation must not be affected in any way by partial physical failures. 

One of the best aids to productivity is program comprehensibility. Managing complexity is one COSA's strengths. COSA adds clarity to software development in several ways:

Finally, a concurrent synchronous system lends itself well to formal logic verification techniques of the sort already being used for logic circuit validation in the chip manufacturing industry.

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 is a call for help. Project COSA is currently a one-man project. However, given the scope of the project, this cannot continue forever. If you can contribute resources, ideas, suggestions, time or money to COSA, please contact me. You will not regret it. Project COSA will save lives. So all of you philanthropists out there should dig deep into your heart (and pockets) and support this project. And do spread the word.