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 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 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.

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.

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.

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 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.

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.