Beyond object-orientation?

No introduction to object orientation is complete without an indication of the trends and technologies that surround the field. The word trend should be understood in its positive meaning of set examples and emerging guidelines. And `technologies', such as for example CORBA (the OMG Common Object Request Broker Architecture), as those that set the technological landscape which determines whether object-oriented approaches can be deployed effectively in practice.

Trends -- modeling

patterns -- examples of design
UML -- Unified Modeling Language

Technologies -- components

Web -- global infrastructure
CORBA/DCOM - the software bus
Java -- the platform?

Challenges

Applications $->$ Frameworks $<-$ Patterns

slide: Trends and technologies

At the design front, we may observe two dominant trends. The first may be called the patterns movement, which came into the forefront after the publication of Design Patterns, authored by a group of authors that is commonly known as the `Gang of Four', [GOF94]. The design patterns published there, and elsewhere e.g. [Coplien95], may be regarded as the outcome of mining actual framework and application designs for valid solutions that may be generalized to broader classes of problems. Design patterns focus on understanding and describing structural and behavioral properties of (fragments of) software systems.

Equally focused on understanding structure and behavior, but more from a modeling perspective, is the Unified Modeling Language (UML), which has resulted from a common effort of leading experts in object-oriented analysis and design, Grady Booch, Ivar Jacobson and James Rumbaugh, also known as `The Three Amigos'. UML, indeed the second trend, aims at providing the full notational repertoire needed for modeling every conceivable structural and behavioral aspect of software systems. An excellent introduction to UML is given in [Fowler97]. In Appendix UML you will find a brief introduction to the UML.

With respect to technology, the field is still very much in flux. A dominant factor here is the rapid increase in Internet usage and, more in particular, the Web. The Web has boosted the interest of the IT business world in the deployment of distributed object or component technology to extend their range of business. Nevertheless, the very existence of this infrastructure is in itself somewhat embarrassing, in that the Web and the technology around which it is built is not object-oriented. Perhaps it should be, but it simply isn't. Our embarrassment is aggravated when we observe, following [Szyperski97], that the technology which may change this, in casu component software, is in itself not object-oriented but, paraphrasing the subtitle of this excellent book, `beyond object orientation'. And even worse, object-oriented approaches at framework development have failed more often than they have succeeded, an observation which is confirmed by for example [Surviving]. Reading this you may think that object-orientation is in a deplorable state, and close the book. It isn't. First of all, because in terms of modeling and design there is no beyond object-orientation. And secondly, quoting Szyperski, `object-technology, if harnessed carefully, is possibly one of the best ways to realize component technology ...'. Well, believe me, it is the best way. Whether it is CORBA, Microsof (D)COM or Java that will become the dominant component technology is quite another issue; component technology that ignores the object-lessons is doomed to fail!

Challenges

Ignoring the component question for the moment, we may ask ourselves what the major challenges are that are confronting us as software developers. Briefly put, we still need to go a long way before we understand our applications well enough in terms of the (problem-solving) patterns underlying their construction that we can realize these patterns robustly in frameworks that are not only reusable conceptually, but that will also be (re)used in practice to develop cost-effective, competitive, economically viable applications.

More concretely, a major challenge for the next decade will be to develop and deploy frameworks that operate in areas such as finance, medical care, social welfare and insurance. This is explicitly not only a technical problem, but also a problem of coming to agreement with respect to the abstractions and corresponding standards that provide the computational infrastructure for these domains. Also on my wish-list is the separation of logic and control, by which I mean the decoupling of the more or less invariant functionality as may be provided by for example business objects and business processes and the more variable logic that controls these processes. In other words, it is necessary that the business logic is made explicit and that it is factored out of the code effectuating it.

Challenges in O-O

vertical framework development -- finance, medical care, insurance
separation of 'logic' from 'control' -- business rules
distributed object technology -- heterogeneous systems
visualisation -- structure and processes
knowledge intensive applications -- declarative
heterogeneous systems -- fragmented applications

slide: Challenges

Another challenge is to integrate the various technologies into our frameworks and systems. In effect we will see more and more heterogeneous systems, composed of components from a variety of suppliers. These components may be implemented in every conceivable language, and may run on different platforms. How to connect these components in a reliable manner is still an open problem. And more generally, although there are solutions for crossing the various boundaries, the platform boundary and the language boundary, there are still a lot of problems to solve. In this book we will explore some of these problems, and get some experience with some of the solutions.

Both our hardware and software technology are improving rapidly. Yet, we are still stuck with the WIMP interfaces. In my opinion, it is time for a change. What I would like to see is an exploration of 3D user interfaces and 3D visualisations of the structure and processes underlying information-intensive applications. Although not specifically related to object-oriented software development, this is an area where object orientation can prove its worth.

When we think about real applications, for example information or business services on the Internet, they are usually the kind of applications that we may characterize as knowledge-intensive applications. In a somewhat idealistic vision, we may think of application development that consists of composing components from perhaps even a number of frameworks, so that we don't have to bother with the tiresome details of network access and GUI development. Then what remains to be done is to glue it all together, and provide the information and knowledge that enables our application to deliver its services. Partly we can rely on database technology for the storage and retrieval of information. But in addition we will need other declarative formalisms for expressing, for example, our business logic or, as another example, for expressing the synchronisation constraints of our multimedia presentation.

Considering Web applications, even as they are today, we see applications that consist of a mixture of code, tools and information. The phrase fragmented applications seems apt here. For example a store selling books on the Internet needs everything ranging from Javascript enabled webpages, to a secure CORBA-based accounting server. It is very likely that such applications will be developed partly by composing already existing components.

In his book, [Szyperski97] argues that component-technology must be considered as the next stage, that is (as the subtitle of his book indicates) beyond object orientation. This is true to the extent that naive object orientation, characterized by weak encapsulation and white-box or implementation inheritance, has proven to be not entirely successful. What we need is a more robust specification of the behavioral properties of objects, for example by contractual specifications, and a stronger notion of encapsulation, in which not only the inner world of the object is protected from invasions from the outside, but where the outer world is also shielded from the object itself, so that the object cannot reach out into a world that might not even exist. More concretely, objects must be designed that allows them to be used in a distributed environment. They must observe, as Wegner puts it, the distribution boundary.

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.