Organizational foundations of object-oriented programming

Controversy Corner It is the intention of the Journal of Systems and Sofiware to publish, from time to time, articles cut from a different mold. This is one of that series.

The goal of CONTROVERSY CORNER is both to present information and to stimulate thought. Topics chosen for this coverage are not just traditional formal discussions of research work; they also contain ideas at the fringes of the field’s “conven- tional wisdom.”

This series will succeed only to the extent that it stimulates not just thought, but action. If you have a strong reaction to the article that follows, either positive or negative, write to Robert L. Glass, Edi- tor, Journal of Systems and Software, at the address on the JSS masthead. We will publish the best of the responses as CONTROVERSY REVISITED.

Organizational Foundations of Object-Oriented Programming

John Mathews Industrial Relations Research Centre, The University of New South Wales, Sydney, Australia

This article demonstrates that object-oriented programming (OOP) systems are in fact part of a larger class of technical systems, which are structured along “holonic” organizational lines. The properties of holonic organizational architecture are brought out and applied to the description of OOP systems. This brings out the fundamental organizational features of OOP systems, abstracting them from other issues to do with standardization, replication, or costs, and en- ables a clearer understanding of the sources of their efficiency with respect to traditional, functionally structured programs. Finally, the use of the holonic paradigm as a design tool is illustrated, with a view to further developing the organizational clarity and effec- tiveness of OOP systems.

INTRODUCTION

The object-oriented paradigm in software engineering, known as object-oriented programming (OOP) is now widely discussed as an alternative to hierarchically structured functional programming (Parsaye et al., 1989; Booth, 1991; Ege, 1992; Dillon and Tan,

Address correspondence to John Mathews, Industrinl Relations Research Centre, The University of New South Wales, Sydney, NSW 2052, Australia. Email: [email protected]

1993; Yourdon, 1994). This shift is driven partly by the need for an alternative to the functional division approach that was swamping programs with unman- ageable complexity, and by the economic benefits that are thought to accrue from standardization of software engineering and the development of reusable libraries of software “components.”

In this article, our concern is to develop an account of the organizational architecture of OOP. It is argued that OOP is in fact an exemplar of a wider class of organizational architectures, termed “holonic” (Mathews, 1996). These organizational systems share the property that they overcome complexity by devolving system operational responsibili- ties to a nested sequence of subsystem entities. It would therefore appear to be worthwhile to explore just what these organizational foundations are, if for no other reason than to provide a clarification for software engineers. More broadly, because of its significance, OOP could develop to become paradigmatic in its organizational foundations for a wide class of technical systems, in software and beyond.

Traditional Approaches to Software Engineering

Software engineering has traditionally been con- ceived as an approach to the processing of data

J. SYSTEMS SOFTWARE 1996; 34:247-253 0 1996 by Elsevier Science Inc. 655 Avenue of the Americas, New York, NY 10010

