sign in sign up
<<
Home , Programming paradigm

DICE AN OBJECT-ORIENTED TOOL FOR RAPID PROTOTYPING

Wolfgang Pree Institut für Wirtschaftsinformatik Johannes Kepler University of Linz A-4040 LINZ, Austria -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 reation E nvironment), a tool for rapid 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 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’ 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 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 set studies around the prototyping-oriented of basic mechanisms. ET++ provides a design and implementation of DICE’s homogenous object-oriented class that components (Section 3). The suitability of integrates user interface building blocks, object-oriented programming for prototyp- basic 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 . 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 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 -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 4. Code generation functionality as far as possible. For instance, if the user interface layout is changed, code The basic idea of code generation is the (i.e. ET++ subclasses) must be generated following: A subclass of the ET++ class again. The user-defined classes that have Document is generated for each window been derived from the originally generated specified with DICE. The dynamically bound classes are not concerned. Changes of these method Control of this class is called if an classes become only necessary if interface interface element is activated. Let us look at elements are removed (this would result in the cash dispenser interface (Fig. 2) as an redundant code) or switched between example: When the “Ok” button windows of the prototype. (component name: “OkButton”) is pressed, a check of the correctness of the displayed 2.2.3 Integration of Conventional amount (in the Text Field called “Display”) and Object-Oriented Systems is necessary. The generated class CashDispenser implements no special Writing applications based on frameworks behavior if the “Ok” button is pressed; this can result in an enormous reduction in source behavior couldn’ be specified with the code size (see Section 1) since they provide predefined messages: powerful building blocks for the kind of applications they support. Unfortunately, the class CashDispenser: public Document { only frameworks available are for user ... interface programming. Therefore it is very void Control(int id) { important for a user interface prototyping ... tool to facilitate communication with other case OkButton: systems. Since ET++ is implemented on break; // no action UNIX systems, the socket mechanism is used ... for interprocess communication of indepen- } dent processes. The interface specified with DICE and the process interacting with the }; interface form a so- called UIMS (User For this reason the class ExtCashDispenser Interface Management System) with (stands for “Extended Cash Dispenser”) is mixed control ([Bet87, Hay85]). implemented in order to check the correctness of the amount:. programming and a specific application User UNIX framework, the prototyping cycle as depicted Interface Process in Fig. 6 results.

Figure 5. Communication between application and user interface The suitability of an application framework for prototyping depends on the reusability Communication between the application and and extensibility of the available building user interface (see Fig. 5) is based on a blocks. DICE itself is implemented on the simple protocol: If a user interface element is basis of ET++. Short case studies drawn from activated, the name and (if meaningful) its the implementation of DICE components value are sent to the connected process. The show that the desired reusability of software value of a Radio Button, for instance, is components often cannot be achieved even “TRUE” or “FALSE”; an Action Button by using state-of-the-art application frame- and a Menu Item do not send a value. On the works or object-oriented programming in other hand, the connected process can ask for general. the value of each interface element by sending its name and a “?” to the interface. Extend generic application by Thus the user interface developed with DICE modifying or adding classes can be connected with any conventional software system. E.g., the functionality of the cash dispenser depicted in Fig. 2 was implemented in C. Necessary modifications experiment with prototype or enhancements of the functionality are implemented in a C program. Immediately after compilation and starting of this modify or add class program, the modified functionality can be tested together with the user interface prototype without restarting DICE. Figure 6. Prototyping with an application framework

The development of software systems that are to be connected with the interface prototype First the Good News can be supported by available methods and tools. [Bisch90], for instance, describes a new One of the most important advantages paradigm called “Prototyping-Oriented associated with object-oriented software Incremental ”. On the building blocks is that they naturally lend other hand it is, of course, possible to connect themselves to bottom-up reuse, extension and the interface prototype with object-oriented combination [Mey88, Mey89]. Application systems developed by means of any domain- frameworks in particular provide a structure specific class libraries that might be available. in their “empty” application, which is to be extended accordingly for an application that is based on it. Certain extensions are necessary for almost every application. These 3 Implementation of DICE extensions are prescribed by the framework and forseen by the designer of the framework An application framework can be classified as classes. Thus it is easy to reuse and extend a simple prototyping tool: The abstraction those building blocks. level is raised and the implementation effort can be drastically reduced due to powerful Generally speaking, classes can be reused and building blocks. If we assume that a software extended without problems if the designer developer is familiar with object-oriented has forseen the wishes of future users. The classes of DICE, for example, have been designed in such a way that the following these dynamically linked methods in adaptations can be achieved by means of subclasses, class behavior can be modified. object-oriented techniques (i.e., without modifying the source code of the tool): The above procedure is possible only at locations where the class designer provided • adding new interface elements, hooks. In order to a more general extensibility possible, the following • modifying the parameters to be defined for (theoretical) solutions could be suggested: an interface element, and • adding new messages that are “under- • A hook method is invoked between every stood” by the interface elements. pair of statements of a method. Modifications not forseen by the designer • Every class method consists of exactly one can be pretty hard to realize, as the following statement. case studies show. The idea of a narrow inheritance interface that is usually implemented in application Then the Bad News frameworks [Wei89] contradicts these suggestions: Behavior that is spread over [Mey88] states that reusability does not work several methods in a class should be based on automatically for object-oriented software a minimal set of dynamically bound building blocks: Disregarding the methods. This allows a client deriving economical, political and psychological subclasses from an existing class to override problems involved, software will only be just a few methods in order to adopt its reused if the potential beneficiaries know behavior. Not adhering to this narrow about available components. Unfortunately, inheritance principle often means that too this is not the only problem, as two examples many methods have to be overridden, will demonstrate. resulting in ugly and bulky code.

We must note in advance that ET++ is not yet For extensions that were not foreseen, the construed by its designers as a finished class source code of the respective superclass must library. DICE was implemented on ET++ be copied and complemented by the desired Version 1.1. The conclusions drawn about statements. This procedure was unavoidable, application frameworks are not, however, for example, in the modification of the ET++ weakened by the argument that ET++ is class VObjectStretcher (which stands for continually being improved. In our opinion “Visual Object Stretcher”), which is outlined complex software systems will always be below: inadequate for certain problems. Object- oriented programming is intended to The ET++ class VObjectStretcher is a subclass eliminate precisely this weakness of software of the ET++ class Command and can be used systems. The general reasons why this is not for stretching VObject objects. Thus it serves always possible in a clean way even with the as a basis for resizing interface elements in object-oriented programming paradigm can DICE. The direct use of this class without be discerned from the ET++ specific case adaptation is undesirable for the following studies. reason: If the size of an interface element has Missing Hook Methods changed, the entire window contents must be recalculated (while the mouse is being In order to be able to modify the behavior of moved) in order to maintain the interface as a class in subclasses, hook methods need to be WYSIWYG. If the class VObjectStretcher is called at the respective locations in the used directly, only the respective outline methods of the base classes. By overwriting rectangle of the interface element to be changed is drawn when the mouse is moved error in the implementation of the method (with mouse button pressed). The window mentioned above was not detected. The contents itself are recalculated and redrawn modifications of the class MatrixView by only after the mouse button is released. creating a subclass would not have been possible without the source code since the Thus the class ItemStretcher was created as a relationships between the class methods could subclass of VObjectStretcher in order to not have been discerned otherwise. implement the behavior described above. There was no dynamically linked hook The comprehension of a class to be modified method in the class VObjectStretcher that is can become more difficult due to the “Yoyo invoked with each mouse movement (with Problem” ([Taen89]). This issue is related to mouse button pressed). In the missing hook objects sending themselves messages, which method, the desired behavior could have been may cause the execution of methods up and implemented in two statements. down the class hierarchy.

Since the superclass VObjectStretcher pro- 4 Conclusion vided no other possibility, the source code of the relatively extensive method TrackMouse We are convinced that application was copied into the method TrackMouse of frameworks available today are well suited as the class ItemStretcher and extended by the a basis for object-oriented programming. necessary statements at the required position. System design decisions are partially This procedure was only possible because prescribed. A number of object-oriented ideas, as offered in an application framework, • the source code of the class to be modified significantly reduce the implementation was available; and effort for systems. • the instance variables used in the method TrackMouse of the class VObjectStretcher DICE demonstrates how currently available can be accessed in their subclasses. application frameworks can be enhanced in order to serve as powerful prototyping tools. These facts directly contradict the promises DICE was evaluated in several small and of object-oriented programming. medium-scale projects. Parts of the tool (especially dialog sheets) were generated with Correcting Framework Errors DICE itself. The next step will be the integration of a simple programming In order to correct errors or to eliminate environment for C++ so that application restrictions in the library classes by creating specific behavior can be programmed in an subclasses, the source code is often necessary object-oriented manner within DICE. in order to understand class behavior and find the methods to be modified. The ET++ class MatrixView serves as an example that an error couldn’t have been removed without the source code. MatrixView is a basic building block for user interface elements that include a matrix of selectable objects References (e.g., menu items, graphically depicted tools in a toolpalette, etc.). If one object is selected, a class method returns the row and column of [Bisch90] that object in the matrix. Bischofberger W..: Prototyping-Oriented Incremental Software Development: Paradigms, Since the objects in such lists are usually Methods, Tools and Implications, doctoral ordered vertically in only one column, an thesis, University of Linz, 1990. [Bet87] [Taen89] Betts, B. et al.: Goals and Objectives for User Taenzer ., Ganti M., Podar S.: Problems in Interface Software; in: , Vol. Object-Oriented Software Reuse, Proceedings of 21, No. 2, April 1987, pp. 73-78. the 1989 ECOOP, July 1989.

[Flo84] [Wei88] Floyd, Ch.: A Systematic Look at Prototyping; Weinand A., Gamma E., Marty R.: ET++ - An in: Approaches to Prototyping, Springer, 1984, Object-Oriented Application Framework in C++; pp. 1-18. OOPSLA 88, Special Issue of SIGPLAN Notices, Vol. 23, No. 11 (1988) [Gam89] Gamma E., Weinand A., Marty R.: Integration [Wei89] of a Programming Environment into ET++ A Weinand A., Gamma E., Marty R.: Design and Case Study, Proceedings of the 1989 ECOOP, Implementation of ET++, a Seamless Object- July 1989. Oriented Application Framework; in: Vol.10 No.2, Springer 1989. [Hay85] Hayes, P.J., Szekely, P.A., Lerner, R.A.: [Wil90] Design Alternatives for User Interface Wilson D.A., Rosenstein L.S., Shafer D.: Management Systems Based on Experience with Programming with MacApp; Addison-Wesley, COUSIN; in: Human Factors in 1990. Systems: CHI’85 Conference Proceedings, Boston, Mass., April 1985, pp. 169-175.

[Jör84] Jörgensen, A.H.: On the Psychology of Prototyping; in: Approaches to Prototyping, Springer, 1984, pp. 278-289.

[Mey88] Meyer B.: Object-Oriented Software Construc- tion; Prentice Hall, 1988. Trademarks: [Mey89] Apple and MacApp are trademarks of Apple Meyer B.: From Structured Programming to Computer Inc. Object-Oriented Design: The Road to Eiffel; in: Structured Programming Vol.10 No.1, Springer NeXT and App Kit are trademarks of NeXT Inc. 1989. SunWindows and NeWS are trademarks of Sun [NeXT89] Microsystems. NeXT, Inc.: 1.0 Technical Documentation: Concepts; NeXT, Inc., Redwood City, CA, UNIX and C++ are trademarks of AT&T. 1989.