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