The Roots of Object Orientation

The roots of Object-oriented programming and software (OOPS) are usually traced back to SIMULA (SIMUlation Language) programming language, which was designed and built by Ole-Johan Dahl and Kristen Nygaard at the Norwegian Computing Centre (NCC) in Oslo between 1962 and 1967. Nygaard had set out to create a programming language for discrete event simulation that could be applied to real-world systems such as ticket counter systems, production lines, production in development programs, neuron systems, and concurrent processing of programs on computers.

The early approach to SIMULA was based on the notion of a network concept consisting of active “stations” serving a flow of passive “customers.” Stations consisted of a queue part and a service part, and the actions associated with the service part were described by a sequence of formalized statements. The customers possessed no similar operating rules, but were instead described through a sequence of variables called characteristics. A customer was supposed to be generated by the service part of a given station, then transferred to the queue part of another station, and subsequently to the service part of that station. Here the customer was 'served', and then passed on to the next station in the network, and so on until it ultimately disappeared by not being transferred any further. [i]

Although SIMULA never became widely used, the language has been highly influential on modern programming methodology. Among other things SIMULA introduced important object-oriented programming concepts like classes and objects, inheritance, and dynamic binding. Smalltalk was the next major contributor including classes, inheritance, a high-powered graphical environment and a powerful dynamic typing mechanism (which existed to some extent in Simula).

However, it is the early applications of object-oriented languages that sheds light on our subject rather than the development of the object-oriented languages themselves. Humans, even programmers, are greatly influenced by their environment.  Simulation systems developed for the Department of Defense and NASA required a graphic environment. Computer graphics, for the most part, are built using relatively simple geometric building blocks. In any drawing package found on today's market, the “tool box” emphasizes basic geometric elements such as circles, squares, and polygons. Once a program was developed that, for instance, drew a circle, it naturally makes sense to use that same code every time a circle is drawn rather than writing code for every possible instance of “circle.” However, each time a circle is drawn the user may want to attribute different design features. Should the circle have a fill, a new size, and new position, a color?

In modern object oriented terminology the circle is a “class” of geometric shapes, as opposed to lines, squares, and so forth. In our example the circle class may have the attributes of line, fill, and diameter, which is the basic information that you need in order to draw a circle. It is easy to imaging a super-classes or parent class of “shape” that has attributes of color, width (as in line), pattern or shade (as in fill), and a reference position grid system (“anchors” in vector graphics parlance) that orients any drawing to a virtual x, y  coordinate space. An of course, the “method,” as it is called in OOM, would be that actual code that draws the circle to the screen and digital file. What would you call a circle, or square, or airplane, or soldier that has been drawn using this system? You’d probably call it an “object;” and instance of the class “circle,” or “square,” etc. In context of the original environment, OOM terms such as “object” or “method” or “attribute” are very intuitive. Perhaps that’s why I’ve never seen many of these terms attributed to a specific author. The language of OOM grew out of the environment in which early OOM programmers were working. Over time the objectives of OOM changed, as did the environment, and hence, the terminology of OOM are much harder to grasp for today’s programming student.

            Simulations, be they battlefield simulations or simulations of manufacturing process, imply action over time and depth of field or depth of view. OOM was dramatically changed in the 1970’s by the introduction of graphics in motion. Not only could our circle represent an object with given characteristics, but in a complex simulation that “circle” object may have position and motion relative to other objects, and its characteristics (attributes) could influence other objects.

For instance, in a battlefield simulation, a virtual tank should have a limited view. If a virtual hill separates one virtual tank from another, the user interacting with the tank shouldn’t be able to “see” through the virtual hill. The user could also alter the state of another object by “firing on it” and “hitting” it. That interaction should be bidirectional: one tank acquires the attribute of “killed” and the other tank should add “one” to the attribute of “kills” and lose “one” in the attribute of “Rounds of ammunition.” Over time, user, represented in the system as an “actor” could have a record of total kills, kills per battle, and so forth.

