Smalltalk and OOP in Real-Time Systems
Real-time computing represents one of the most difficult computing tasks that has been successfully solved by object-oriented programming. It also serves as an example of the way in which another powerful and previously unmentioned force - the militar y - contributes to the development of programming and the creation of new programming techniques.
One of the main reasons that computers have become much more powerful and more readily available is, indirectly, the military. For a very long time most computer-research projects were funded solely by the military. Of course, it was an investment; sin ce most of the past breakthroughs in computing have been designed for, and used by, them. Originally needed by the military, most of these new developments later found applications in the civilian world. This system is well illustrated by real-time system s software.
Historically, the need for real-time systems was made imperative by the Cold War. Since the US (as well as many other countries) felt threatened by nuclear war, radar systems were set up to monitor all threatening airborne activity. Since nuclear warhe ads could be delivered faster and faster, thanks to technology such as B 52's, then submarines, then inter-continental ballistic missiles, surveillance systems needed to become increasingly responsive. Systems such as this are characterized by the interaction between computers and the physical world. Usually, these types of system are called real-time systems, because they need to take input(s), process data, and return out output(s) within narrowly defined time constraints(Object-Oriented Technology for Real-time Systems, p.2).
Interaction also implies speed, because the microprocessor must be able to keep up with the physical world in order to be functional. Hence, "embedded software is normally real-time software, because it has to react to many events in the specified tim e limits"(Object-Oriented Technology for Real-time Systems, p.2).
The increasing popularity of object-oriented programming played a key role in the development of real-time software. When Kay and Goldberg introduced Smalltalk in the late seventies and early eighties, (See: History of Smalltalk), "OOP was seen as an implementation technique, and it was developed alongside programming langua ges." (Object-Oriented Technology for Real-time Systems, p.3). But the first important step toward software design was made when Sally Shlaer and Stephen Mallor came up with an Object-Oriented Analysis method in 1985. (Object-Oriented Technology for Real- time Systems, p.3). From there came the Object Modeling Technique, known as OMT, and the OCTOPUS method, which has been one of the most successful "attempts to introduce object-oriented methods for real-time systems" (Object-Oriented Technology for Real-t ime Systems, p.4).
Without getting too technical, one of the most difficult problems that programmers of real-time software have had to face is that of concurrency, and how to fuse the concepts of concurrency and objects. If an operating system receives two distinct inputs, and has fixed priorities, then the OS must be able to break up the pro cessing of each input in order to obtain an output within time limits. But the division of t he processes is difficult when using OOP. When an input is given to the real-time system, a certain number of objects receive it. Then, other objects are called upon to process the data, and finally, other objects give the output. The problem with this system is that it creates three levels of concurrency: low (object-interaction), medium (interobject), and high (intra-object). Low level concurrency is the most common and simplest: "it means that when an object completes the processing of a request, an y other object with a request pending may gain access to the processor next, regardless of where the req uest of that object originated" (Object-Oriented Technology for Real-time Systems, p.11).
At first, real-time systems software designed with OOP were used to handle multiple inputs coming from, for example, different radars, then process the data as fast as possible, and react accordingly. As computers grew smaller, and software more performant, real-time systems were used in the development of "smart bombs," which were used during the Gulf War. Tiny microprocessors guided missiles to land within a few f eet of their targets. Today, microprocessors have become sufficiently inexpensive, and programs sufficiently effective, that real-time systems have found many applications in the civilian world, and not just for the military. They can be found in cars, cellular ph ones and communication equipment in general, television sets... Since the microprocessor and its necessary software are "hidden" inside most of these products, their users tend to not think about them. For example, the cruise control function in a car is controlled by a microprocessor guided by real-time software. It allows the driver to set a specific speed, and makes sure that that speed is maintained, whether the car is going uphill or downhill. This system is a great example of how a real-time system gathers information from different inputs (the axle, the brake, the transmission), processes it as quickly as possible, and sends commands to other locations (the dashboard, the brake, the throttle).