Strengths of componentware: end-user oriented, visual programming, rapid application development, large libraries of predefined domain-specific components.
Strengths of object-orientation: general purpose, solid software engineering capacity, application framework development, extensibility of the class library, availability of application builders.
In our experience component-oriented environments suffer from their closed nature, which limits the applicability of componentware. Conventionally, components can only be composed in an inflexible framework. Thus, users rapidly encounter the limits of the system, due to a lack of solid software engineering techniques offered. This is reinforced by the wide gap between composing components into an application and the development of new components or adapting the environment.
In some cases -- for instance object-based document exchange standards like OpenDoc and OLE -- the object-oriented approach meets with componentware. These are examples of object-oriented frameworks that are equipped with a predefined set of pluggable objects with which limited applications can be made. The actual strength of componentware, being rapid application development through visual programming, is not achieved in these examples, however.
We are working on ApplFLab (Application Framework Laboratory), an application development environment where solid object-oriented software engineering techniques go hand in hand with rapid application development by visual composition. This environment supports the construction of object-oriented frameworks together with the tools for visual composition of domain-specific components in the constructed frameworks. This constitutes a true domain-specific software architecture: rapid application development through visual composition by domain experts (not necessarily programmers) based on a soundly engineered framework architecture by software engineers. ApplFLab has the specific advantage that the domain experts and the software engineers work in the same medium. The integration is achieved by combining reflection techniques with object-oriented frameworks and graphical user interface builders.
The demonstration will show how easily a specialised visual composition environment is constructed. We will consider a framework for a particular problem domain. This is called the domain model. With a standard user interface builder, applications are built by dragging user interface components from a palette onto a canvas, editing their (visual) properties and connecting them to the domain model. The connection to the domain model is achieved mainly by programming. Herein lies the key difference with domain-specific visual composition. Application building with a specialised visual composition environment follows the same scheme as before, except that much less, or no coding is required; simply connecting the domain-specific components is sufficient. This will also be demonstrated. The technical part of the demonstration shows how the specialisation tools of ApplFLab are used to build domain-specific components, palettes of those components and properties editors. We will illustrate the difference between ÒnormalÓ use of ApplFLab whereby domain-specific components are created by composing standard or other domain-specific components, and "reflective" use of ApplFLab whereby domain-specific components (i.e. meta-level components) are used to edit the properties of other components (i.e. base-level components).
[Udell 94] J. Udell, ComponentWare, Byte, Vol. 19, No. 5, May 1994