0164-1212/96/$15.00 SSDI 0164-1212(95K!OO79-G

248 _I. SYSTEMS SOFTWARE 1996; 34:247-253

J. Mathews

organized in terms of functions, dividing them into more and more diverse routines and subroutines. Programming techniques have been designed to cope hierarchically with the increasing complexity this approach entailed. Thus, programs have been structured along the model of “master” and “servant” routines, with a master program calling up servant routines as and when they are required. The traditional approaches have led to a clear distinction being made between functions (routines and subroutines) and the data that they operate on. This has been accomplished in the pursuit of efficiency; it was thought desirable to be able to allow data structures to be defined anywhere in a program and to allow different routines to access this data. The effect, however, has been to create enormous problems whenever such a complex program needs to be up- dated, because changes in any one routine can have unexpected effects elsewhere. Thus, program main- tenance has become a time-consuming chore of trac- ing through procedures to check how they depend on current and past definitions of data structures, leaving loose ends in newiy written programs that show up as increasingly baffling “bugs.”

These are the familiar problems of hierarchically rigid, functionally defined systems grappling with a changing and complex world. Moreover, the traditional approach to programming has made it very difficult to reuse pieces of software, given the dependence of functional routines on data structures, which are defined differently for any particular program. Thus, software engineering has been constrained to operate more or less like a cottage indus- try, in the sense that programmers have had to work individually on their own routines and have been able to share tasks only with great difficulty. As programming tasks have multiplied exponentially, this productivity constraint has emerged as a major problem demanding a radical solution.

The solution developed is OOP. This paradigm shift in software engineering, which has been discussed for over two decades but is now coming into its own in the 199Os, forces a radical break in perspective. In place of functional routines that are summoned by a master program to access or process data structured elsewhere in a program and return a result to the master program, the OOP approach instead defines problems in terms of their con- stituent objects and then creates software “objects” that match these as the core operating entities of the program. These objects contain both data and functions; they are said to be encapsulated. The OOP approach is thus characterized by the creation

of small, discrete software components that can be summoned to perform particular tasks by a coordinating program without any need to know their inner workings. This has a profound effect, for it simplifies the task of program execution, which now becomes primarily one of coordination of preexisting software objects.

Moreover, the OOP approach offers a solution to the problem of software engineering productivity, in that objects can be standardized and reused by any given software firm. Indeed, object-oriented software libraries can be created, allowing software compa- nies to draw objects (e.g., for graphical user inter- face) from the public domain. Software engineering is thus brought to resemble other engineering fields, in that practitioners are able to draw on a core of standardized objects; their work increasingly becomes the design of routines that cleverly use these objects, rather than inventing them anew in each new program.

CORE CONCEPTS OF THE OOP PARADIGM

In the OOP approach, the basic software unit is the object, which has its own identity, and which incor- porates internally its own set of procedures and data. Once the object is defined, any part of a program can access the object by sending it a message, which is an instruction requesting performance of one of the object’s defined behaviors. The message does not have to specify any data; it simply requests the object to perform a certain task with its current data. As two of the authorities on OOP put it, “The arrangement of bits in an object’s allocated memory space determines that object’s state at any given moment. Associated with every given object is a set of procedures and functions that define the meaningful operations on that object. Thus, an object encapsulates both state and behavior” (Korson and McGregory, 1990, p. 42).

It is this conjunction of data and behavior, termed encapsulation, that provides the essential condition needed for relative autonomy of different objects within a program. As Booth (1991) puts it, “No part of a complex system should depend on the internal details of any other part” (p. 45).

Further conceptual efficiency is provided in the OOP model by the capacity to define classes of objects that share certain characteristics. Given a class, it is possible to define a subclass that inherits the properties of the original class, and adds some more of its own. Thus, objects do not have to be defined ab initio every time they are created, but

Organizational Foundations of Object-Oriented Programming J. SYSTEMS SOFTWARE 249

only in terms of distinctive characteristics over and above those inherited from a superclass of similar objects.

From an organizational perspective, the significance of inheritance lies in its capacity to create scalar “chains” of holonic entities (objects), each of which inherits certain properties from its supersys- tern. In the literature on OOP, inheritance is seen as an incremental modification mechanism that allows classes to be refined and extended without editing any of the existing code: “Inheritance minimizes the amount of new code needed when adding additional features . . . and minimizes the amount of new code that must be changed when extending a system” (Korson and McGregory, 1990, p. 43).

A side effect is that changes entered in one area of the program may be propagated to other areas, without having to change the code at each mention of the code to be altered. In the field of manufacturing, this can have a profound effect. With central- ized, hierarchical manufacturing databases such as Materials Requirements Planning (MRP), any change to a product code could require scrutiny of thousands of lines of code to ensure that the change is picked up elsewhere; otherwise the codes will be incompatible and part requests will not be actioned, bringing production to a halt. Inheritance would change all that.

Multiple inheritance allows objects to embody features characteristic of quite different classes of real-world events, thus enhancing the ability of object-oriented programs to closely follow real-world phenomena, no matter how complex they might be. In multiple inheritance, a class inheriting from multiple superclasses can be seen as a specialization of all its superclasses, not just one of them at a time.

This conceptual efficiency is further enhanced by dynamic binding, which means that the actual opera- tion to be executed when a message is received by an object is determined dynamically at run time (rather than statically, for all time, by the program itself). These features allow the same messages to cause different kinds of actions to be executed when sent to different objects, thus enabling the same message to take on multiple meanings, or effects. This property of OOP systems is termed polymorphism.

Polymorphism and dynamic binding provide the conditions needed by programmers to tackle problems in their generality, creating objects that map the real world and that change as the real-world phenomena change. The program can be written at a level of generality that transcends the particular

1996; 34~247-253

conditions in which an object or class of objects may be found.

The concepts of object, encapsulation, classes, inheritance, polymorphism, and dynamic binding, and their applications in notions such as object linking and embedding (to use the terms applied by Micro- soft’ ), are the critical concepts that demarcate OOP as a radical break with traditional approaches.

HOLONIC ORGANIZATIONAL ARCHITECTURE

What is striking about the OOP innovation is that it is concerned with introducing flexibility through the decomposition of large-scale, complex systems into coordinated systems of smaller, focused, semiau- tonomous entities (objects). In many technological systems, a similarly inspired concern to break down rigidity and exponentially expanding complexity can be detected in moves to decompose systems into smaller, more manageable units that behave as min- isystems in their own right but can be coordinated as subsystems of a central intelligent supersystem. These trends can be detected in large-scale telecom- munications systems, in robotic systems, and in many other technological systems. [On holonic neural network communications systems, see Iida et al. (1989) and Chugo et al. (1990). On holonic robotic systems, see Hirose (199O)l.

A consistent organizational architecture can be discerned here, in which complex systems need to be decomposed into simpler subsystems, and in which the subsystems themselves can be treated as autonomous systems possibly containing further subsystems of their own. It was Arthur Koestler who drew attention to this common structure in what he called holonic systems. In his 1967 book, The Ghost in the Machine, he emphasized that such systems possess a flexibility and adaptability derived from the capacity of individual units to perform their own, relatively autonomous functions, whereas system integrity was maintained through an overall system intelligence coordinating the activities of the individual units.

Koestler (1967/1976) introduced his notion of a holonic organizational architecture in the following way:

The first universal characteristic of hierarchies is the relativity, and indeed ambiguity, of the terms “part” and “whole” when applied to any of the sub-assemblies . . . . A “part,” as we generally use the word, means something fragmentary and incomplete, which by itself would have no legitimate existence. On the other hand, a “whole” is considered as something

250 J. SYSTEMS SOFTWARE 1996; 34~247-253

J. Mathews

complete in itself which needs no further explanation. But “wholes” and “parts” in this absolute sense just do not exist anywhere, either in the domain of living organ- isms or of social organizations. What we find are inter- mediary structures on a series of levels in an ascending order of complexity: sub-wholes which display, according to the way you look at them, some of the characteristics commonly attributed to wholes and some of the characteristics commonly attributed to parts.. . . The members of a hierarchy, like the Roman god Janus, all have two faces looking in opposite directions: the face turned towards the subordinate levels is that of a self-contained whole; the face turned upward towards the apex, that of a dependent part.. . . This “Janus effect” is a fundamental characteristic of sub-wholes in all types of hierarchies.

But there is no satisfactory word in our vocabulary to refer to these Janus-faced entities: to talk of sub-wholes (or sub-assemblies, sub-structures, sub-skills, sub-systems) is awkward and tedious. It seems preferable to coin a new term to designate these nodes on the hierarchic tree which behave partly as wholes or wholly as parts, according to the way you look at them. The term I would propose is “holon,” from the Greek bolos = whole, with the suffix on which, as in proton or neutron, suggests a particle or part (p. 48).

Koestler’s conceptual and terminological innovation was introduced in the context of biological systems. He was an opponent of biological reductionism, and in particular of the reductionism that saw complex, interactive entities as mere input-out- put devices. The terminological innovation of “ho- ionic system” was designed to counter such tenden- cies. But the wider ramifications of this perspective have been all but ignored by organizational theorists. Its relevance to the design of software engineering systems, and to the notion of OOP, is surely apparent.

In Mathews (1996) Koestler’s notion of holonic system is broadened to become the organizational foundation for a wide class of technical systems, including OOP. The main features of holonic organizational architecture are as follows.

The basic conceptual core of holonic systems is the holon, which is deemed to be an autonomous, independent, intelligent, operating entity that is both a system in itself, possibly containing subsystems that can also be characterized as holons, and at the same time a subsystem of a broader systemic entity. Holons display triple characteristics of autonomy, system dependence, and recursivity. Provided these terms are interpreted sufficiently broadly, we can characterize as holons objects in OOP, cells in biological systems, cells in manufacturing systems, and

many other technological and biological viable systems.

Holonic systems may be considered to consists of scalar chains of holonic entities, where at each level the reference entity can be considered to subsist as part of a higher level system and to contain lower level subsystems of its own. At each level, tasks are allocated to holons according to a given design, such as parallel processing. This determines the fundamental relations between holons at any level, between holons at different levels, and between holons and the overall system.

There are three basic structural features of holonic systems, which we shall propose as being defini- tional.

1. Relative autonomy of holons. Holons possess a degree of self-sufficiency if they are to have what might be termed coherence and integrity in the performance of a set task. At a minimum, they need to have their own capacity to collect data to ensure that the set task is completed to a sufficient stan- dard; they need to be possessed of intelligence, meaning processing power and the ability to vary their response depending on circumstances; and they need to be equipped with a mechanism for continu- ous improvement, or learning. They may contain subsystems that similarly display holonic qualities.

2. System dependence. Holons are not expected to operate with absolute autonomy. Rather they are required to function within the constraints, and sub- ject to the direction, of a supersystem that provides all necessary external coordinating inputs. Systemic order (as opposed to control) is obtained through the coordinated activity of holons, each performing its own operations but within the operational context established by a supersystemic coordinating mechanism. Thus, holons are not expected to deter- mine their tasks for themselves; these are given by the overall system design. But how they accomplish their tasks is up to them (given the existence of standardized protocols, operating procedures and so on, discussed in greater detail below).

3. Holonic concatenation: recur&it-y. Holonic systems consist of holons at various levels. But system integrity calls for these holons to be structured along similar lines, so that there can be meaningful aggregation from level to level. This implies that holonic structures be self-similar, or recursive. [Since fractal geometry displays such self-similarity, it provides an attractive metaphor for this property. See

Organizational Foundations of Object-Oriented Programming

Mandelbrot (1977) for the original account, and Peitgen et al. (1992) for a recent survey. In a similar vein, holograms capture the notion of “the whole contained in the part,” and they, too, serve as a useful metaphor.] For example, data management needs to follow the same format within different holons, as do message protocols to allow holons to communicate at each level and between levels. Like- wise, performance criteria need to be formulated using similar ratios; the actual ratios will be different at each level, depending on the degree of aggregation, but their structure will be the same. Self-similarity provides the technical foundation for systemic coherence.

Functionality

We use these three properties-holonic autonomy, system dependence, and recursivity-as defining the characteristics of holonic systems. The functionality of such systems can then be described using a triad of relations. There is the functionality of the holons themselves (which we call first-order functionality); there is the functionality of the set of holons at any one level, whose combined operations complete a total process (which we call second-order functionality); and there is the functionality of the total system (which we call third-order functionality).

Organizations or systems that have a hplonic basis are deemed to be instances of holonic organizational architectures. Depending on the degree of interde- pendence of holons and system, and the number of holonic levels within any given system, there will be a variety of such architectures. In each, there will be different intensities of information exchange and knowledge generation. All such systems will share a number of common features that together define the conditions for viability (sustainable survival) of the systems under conditions of changing operating en- vironments.

HOLONIC FEATURES OF THE OOP APPROACH

Having given this brief account of the holonic organizational perspective, there are several features of the OOP approach that have clear holonic interpre- tation.

The critical innovation is one of considering a program not as a complex entity divided by functions, but as an interacting system of relatively autonomous software entities termed objects. These are our holons. Objects are defined to possess their own identity. The property of encapsulation, which

hides the state and behavioral procedures of the object from the rest of the program, ensures that their operations are relatively autonomous. Objects receive messages from other objects, but the way they respond depends on their own internal state.

J. smrms SQUARE 251 1996; 34247-253

The concept of inheritance provides for an organizational architecture consisting of different holonic levels. At each level, an object can be considered as belonging to a superclass of progenitor objects, whereas it also contains inherited subobjects that also possess holonic features. Inheritance thus equates to our notion of a scalar chain of holonic entities.

The autonomy of objects is constrained by the needs of the total system, that is, the overall program. It is the main routine that sends instructions; these are not to be queried by objects, but are to be responded to according to the norms embodied in each object’s defining features. Thus the autonomy of objects is relative, not absolute. Another way of looking at this is to interpret the main program as setting the goals that objects need to accomplish, without specifying the means by which they are to be accomplished.

The concepts of polymorphism and dynamic binding allow OOP programs to operate with distributed, or decentralized, control. As circumstances require, the main routine calls for relevant objects to perform their tasks, or provide their services, without specifying how these services are to be provided. The objects simply communicate the results of their operations. Thus there is no central authority that can access all routines or all data, as is the case in traditional programming. Rather, in OOP, complex tasks are accomplished by the concerted activity of relevant objects, whose operations are coordinated by a main program. It is the complexity of the objects, rather than of the organizational structure, that makes task management so effective in OOP systems (Taivalsaari, 1993).

The concept of inheritance ensures that objects within a class share common features, often through several sets of super- and subclasses. This emphasis on commonality allows for coherence of process description at any level of the system; it is what system theorists defined as recursivity (Beer, 1985). This is a powerful attribute of all organizational systems structured along holonic lines, such as object-oriented programs.

The concepts of inheritance and polymorphism allow OOP programs to be cast in terms of general behavior, with objects being defined to possess general attributes and capabilities, which can then be

252 J. SYSTEMS SOFTWARE 1996: 34:241-253

J. Mathews

tailored to suit any particular occasion. It is this customization of object-oriented programs that makes them so flexible in the face of complexity.

Dynamic Attributes of Holonic Software Systems

The real test of the utility of holonic organizational approaches to the design of technical systems lies not in static relationships, but in their dynamic behavior, such as in their powers of adaptation, of responsiveness to new situations, and to the facility with which the system can grow, expanding or con- tracting its functionality by adding or deleting holons (objects).

In the case of OOP systems, these dynamic attributes are all important in ensuring flexibility. Changes and adaptations can be made to individual objects, which then flow through to all the members of their inheritance classes. Programs can be adapted and extended through the deletion or addition of new objects, without having to make consequent changes throughout the rest of the program.

Indeed, because objects change their internal state as a result of their behavior, their current state can be said to depend on their past behavior. In this sense, objects can be said to learn. And through the device of dynamic binding, the learning of individual objects can be communicated to the rest of the system, giving rise to a capacity for what we might call system learning (by analogy with organizational learning).

In all these ways, the advantages of object-oriented software over the traditional functionally structured form can be derived from its holonic organizational architecture.

CONCLUSION

The purposes of this article have been threefold. First, it has been demonstrated that OOP systems belong to a wider class of technical system, termed holonic, in that they all share the basic features of holonic organizational architecture. This could have the effect of making object-oriented systems paradigmatic of this approach, bringing systems designers in quite different disciplines to a realization of their common goals and methods, albeit ex- pressed in different technical terminology.

Second, the innovation of OOP has been placed in its fundamental organizational context. This allows the organizational dimensions of OOP to be brought to the fore and to be separated from other

considerations such as standardization, programming efficiency, recycling of program modules, economic matters such as costs, and other issues that are widely discussed in the software engineering literature. This could help to clarify the fundamental workings of object-oriented systems by demonstrat- ing how they achieve their efficiency and effective- ness through their organizational architecture.

Third, there is the question of design. The holonic paradigm serves not just as a descriptive device, but also as a prescriptive tool, that is, as a framework to aid design of software systems. The criteria of object autonomy, system dependence, and recursivity can be used to guide the further development of object- oriented systems. The utility of the paradigm is that it draws designers’ attention to the need to build mechanisms for first-, second-, and third-order coordination (i.e., within objects, between objects, and outside the objects via the program as a totality) into a viable program. Thus, the holonic paradigm could contribute to furthering the efficiency and effec- tiveness of OOP systems themselves.

REFERENCES

Beer, S., Diagnosing the System for Organizations, John Wiley & Sons, Inc., New York, 1985.

Booth, G., Object-Oriented Design, with Applications, Ben- jamin/Cummings, Redwood City, California, 1991.

Chugo, A., Sotelo, W., and Iida, I., Holonic routing scheme based on neural computations, in Proc IEEE Globecom, vol. 2, 1990, pp. 1366-1370.

Dillon, T., and Tan, P. L., Object-Oriented Conceptual Modelling, Prentice-Hall, Sydney, 1993.

Ege, R., Programming in an Object-Oriented Environment, Ap Professional, Cambridge, Massachusetts, 1992.

Hirose, M., Development of the holonic manipulator and its control, in Proceedings of the 29th IEEE Conference on Decision and Control, 1990, pp. 91-96.

Iida, I., Chugo, A., and Yatsuboshi, R., Autonomous routing scheme for large-scale network based on neural processing, in Proceedings qf the IEEE International Conference on Systems, Man and Cybernetics, 1989, pp. 194-199.

Koestler, A., The Ghost in the Machine, Hutchinson/ Danube, London, 1967/1976.

Korson, T., and McGregory J., Understanding Object-Ori- ented: A Unifying Paradigm, Commun. ACM (Septem- ber 1990).

Mandelbrot, B., 7’he Fractal Geometry of Nature, W. H. Freeman, New York, 1977.

Mathews, J., Holonic Organisational Architectures, Hum. Syst. Manug. (1996). In press.

Parsaye, K., Chignell, M., Khoshafian, S., and Wong, H.

Organizational Foundations of Object-Oriented Programming J. SYSTEMS SOFTWARE 253 1996; 3412477253

Intelligent Databases: Object-Oriented, Deductive Hyper- Taivalsaari, A., On the Notion of Object, J. Syst. Software

media Technologies, John Wiley, New York, 1989. 21, 3-16 (1993). Peitgen, H.-O., Juergens, H., and Saupe, D., Chaos and Yourdon, E., Object-Oriented Systems Design: An Integrated

Fractals: New Frontiers of Science, Springer-Verlag, Hei- Approach, Prentice-Hall, Englewood Cliffs, New Jersey, delberg, 1992. 1994.

Documents

Organizational foundations of object-oriented programming