5 Modularization

The modularization makes it easy to develop one dialog in teams, provided that the dialog has been split up into useful dialog parts (so-called modules). Moreover, resources (e.g. colors and fonts) can be provided by a central position and used by all application developers. Such dialog parts may also contain models which are available to all users. Thus it is no longer necessary to create one's own basic models, but one can use the models generated by the central position. This simplifies considerably e.g. the realization of a company's style-guide. In these dialog parts you may of course also store functionality which usually re-occur in the dialogs. Such partial functionality can so be re-used and maintained centrally.

You will find a detailed description of further application possibilities in the last section.

Apart from the aspects related to the dialog development, the modularization also has an impact on the runtime behavior of dialogs. Single dialog parts can be loaded and unloaded when required. This property makes the loading time seem shorter, since this loading time can be better spread over the entire working time of the dialog. Functions that are only rarely used can be loaded only when required and be unloaded after using to reduce the memory allocation of the dialog process.

If large dialogs are realized by partial dialogs, the maintenance increases since the dialog units are much smaller than usual. But as these dialogs are smaller you can maintain them more easily.

The modularization also bears an advantage for the use of the Distributed Dialog Manager (DDM): partial dialogs reduce the number of network links between client and server. Before the availability of the modularization every independent dialog had its own network connection. Now, by using partial dialogs one single connection is sufficient, which is one single server process.