| [Up] [Search CIT] |
In parallel with the hardware evolution, client/server programming is gaining still more popularity over mainframe computing, and connecting computers from different vendors in a local area network (LAN) in a manner transparent to the user has become a necessity. This factor in connection with the popularity that the Internet has gained outside the academic world, has meant that much attention is given to distributed computing by the software industry.
At the same time object-oriented (OO) programming has become the dominant paradigm, which means that developers tend to structure software in a modularised manner. Objects in different source modules may encapsulate different functionality of the entire program, display and storage management for example. The train of thought that OO provokes joined with that of distributed programming has meant that monolithic applications are no longer as popular as they used to be.
Monolithic applications have the inherent problem of being hard to maintain because the entire program must be recompiled each time a small part of it has been upgraded. The different parts of such applications can be hard to use across applications, and even so it seems wasteful to have the same code potentially reside several times on the same machine or indeed on different machines in a network.
A challenge that faces the software industry today is therefore to build frameworks for developing software that
CBSD extends the client/server paradigm by allowing components to interact between different machines and sometimes even move across a network. A component encapsulates behaviour and state, and as such resembles the traditional OO notion of an object, which is no coincidence since CBSD borrows most of its foundations from OO.
Building a component model in the spirit of OO is not an easy task at all. Many of the concepts from object-oriented programming are not directly transferable to CBSD, and some of them can only be partially mapped. The fact that components reside in runtime modules, the implementation of which is not visible to the user, makes inheritance and related concepts like specialisation and virtual methods very difficult to support in a component model.
The runtime modules in which the components live also raise a number of issues that must be dealt with. How is different versions of the same module managed? Can modules and thereby components be dynamically replaced even when there are clients of it running? But that is not all.
By supporting distributed computing, component models must confront and overcome difficulties pertaining to that area also. Some strategy for transparent interconnection must be defined, and schemes for dealing with network congestion, in the case of many clients using the same component, needs to be invented. In addition issues like access security and managing transactions between multiple clients of a component must be addressed.
Using components as building blocks in software development raises the problem of defining components that can be easily reused across applications, which may not be an easy task at all. By all means it is at least as difficult as building general classes in traditional OO. This carries over to the problem of using third party components as part of the application model. A developer needs to know exactly what a component does and how to use it, and even so fitting the component into the model may still be difficult.
With all the issues that component models embrace, actually using them to build software may not be trivial. A designer would very often benefit from possessing tools that support CBSD in a way that fits into the object-oriented design strategy that he has employed for the entire application. He should be able to select certain classes as suitable for being components, and should not need to specify the implementation language until such time as the entire design is finished. The tool should also automate trivial and bothersome tasks that pertain to the specific component model.
The topic of this thesis is component models and tools that support their use. The focus is on component models, not on how a design strategy using components can be carried out. Addressing the problems that have been outlined above, the structure of the thesis is divided into four areas.
First, an investigation of the issues that component models must address, seeks to build a foundation on which concrete, commercial models can be evaluated. The issues are classified with respect to the area from which they have been inspired, and argues why each particular concept should be dealt with by component models. On this basis a short review of how the commercial models CORBA and Java Beans tackle the issues, provides a comparative fundament for the next chapter.
The specific component model, which we have treated in depth is Microsoft's Component Object Model (COM). COM has grown to become the facility for controlling applications externally on the Microsoft Windows platform, and a large majority of the operating system facilities can also be accessed through that technology. Today it is possible to control applications like Word and Internet Explorer fully through COM, which means that enriching new applications with text editing capabilities or web browsing facilities boils down to learning the COM interfaces of these programs. A developer can even hide the fact that other programs are used, by customising the applications and embed them within a frame of his own application.
COM is also viewed in the light of our requirements for component models in general, while using the examples of Java Beans and CORBA to contrast actual solutions to the issues. The chapter concludes with a detailed summary of how and how well COM relates to the general issues. In order to provide detailed knowledge of how COM components are built, the chapter will use sample code where needed.
Having focused on the model, it is time to take a look at development environments that claim to support COM based software engineering. Chapter 4 introduces a method for evaluating COM support in development environments, which was defined as part of a research project under the Centre for Object Technology (COT). The method was used for investigating four different environments, in order to reveal strengths and weaknesses.
We were engaged in the project from the very beginning, and participated in defining the investigation method, which came to consist of two parts. The first, a test application that should be built in an environment sought to answer specific questions in the second part, the Taxonomy document. It became our responsibility to apply the method to one of the four environments, Delphi from Borland Inc., and so chapter 4 presents that investigation.
Working with the COM model and investigating environments for its support helped identifying areas that could be assisted by tools. The last chapter introduces a number of such utensils and provides a detailed discussion of a visual tool for designing and generating component source code for various languages. We have in fact implemented the better part of this last utility, and so the tool discussion is not hypothetical.
All source code referred to in the thesis including the tool and the corresponding binaries can be found on the companion CD, which is attached to the cover of this thesis. On the CD the actual evaluation from the research project as well as an electronic form of this document can also be found.