Heterogeneous systems

Hypermedia require the connection of (a large number of) hybrid components. Moreover, as we have seen in the previous section, a multi-paradigm approach seems to be best suited to cope with the variety of aspects (both computational and presentational) involved in the application of hypermedia technology. The problem of achieving a symbiosis of hybrid components bears a close analogy to the problems addressed by object-oriented technology.

Hypermedia technology

Heterogeneous systems


slide: Heterogeneous systems

Object orientation is about program organization, and not about programming per se. This was the characterization given at the beginning of the first chapter. Subsequently, we have dealt with modeling, validation, programming language constructs (including constructs for distribution and concurrency), programming techniques, theoretical foundations, libraries and system development support. Our discussion of distribution and system support (as proposed by the OMG and Microsoft OLE) paved the way, so to speak, for the viewpoint that object-oriented technology intrinsically supports the development of heterogeneous systems. In particular, the techniques of wrapping (employing encapsulation and refinement) and distribution (for example, by employing object request brokers) are invaluable in realizing heterogeneous systems as the integration of multiple (hybrid) components. Wrapping allows us to incorporate old (procedural) code by defining a clean object interface, whereas distribution supports the incorporation of distinct active components. The motivation for employing wrapping as a technique for reuse may be that the code involved cannot be rewritten, due to a lack of resources or expertise. Wrapping, despite its ad hoc nature, may in practice be a good substitute for (object-oriented) redesign. The motivation for distribution may simply be the need to have applications operating on a local or wide area network. Another aspect of distribution of course is reuse, not on a component level but on the level of applications (employing other applications, such as a text editor, as a functional component). One aspect of heterogeneous systems that has not been adequately dealt with thus far (except to some extent by the OMG CORBA proposal, see section OMG) is that different components of an application may require a different (application) programming language. To a certain extent, this problem has also been dealt with by 4GL application generators, but only in a very limited, application-dependent manner. As may be observed in a number of research projects, there seems to be a trend towards the development of embeddable interpreters, and the combinations of interpreted languages (such as Tcl or Perl) with system implementation languages (such as C, C++, Lisp and Prolog). Moreover, in many cases a widget binding (to Tk widgets, Athena or Motif widgets) is offered in both languages, similar to that described in the previous section. However, thus far, language embeddings have only been realized on the level of functions and procedures and not on the level of objects, providing a mapping between object interfaces instead of single functions. This is exactly the problem addressed by the OMG proposal. However, there seems to be no generally accepted solution thus far. This brings us to our final question. What will be the future of OOP? Is it worth investing in, and where will it lead us?

The future of OOP

Object orientation is here to stay, as object-oriented programming, as well as in the form of object-oriented modeling and design. Object orientation is commercially viable, as testified in  [Harmon93]. Moreover, it is the method of choice for many of large companies (including HP, Sun and Microsoft) and, increasingly, many smaller ones. To have an indication of where object orientation will lead us, we conclude by reflecting on the meaning of the phrases encountered in project and research proposals.

Terminology

\zline{\fbox{project speak}}
slide: Terminology -- project speak

The phrase open is mostly used to indicate that the result will not be a closed system, but may be extended to include extraneous functionality. By their very nature, objects are extensible by means of refinement by inheritance (provided they are well-designed). The phrase heterogeneous is often meant to indicate that the result is dependent on extraneous components, that will be obtained from some external source. Given the complexity of many systems (including information systems, management support systems or systems for scientific visualization), this is only natural. The difference with earlier times lies primarily in the way in which such extraneous components are being (re)used. Object-oriented technology in principle makes it possible to reuse components in a clean way, without requiring access to the source code. The phrase distributed is often motivated by the wish to support the interaction of geographically distinct components or to achieve speed-up by means of parallel/distributed processing. However, parallel/distributed programming is intrinsically difficult. Distribution seems to be an area in which the technology has not (yet) outgrown the level of systems programming. Also here, object orientation appears to be gaining ground. The phrase object orientation itself has in the past often been abused. See  [Ki89] and  [St88]. However, now the technology is maturing, the standards with respect to what may be called object-oriented are becoming more solid, and object orientation is increasingly recognized as being valuable both in modeling and programming, and not merely as a trend. Finally, the phrase intelligent, encountered in a variety of situations, may be taken to mean either adaptable, tunable to user needs, augmented with reasoning capabilities, or simply superior. In a more neutral way, it may be taken to mean the incorporation of logic-based, declarative (programming) formalisms to specify the functionality of a system in a knowledge-based manner. On the one hand, there lies a challenge to incorporate (and actually employ) object-oriented technology in, for example, expert systems, but also hypermedia and (intelligent) information systems. On the other hand, I am convinced, that logic-based programming and specification techniques may be fruitfully applied in object-oriented system development. That was the good news. And now for the bad news. One potential danger that haunts the field of object orientation is the diversification of programming languages, programming techniques, analysis and design methods and development frameworks. Even for a single language like C++ there already exist a number of mutually incompatible compilers. The only way to resolve the problems of proliferation is standardization. Standardization involves not only the adherence to a single language reference manual but also an agreement on the terminology employed. Moreover it requires the adoption of appropriate conventions concerning issues of design and the utilization of object-oriented techniques. This book has been written from the conviction that an understanding of the theoretical foundations of object-oriented programming is a prerequisite to the development of a consensus concerning these issues, if not interesting for its own sake. In summary, the future of object orientation lies in stabilization and consolidation.