DICE AN OBJECT-ORIENTED TOOL FOR RAPID PROTOTYPING Wolfgang Pree Institut für Wirtschaftsinformatik Johannes Kepler University of Linz A-4040 LINZ, Austria E-mail: K2G0190@AEARN Abstract 1 Introduction This paper deals with object-oriented The object-oriented programming paradigm programming in several ways. On the one gave rise to great hopes of drastically hand it presents DICE (Dynamic Interface improving the extensibility and reusability of C reation E nvironment), a tool for rapid software components. The assertion that in prototyping implemented in an object- object-oriented programming a linear oriented manner. In particular it discusses the increase in coding effort can produce an question of how dynamic behavior can be exponential rise in functionality is reinforced added to a user interface prototype. It also by such user interface application presents a useful and powerful way to frameworks as MacApp [Wil90], AppKit combine conventionally developed and [NeXT89] and ET++ [Wei88, Gam89, object-oriented software systems. On the Wei89]. Experience has proven that writing a other hand, the possibilities and limits of complex application based on frameworks currently available application frameworks such as those mentioned above can result in a for prototyping-oriented software develop- reduction in source code size of 80% and ment are examined on the basis of DICE’s more compared to software written with the implementation. support of a conventional graphic toolbox. Keywords: Apart from this enormous code reduction, prototyping, integration of conventional and application frameworks offer other important object-oriented systems, application advantages: the abstraction level is raised, frameworks, class libraries, ET++, C++, and a standardization is achieved in terms of reusability, extensibility both the user interface and the code structure. However, the abstraction level of an application framework is considered to be too low to support prototyping in a comfortable way. Implementing applications with a framework absolutely requires specialized programming ability (especially in object- oriented programming). Furthermore, the programmer must become familiar with the particular application framework—a time investment that cannot be neglected. This fact One of our basic premises was not to change is contrary to the philosophy of prototyping. the application framework itself. Only this restriction would allow us to test the DICE was implemented for/with an appli- suitability of the object-oriented approach to cation framework in order to extend such a the extension and modification of given tool in the direction of rapid prototyping. software building blocks. We chose ET++ for the following reasons: This report portrays DICE as a rapid Compared to other available application prototyping tool based on an application frameworks, ET++ was the cleanest object- framework (Section 2) and describes case oriented implementation based on a small set studies around the prototyping-oriented of basic mechanisms. ET++ provides a design and implementation of DICE’s homogenous object-oriented class library that components (Section 3). The suitability of integrates user interface building blocks, object-oriented programming for prototyp- basic data structures and high level ing is summed up in the conclusion (Section application components. ET++ was 4). implemented in C++ and runs under UNIX and either SunWindows, NeWS, or the X11 window system. The design and 2 Prototyping with DICE implementation of ET++ is described in detail in [Wei88, Wei89]. Furthermore, the author Prototyping is a paradigm that is well (and implementor of DICE) had the established in research and practice for opportunity to work directly with the enhancing the Software Life Cycle and developers of ET++, E. Gamma and A. improving software quality. There are various Weinand, and thus got to know ET++ publications discussing definitions of intimately. prototyping in depth (e.g., [Flo84, Jör84, Bisch90]). User Interface Prototyping in Figure 1. DICE’s Control Panel particular is important for the development of • With conventional programming: A applications that have non-trivial user protocol was developed that allows the interfaces by providing better requirement prototype to be connected with other definitions. This is especially true for UNIX processes using the UNIX Inter- applications with highly interactive graphic- process Communication mechanism. oriented interfaces. Prototyping this kind of The simulation of the constructed interface user interface with proper tools can (screen layout together with its dynamic significantly reduce the implementation behavior) is at the designer’s disposal. effort (especially if the prototype can be enhanced to the final product). Furthermore, the acceptance of the software system is 2.1 Static Layout Aspects improved since the interface can be discussed with the later user at an early stage of the development. The main building block of a DICE application is a Window. When the “Edit DICE supports the graphical specification of Window” button in DICE’s Control Panel is the user interface layout (see Section 2.1). In pressed (see Fig. 1), an empty window is order to enhance the functionality of the opened. To insert user interface elements, one prototype, most comparable tools available has to choose the proper element in the today provide interfaces to third generation control panel and mark the position where languages or some kind of an integrated third the item is to be placed in the window. generation language. DICE offers three possibilities for enhancing the functionality Besides the usual interface elements (Buttons, (see Section 2.2): Text Fields, Popup Items and scrollable Subwindows, as shown in Fig. 1) there are two • Without programming: Interface elements elements for grouping interface items – communicate with one another by sending Cluster and Expander. They allow a predefined messages. comfortable specification of the window • With object-oriented programming: Sub- layout and of the behavior of the contained classes of ET++ classes can be generated. elements if a window is resized. Application-specific behavior is added in subclasses of the generated classes. Figure 2. Sample user interface specified with DICE Figure 3. Message Editor DICE provides undoable editing functions as “Cash Dispenser” when the “Stop” button known from state-of-the-art WYSIWYG is pressed). editors: moving and resizing of the elements, From each element that can be activated cut/copy/paste between windows and different (Buttons and Menu Items), any number of DICE prototypes, etc. The parameters of messages to other elements can be specified. interface elements are defined in specific If you test the prototype (by pressing the parameter sheets. Figure 2 shows the “Test Prototype” button in DICE’s Control parameters for an action button. Panel – see Fig. 1) and activate an interface element, the messages specified for that 2.2 Adding Functionality element are sent to their receivers. They to the Prototype effect the corresponding change in the user interface. Thus rudimentary dynamics can be The behavior of a system is above all realized without programming effort. determined by its dynamics. Therefore it is not enough just to describe screen layouts. One of the criteria for judging prototyping Rather, it should also be possible to portray tools is their extensibility (e.g., adding new the dynamic behavior of a system and at the messages to DICE’s interface elements). This same time to develop the prototype to an aspect is discussed in Section 3. accomplished application. For this purpose, DICE offers the possibilities described below. 2.2.2 Generating Classes 2.2.1 Predefined Messages DICE simulates the static and dynamic Certain messages are assigned to each user behavior of the specified prototype when that interface element (e.g., the messages “Open” prototype is tested. Thus no code generation and “Close” to a window, the messages and no compile/link/go cycles are necessary “Enable”, “Disable” and “SetText(...)” to for testing. In order to enhance the prototype a text field, etc.). Let us take the “Cash based on the application framework ET++, Dispenser” interface (see Fig. 2) as an DICE creates subclasses of ET++ classes by example. The “Cash Dispenser” window is pressing the “Generate Code” button (Fig. to be closed when the “Stop” button is 1). The compilation of the generated classes pressed. To specify this functionality, one results in an application which works exactly presses the “Link...” button in the parameter like the specified prototype. The generated sheet of the “Stop” button (see Fig. 2). By classes need not (and should not) be changed means of DICE’s Message Editor (see Fig. 3), when further functionality is added in the the desired dynamic behavior can then be sense of evolutionary prototyping. Additional defined for the “Stop” button (i.e., that the functionality can be implemented in sub- message “Close” is sent to the window classes of the generated classes by overwriting or extending the corresponding dynamically class ExtCashDispenser: bound methods (see Fig. 4). public CashDispenser { ... void Control(int id) { ... case OkButton: int disp=Display->Val(); if (AmountOk(disp)) ET++ classes ... ... break; ... classes generated by DICE CashDispenser::Control(id); ... } }; ... user-defined, application- This kind of code generation separates specific classes changes of the user interface from coded Figure