The ramification of complex simulations such as this naturally lead to OOM concepts such as dynamic binding, but two other changes were occurring in the OOM programmer’s environment. First, OOM concepts were expanding beyond simulation and graphics. CAD systems files drawn by architects needed to have precise relationships to parts lists, tolerances, and other fielded data. Furthermore, this associated engineering data often had to be accessed in external logistics systems or had to be accessible to manufacturing systems, robotics, and so forth. The age of concurrent engineering arrived in the mid-1980s, originating with the development of Chrysler’s Viper, early geographical information systems (GIS),  and the Department of Defense’s Computer Aided Logistics and Support (CALS) program. This first OOM change required that object oriented systems be open to cross-platform integration as well as to systems distributed across computers, companies, and geographical locations. Terms such as “remote procedure calls” and “portable application programming interfaces” (APIs) entered the OOM programmer’s lexicon. The most significant result was the formation of the Object Management Group (OMG), a consortium that today has over 800 technology companies in membership, and the development of the OMG’s Object Management Architecture (OMA). A central feature of the OMA is the Interface Definition Language (IDL). The IDL, now an ISO Standard, provides a neutral and open method for describing objects and their functions. The IDL can has been mapped to Java, C, Smalltalk and other programming environments. Not only can it be used to help generate and compile code, the IDL:

·        Provides an operating system and programming language independent interface.

·        Due to its higher level of abstraction, the programmer does not have to be concerned with the lower layer protocols.

·        The programmer does not have to be concerned wit the server location or activation state.

·        The programmer does not have to be concerned with the server host hardware or operating system.

·        Certain integration issues are simplified; for example, no longer does a client or server have to be concerned with byte ordering of data when transferring data between different platforms. [ii]

The IDL, which is also the role model for the distributed common object model (DCOM), the web interface definition language (WIDL), and Enterprise Java Beans, along with its sister specification, the Common Object Request Broker Architecture (CORBA) now added to the OOM environment the concept of portability, and the abstraction of object systems without inherent reference to the underlying programming language or systems.

 The second changes was a subtle reversal of the role of graphics and OOM. Graphical elements, such as “tank,” could also be considered as a symbol for a series of programming code. If the code was associated to the graphic, graphic manipulation could be indirectly used to manage the organization and modification of the code.

The most well know application of this change in philosophy occurred in the late 1970s at Xerox’s fabled Palo Alto Research Center (PARC). PARC researchers working on what would later be called a WYSIWYG (what you see, is what you get) document layout and authoring system, created a graphical user interface (GUI). Rather than entering text commands, the user could use iconic representations of slides and buttons to initiate an object, even fonts could be drawn to scale and proportion on screen. (One PARC researcher, John Warnock went on to co-found Adobe Systems.)

An important yet subtle implication of the GUI is that the graphic had been divorced from the programming code. Icons, buttons, and slides became graphics that could be re-used and associated to a variety of programs or “methods.” Graphics became “handles” that could be used to handle and move block of programming code. Object orientation was starting to be applied to itself: Computer programs are systems of code, why not simulate systems of code with object oriented methods?

In the late 1980’s and early 1970’s programmers such as Grady Booch, James Rumbaugh, Ivar Jacobson,  and others were introducing highly graphical methods of modeling object oriented software and systems. In 1994, Booch and Rumbaugh started work on a “unified method of modeling.” Later adding Jacobson to the team, they renamed the effort the “Unified Modeling Language” and added concepts from other methods other than their own. UML was released in January 1997, under the auspices of OMG. The goals of UML are:

·        To model systems (and not just software) using object-oriented concepts.

·        To established an explicit coupling to conceptual as well as executable artifacts.

·        To address the issues of scale inherent in complex, mission-critical systems.

·        To create a modeling language usable by both humans and machines. [iii]

Finally, in the last two years, the OMG has recognized that systems level generic abstractions of APIs and models, such as file access, security, and so forth are not enough. For OOM techniques to be truly successful, they must take into account the unique terms and requirements of industry groups. As a result the OMG is developing industry specific task force groups in the areas of finance, health care, manufacturing, printing and publishing, and so forth. These groups are adding the to the OMA the business-specific or process-specific definitions necessary for the OOM to be successful in inter-enterprise integration. Hence, over the years the basic philosophy of OOM has changed. Originally a simulation and graphical method, OOM has become an inter-enterprise method for designing, building, and managing systems. We’ll see that the mark-up languages have evolved along a very similar path.