Introduction

In our research we improve current visual component composition environments by introducing composition patterns as first class objects that can be defined, stored and reused independently of the components. We document both components and composition patterns using an extended sequence diagram notation. For a component, typical usage protocols are specified while a composition pattern specifies how a set of roles interact. From this documentation, we check whether a component can work as described by a composition pattern using finite state automata theory and we generate glue-code for the composition.

A Small Example

Our work is mainly targeted towards Java Beans. One of the tutorials for the Java Bean Box describes how to build a Juggler application so that a click on one button starts the juggling on the Juggler component and a click on the other buttons stops the juggling on the Juggler component. The construction of this application only requires visual wiring. We show how we use our approach to build a similar application but instead of one start button and one stop button, we try to use the same button component as a “toggle” button. This is not possible in the Bean Box (nor in any other commercial visual wiring tool I know) without manual adaptation of the code.

Figure 1: Toggling Composition.

Figure 2: Typical use of a Juggler Component

Figure 3: Typical use of a standard JButton Component

The documentation for a typical usage scenario for a standard Java Button and the Juggler component is shown in Figure 2. In our approach we also have a pallet of typical compositions on top of a pallet of components. Such a composition is defined as a protocol between a set of roles. The documentation for a toggle composition is depicted in Figure 1 This documentation is made by the developer of the construction kit and is transparent for the user. The user is uses a tool as shown in Figure 4 He or she selects the toggle composition from the palette with compositions and he fills the Toggle role with the Button component and the ToBeToggled role with the Juggler component. Our tool then generates all code necessary to build the application. It also checks compatibility of the components with the composition and generates mismatch feedback. In this little example the documentation of the JButton component is checked against the Toggler role. This is done based on the primitives (START, STOP, SIGNAL,…) and the sequence diagrams. We define a little hierarchy on the primitives where SIGNAL matches with any other primitive. It is easy to see that the JButton component matches with the Toggler role and that the Juggler component matches with the ToBeToggled role (for an exact definition of our compatibility definition see my PhD, chapter 4)

Figure 4: Composition Tool

In this case the tool performs the compatibility check and generates a main application that instantiates a button and a juggler. It generates code to set the options as specified for the button and the juggler. It also generates a small state machine component listening for JButton “actionPerformed” events and calling the “startJuggling()” and “stopJuggling()” methods on the Juggler component alternately. This means that all the necessary glue code is generated and that the tool does not require any programming knowledge.

Conclusions

It is clear that this approach is not limited to binary compositions only, nor is it limited to a single composition pattern. However, this very simple example already indicates the main principles and benefits of the approach. This research improves the code generation process found in current commercial visual component composition tools by generating full protocols between components instead of mere event/action pairs. However, the main benefits of this approach lie in the reuse of the composition patterns, the shift of expert knowledge from the application developer towards the component and construction kit builder and in the introduction of compatibility checking algorithms.