- Email: [email protected]
An environment for the design and implementation of visual applications
ARTICLE IN PRESS
Journal of Visual Languages and Computing 15 (2004) 439–461
Journal of Visual Languages & Computing www.elsevier.com/locate/jvlc
An environment for the design and implementation of visual applications Giuseppe Della Penna, Benedetto Intrigila, Sergio Orefice Dipartimento di Informatica, Universita" di L’Aquila,Via Vetoio, Copito, I-67100 L’Aquila, Italy Received 7 October 2002; received in revised form 27 May 2003; accepted 30 March 2004
Abstract In this paper we present Interactive Visual Application code Generator (IVAG), a tool for the automatic generation of the code and the documentation of software applications. It is specifically tailored to support prototyping and rapid development of visual applications, where the user interface is a relevant part of the application. IVAG is currently being experimented on a variety of case studies, in particular web-based applications. r 2004 Elsevier Ltd. All rights reserved.
1. Introduction Visual programming has become a key component of multimodal communication and human–computer interaction and seems likely to gain even more importance in the future, [2,3]. For example, the explosive growth of visual communication on the World Wide Web is an indicator of the increasing use of visual languages and visual applications. In the past years, much research has been done in the theory of visual languages, [3,4], in order to give a systematic approach to their specification, analysis and implementation. On the contrary, no common methodology for handling general visual applications has emerged. Usually, programmers implement graphical applications in an ad hoc way by applying a general-purpose visual programming environment like Microsoft Visual Basict. As a consequence, whenever E-mail addresses: [email protected] (G. Della Penna), [email protected] (B. Intrigila), orefi[email protected] (S. Orefice). 1045-926X/$ - see front matter r 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.jvlc.2004.03.002
ARTICLE IN PRESS 440
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
an application has to be modified or augmented, this cannot be accomplished without substantial reprogramming. To this need, we have developed an environment for the design and the implementation of visual applications, namely the Interactive Visual Application code Generator (IVAG). IVAG is provided with a graphical front-end where the application requirements can be specified through state-transition diagrams describing the user interface and the behaviour of the application. These diagrams are directly compilable within the system that automatically generates the code of the application. The underlying formalism of IVAG is the Visual Automaton, a statemachine model for the specification of visual applications that we presented in [1] together with an early prototype of the system. The Visual Automaton extends the state-machine model first introduced in [5] for specifying user interfaces and applies it to the rapid development of visual applications. In this paper we discuss the architectural design of the advanced version of IVAG in detail and its new features and applications. The key characteristics of IVAG are the following: *
*
*
The generated code is highly modular, reusable, and preserves the logical organization of the application. The user interface portion is separated from the rest of the application, so that it can be easily updated without requiring reprogramming other parts of the application. IVAG supports the rapid development of small/medium code size applications.
Moreover, as opposed to most Rapid Application Development (RAD) tools [6,7] where fast delivery often results in poor or even missing documentation, IVAG also produces an appropriate documentation of the generated code, providing a sound platform for maintenance and further development. The paper is organized as follows. In Section 2, we illustrate the architecture of the IVAG system and its main software modules. Section 3 describes the structure of the code and of the documentation generated by IVAG. A prototype case study, the Web/WAP-based application WapNews, is presented in Section 4. Then, in Section 5 we discuss the practical applicability of the IVAG approach and report some experiments of usage in real settings. Related work is summarized in Section 6, where we compare IVAG with other similar tools. To conclude, some final remarks are outlined in Section 7.
2. The software architecture of IVAG In this section we describe the visual programming environment IVAG. The tool is provided with a graphical front-end that enables the user to specify an application through a state-transition diagram; this diagram describes the application interface and its behaviour. Then, IVAG automatically generates the code for the final program and a proper documentation. The theoretical aspects of the formalism
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
441
underlying the state-transition diagram specifications used in our methodology (i.e. the Visual Automaton) have been presented in [1]; however, the main features of the formalism are recalled in this section, thus making the present paper self-contained. IVAG has been developed using the Microsoftt Visual C++t language and runs on PCs under the Microsoftt Windowst operating system. The software architecture of IVAG is organized in three main modules: the Diagram Editor, the Layout Composer and the Code Editor. In the following, to exemplify the description of these modules, we will refer to the ‘‘Visual Medical Diagnostician’’, an IVAG-generated graphical application for the diagnosis of exhantematic diseases in children, whose specification has been taken from [1]. The application requirements are as follows: A non-expert user (for example one of the parents of the child) interacts with a graphical interface where he/she can visually indicate the disease symptoms. Then, the system may ask the user additional questions if they are needed to express a diagnosis. A running session of the application is shown in the appendix. For this application IVAG compiles the specification in C++ code for the Microsoft Visual C++t compiler on the Windowst platform. 2.1. The Diagram Editor The Diagram Editor allows the user to visually specify the application. It is composed of a working area and two docking toolbars. Fig. 1 shows the Diagram Editor in the IVAG main interface with the Visual Medical Diagnostician state-transition diagram. In the working area the IVAG programmer can use common graphical facilities to draw the state-transition diagram which models the overall organization of the application. For example, in Fig. 2B the programmer places a new node in the diagram, after having selected the appropriate tool from the main toolbar (see Fig. 2A). The nodes of the diagram correspond to the states of the application, whereas each transition corresponds to a particular process of the application. Using the property toolbar the user can give semantics to the diagram by assigning appropriate properties to the nodes and transitions. The user selects a node or transition directly from the diagram, and then he/she can modify its properties through an appropriate property toolbar, which is organized similarly to the property editor of typical visual programming environments such as Visual Basict (see Fig. 2C). In the following, we give a brief description of the node and transition properties: 2.1.1. Node properties *
*
The user assigns a proper name to each node, automatically displayed in the diagram. Among the nodes, he/she must define the initial node (corresponding to the starting configuration of the application) and the set of final nodes (corresponding to the states where the execution of the application terminates).
ARTICLE IN PRESS 442
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 1. The IVAG main interface.
Fig. 2. Steps for drawing a state-transition diagram in the IVAG Diagram Editor.
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461 *
443
The user may associate a specific basic layout name with a node. A basic layout contains a set of characterizing basic components specifying the visual configuration of the graphical interface of the application. A transition between two nodes with different basic layouts expresses a major change in the application interface. Transitions are a high level view of these changes, and do not show the overall computation that generates them.
2.1.2. Transition properties *
*
*
*
*
*
The user assigns a proper name to each transition, displayed as the transition label in the diagram. The transitions can be defined as user or system. A user transition is the abstraction of a process concerning the interaction between the user and the active part (e.g. a button) of the user interface. A system transition is the abstraction of a process corresponding to a procedure call. The programmer writes these procedures using the Code Editor of IVAG. The user assigns the name of the procedure implementing the corresponding process to each transition. User transitions can be specified as pixel or non-pixel. These correspond to two different modalities of interaction with the user interface. In pixel mode, an event acts only on the particular point that has been selected by the user, whereas if the modality is non-pixel it acts on the whole area containing that point. Once the programmer has specified a user transition as pixel or non-pixel, he/she must also define the coordinates of the point or the area, respectively, on which the event can act. Finally, the user assigns a measure to each transition, indicating the computational overhead of the underlying procedure: STRONG, if the overhead overcomes a predefined bound, WEAK otherwise. This measure can be used to show a different view of the diagram, where only the most meaningful (i.e. strong) transitions are displayed (see Fig. 3). Note that the strong transitions are drawn in the diagram with thicker lines.
2.2. The Layout Composer The Layout Composer enables users to specify the layouts of graphical applications. According to the structure shown in Fig. 4, each layout is composed of a basic scenario and of support structures. The scenario represents the working area of the application, which is divided into active areas and static areas. The active areas are those where the user can interact with the graphical interface of the application, while the static areas only contribute to form the graphics of the layout. The support structures contain the primitive graphical objects of the application and typical graphical facilities like windows, menus, dialog boxes and toolbars. As an example, the interface for the Visual Medical Diagnostician application has a human body layout as the basic scenario. The primitive graphical objects are icons
ARTICLE IN PRESS 444
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 3. A different view of the diagram in Fig. 1.
Fig. 4. The structure of the visual layout.
that visually represent some common symptoms. Transitions are activated by user events like the insertion of a new symptom or the answer to a dialog box asking for more information, and by system events corresponding to procedure calls verifying
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
445
Fig. 5. The Layout Composer in the IVAG main interface.
the recognition of a particular disease by querying the knowledge base of the application. Through the Layout Composer (see Fig. 5 for a sequence of interactions in the Layout Composer interface) a user can define the graphical objects of both the scenario and the support structures of the layouts. Then, he/she can use the property box at the bottom-left corner of the window to set the object properties. The Layout Composer also shows a preview of the visual layout appearance.
2.3. The Code Editor The Code Editor allows the user to write program fragments. This code will be embedded in the final application and can be of two types: testing functions and event handlers. Testing functions are code fragments that determine if a system transition can be fired, whereas event handlers are procedures implementing the processes associated to the transitions. For example, Fig. 6 shows the Code Editor window where the user is writing code for the OnFire event of the Choose Symbol Pain transition, and Fig. 7 shows the global declarations for the entire application. The user can select an object (node or transition) and a particular event associated with it. If such object is a system transition, the user may also select the corresponding testing function. Then, the user edits the C++ code implementing the selected event (or testing function).
ARTICLE IN PRESS 446
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 6. The Code Editor window in the IVAG main interface.
Fig. 7. The Code Editor showing Global Declarations.
In this phase, all the API of the underlying operating system are available to the programmer. Moreover, he/she can manipulate all the objects defined in each application layout through the Layout Composer. For example, he/she may update a property of a particular object, or call one of its methods. This is possible thanks to the object model underlying the IVAG generated code (see Section 3).
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
447
The programmer can use the Code Editor also to write general procedures in order to create a library to support the application implementation. Moreover, the programmer can write a set of #include directives to import the interface of external libraries (useful to reuse very complex procedures) that he/she will manually link to the final application. Once the programmer has completed the application specification through the software modules described above, he/she selects the compile button on the IVAG toolbar to integrate the various parts of the software specification and generate the final C++ code. This code is then passed to a standard C++ compiler for Windowst in order to produce the final application. Moreover, part of the specification of the implemented application can be saved as a template. A template contains the state-transition diagram and a set of pre-built graphical objects and facilities, active areas and static areas, and can be reused to start the implementation of other applications. Each template characterizes a specific class of applications. When it is loaded, the Diagram Editor and the Layout Composer of IVAG are configured to support the creation and the manipulation of the components for that kind of application. We introduced the notion of template to improve reusability and productivity in the development of small/medium software projects.
3. The generated code and documentation In this section we give some details on the generation of code and documentation through the use of the tool IVAG. 3.1. Code generation The overall organization of the IVAG application object model is shown in Fig. 8. There is a strict correspondence between the state-transition diagram components and the classes used in the object model. This makes the generated code highly modular, reusable and easily maintainable. The application code is divided in several files, corresponding to the output of the three IVAG modules: 1. The files AppName States.cpp, AppName Transitions.ccp and the corresponding header files contain a set of state classes and transition classes implementing the state-transition diagram input; 2. The file AppName Layouts.cpp and its header contain the definition of the layouts designed using the IVAG Layout Composer; 3. Finally, the file AppName Globals.cpp and its header contain the global code and declarations written with the IVAG Code Editor, while the other code entered using this module is embedded into the corresponding methods of states and transitions (e.g. the OnFire code is embedded in the OnFire method of the corresponding state).
ARTICLE IN PRESS 448
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 8. The IVAG application object model.
To build the final application, the user compiles and links the above files with a set of library files that contain the common runtime for all the generated programs (and possibly also a set of external libraries needed by the program code). We remark that, since the event-driven logic and the interface manager of the application are embedded in the base classes, IVAG produces code with limited size avoiding useless duplications. The current version of IVAG uses C++ as the target language, however other object-oriented languages could be used as well. In fact, the IVAG-generated applications rely on the set of external library files implementing the object model described in Fig. 8. This library covers all the basic functionalities of a visual application, like for example the state transitions and the application visual layout. The structure of the object model, which basically exposes a set
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
449
of interfaces to be implemented, is clearly suitable to be rewritten in the most common object-oriented languages that support the development of graphical user interfaces, e.g. Java. To allow the programmer to write applications in other target languages, the most substantial reprogramming work just consists in the rewriting of such external libraries. Indeed, the part of the code automatically generated by IVAG for a specific application is a simple object-oriented skeleton that is independent of the implementation details of a specific language and has a behaviour completely based on these libraries. In order to make this skeleton consistent with a new target language, only little reprogramming work has to be done on the code underlying the compile button of the IVAG application. Of course, the programmer has to write the program fragments through the IVAG Code Editor in the new target language.
3.2. Documentation generation In addition to the generation of code, IVAG produces an extensive and flexible documentation for the applications that can be compiled in different target formats, e.g. hypertextual, printable manual, etc. Once the programmer has completed the application specification, he/she can select the Write XML Documentation button on the IVAG main toolbar in order to produce an XML description of the entire application, written using an appropriate XML DTD (Document Type Description), [8]. Then, the XML file can be transformed into the final target format using a Extensible Stylesheet Language Transformations (XSLT) document [9]. In this way, the user can design personal documentation formats according to his/her specific needs. To support this functionality, the current version of IVAG has been provided with a sample XSLT document that generates a hypertextual description of the application. This documentation contains a short textual description of the application structure and a list of all the states, transitions and layouts with their properties. As an example, Figs. 9 and 10 show an extract of the hypertext generated for the Visual Medical Diagnostician application. The documentation can be browsed using a standard web browser. From each state, the user can move to the description of the corresponding basic layout or to that of all the outgoing transitions. For each transition, the user can read its firing conditions, move to the description of the specific object that activates it (see Fig. 10), and reach the new states (see Fig. 9). In this way, the hypertext can be used to trace an execution of the application and to debug it. Actually, the generated documentation can be viewed as a re-formatting of the application object model using XML/XSLT technologies. This kind of documentation results to be very helpful in all the software development process, and in particular it supports the maintenance during the evolution of the software project.
ARTICLE IN PRESS 450
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 9. Browsing through the Visual Medical Diagnostician documentation.
Fig. 10. Jumping from a transition to its object and expanding the firing code.
4. IVAG and web-based applications Web-based applications are a prototypical example of open, distributed, networked systems and are hard to manage without a structured approach. On the other hand, web-based applications are typical candidates for using graphical languages and applications as front-ends. For these reasons, IVAG is very suitable to be applied in this field, and we are currently experimenting the tool to design and build such kind of applications. In this section we present WapNews, a Web/WAP prototype application for the dynamic filtering and delivery of news through a web interface. Fig. 11 shows the
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
451
state-transition diagram for the application, whereas Fig. 12 shows the same diagram during the application definition in the IVAG Diagram Editor. To implement the WapNews application the Code Editor and the Layout Composer modules have been enhanced in order to allow the insertion of scripts in JavaScript language (see Fig. 13) and the editing of HTML pages, respectively. In this way, the final result produced by IVAG is a set of HTML pages with embedded JavaScript code, forming the client-side of the application. Of course, an adequate support from the server-side (e.g. DBMS, authentication procedures, etc.) is expected to handle the specific features of particular applications. The application allows the user to receive and read a selected list of news updated in real time and filtered according to the user profile. An interesting feature of this application is that the user preferences do not have to be set through the usual configuration interfaces of the web news services (where usually the user must specify its interests by choosing from a number of predefined categories and/or giving a set of keywords), but are regularly updated by observing what actions the user performs on the proposed articles. Different actions have different update weights, and the user profile is updated according to the keywords present in the articles by the weight associated to the action taken (i.e. read, read all, forward...). The service is divided on several pages: 1. First, the user must log in by writing his/her username and the password assigned by the service provider in the login page.
Fig. 11. The diagram for the WapNews application.
ARTICLE IN PRESS 452
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 12. The WapNews diagram in the IVAG Diagram Editor.
Fig. 13. The Code Editor showing JavaScript code for a transition.
2. After logging in, the starting page presents the user with a list of news headers. The headers contain the news titles and possibly a short summary, if available. This allows the user to choose which news to expand, avoids to transfer a large amount of possibly undesired text, and is particularly useful whenever the web
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
453
interface is accessed e.g. through a WAP device with small capabilities and bandwidth. The actions that can be taken from this layout are the following: The user can request a refresh of the news list (that is supposed to be updated on the server in real time). The user can page through the news headers, when these are presented in a multi-page layout (particularly on WAP or PDA devices). The user can access a keyword input page. From this page he/she can manually enter keywords concerning his/her areas of interest that will be added to those automatically deduced by the server. This function allows an expert user to quickly change its preferences without waiting for the server to adapt them automatically. The user can choose a news to read. 3. When the user selects a news, it is presented with the read page layout. The selected article (or its first page) is loaded and displayed. The server receives a feedback on the selected article, and uses the article keywords to update the user profile. The read action has a low update weight. From the read layout the user can take many actions: The user can scroll or page (depending on the page layout) through the news. Scrolling sends feedback to the server, since it means that the user is actually reading the article. If the user reaches the last page/line of the article, a more significant feedback is sent to the server. Moreover, a countdown timer is embedded in the page, starting from a number of seconds estimated from the length of the article. If the timer reaches zero, another feedback is sent to the server, telling that the user ‘‘viewed’’ the article for an amount of time that is enough to deduce that he/she is really interested in it. The user can forward the article to another user that is subscribed to the service, in which case the profiles of both users are updated, or simply send the header via SMS to the cellular phone of another person. Finally, an expert user can access an explicit rating page where he/she can manually express his/her interest in the article by choosing from a set of predefined values. From the read layout it is possible to return to the starting layout to select another news to read, etc.
5. System usability In this section we report the results of some experiments on using IVAG in real settings. Besides the Web prototype application discussed in Section 4, we have used our tool to generate graphical applications with layout templates ‘‘Chessboard’’ and ‘‘Human body’’ (like the ‘‘Visual Medical Diagnostician’’ application in the Appendix) and we reused these templates to obtain several variants of the starting applications. From this experimentation it results that IVAG significantly reduces
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
454
time and effort for application development and documentation. As an example, in our prototype case study, we constructed the WapNews application in 3 days with a minimal amount of code to be written manually (200 lines of Javascript code), that is about 60% of the generated final application code. It is worth noting that this application was already implemented in a traditional approach (with the use of Frontpaget to create the layouts and manually embedding the Javascript code), taking 4 days. Also for the other applications of small/medium code size tested, we observed that the IVAG programmer writes an amount of code that is still about 60% of the generated final application code, and saves about 70% of the time required to develop the application in a traditional way. Since the development of the other generation steps (application logic specification, interface design, etc.) is comparable to that of traditional programming environments, it follows that IVAG allows a substantial time saving in the overall application development process. Note that IVAG guarantees the correctness of the part of code automatically generated that results to be bug-free and full-featured, whileas the program fragments manually written by the programmer through the Code Editor may be normally debugged. Moreover, we performed several tests, both in academic and industrial context, involving groups of computer science students and managers and technicians belonging to industries. As an example, in the latter case IVAG was used to obtain rapid prototypes of specific components or parts of software projects specified through the SDML (Scenario Description Markup Language) language [10], which is an XML-based formalism that supports scenario based software specification. An industrial team of programmers and web developers was asked to use IVAG to develop a prototype of some relevant functionalities of the ItalGiureWeb application, which is a legal document retrieval system relying on a complex web interface. In the following, we report some findings: *
*
*
The underlying methodology of IVAG was judged useful, because the programmers were able to design a small state-transition diagram describing the required functionalities. All the team members became confident with the IVAG system after an initial trial session. Only 15% of the participants had some difficulties learning the underlying Visual Automaton formalism. It took an average time of 6 h to the participants to complete the prototype.
The team members were requested to fill in a questionnaire about the difficulties they found using IVAG. Each question required to indicate a difficulty level for each phase of the IVAG development process, according to the following schema: Level Level Level Level
1: 2: 3: 4:
Easy. Moderately difficult. Difficult. Very difficult.
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
455
A small percentage of the participants found Moderately difficult using the Code Editor, whileas the remaining members indicated Easy. The development of the Visual Automaton was Moderately difficult or Difficult for about 20% of the members, and all the participants were able to easily design the interfaces through IVAG. Moreover, about 45% of the programmers suggested precise applications of IVAG to other domains. Note that this team of programmers already implemented the same prototype with their conventional methodology, which includes tools like C++ and Visual Basict. Again, it was possible to note a substantial time saving in the IVAG reimplementation.
6. Related work State transition machines have been extensively used in the past for the definition of general graphical interfaces. Starting from the pioneer work of Jacob [5], the idea of using state machines to specify user interfaces was heavily explored for at least 10 years [11–14], and finally it seems to have failed in that scope because of the difficulty of handling the demands of direct manipulation interfaces. However, in [1] we have shown that the state-transition model is valid and effective when applied to rapid application development of visual applications. In Section 5, we have also given some experimental results that confirm the practical effectiveness of our approach. The ‘‘event-driven machine’’ notion is also included in some recent well-known modelling languages like UML [15]. However, such formalisms aim at the design of large-scale software projects, while the target of our approach are small/medium RAD applications. Generally speaking, RAD applications are characterized by the following issues: * * * *
Small or medium code size. Wide use of pre-existing components in the code assembling. Low formal level of specifications. Short release time.
The programmers of such applications usually write programs from scratch, rather than reusing existing code. As a consequence, whenever these applications have to be modified or augmented, this cannot be accomplished without substantial reprogramming. Generic RAD visual applications are usually produced using visual programming environments like Visual Basict, Visual Studiot or JBuildert. These environments could look like IVAG since they are composed of code editors and layout editors, too. However, unlike IVAG, these are general-purpose programming environments that lack a formal support methodology. In general, a programmer of such environments implements an application according to the development style issues above, in an ad hoc fashion and with intensive use of ‘‘cut & paste’’ operations. Moreover, although the programmer often designs an application using
ARTICLE IN PRESS 456
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
a well-organized event-driven logic, this organization is lost in the final ad hoc implementation. Several specific tools for rapid application development have been proposed in the recent literature. Among the others, the software design environment APICES, [16], suitable for the prototyping and rapid development of applications using network-like data structures, which are typical for CAD tools, and the framework-based tool INTRAD, [17], for developing intranet applications, where programmers can develop applications very easily by reusing not only source code but also design information. As opposite to most RAD tools of this kind where fast delivery often results in poor or even missing documentation, IVAG also produces an appropriate documentation of the generated code providing a sound platform for maintenance and further development. Moreover, thanks to its underlying rigorous methodology, IVAG does not skip the design phase and makes the underlying state-transition model available in a suitable format. The idea of using state-transition diagrams is also present in some commercial tools, like for example AnyStatest, [18]. However, what makes IVAG different from these tools is its methodologic counterpart. In fact, the development methodology of IVAG starts when it is possible to capture a precise and limited number of abstractions on the application domain. This happens, for example, when some components can be handled in a way substantially independent of the rest of the system. For instance, the formalism underlying IVAG contains a particular component (i.e. the visual layout, [1]) to abstract specific configurations of the user interface. Thanks to this methodology that directly embeds the abstraction idea in the underlying formalism, the state machines produced by applying our approach result to be of limited size and, therefore, can be easily manipulated. As a further benefit, any modification to the final application can be first designed using the statetransition diagram and then easily reported on the code by IVAG. This would be difficult to do with tools that are based on a general state machine model notion. In fact, in this case even small applications may produce state explosion resulting in complex automata that are hard to manipulate.
7. Conclusions In this paper we have presented a support environment for the design and the implementation of visual applications, namely the Interactive Visual Application code Generator (IVAG) system. The starting idea of the present research was to define a lightweight software development methodology based on a state-transition model avoiding the typical state explosion problem. We are confident that the current version of IVAG represents a good step towards this aim. In the Section ‘‘Related Work’’ we surveyed a number of related tools, remarking some advantages provided by the use of IVAG. In this discussion we do not mean that IVAG is more or less performing than these tools. Actually, the point is the particular application context that makes an approach more convenient respect to others. At present, we are encouraged by the experimental results and we feel that IVAG is suitable when
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
457
the application domain consists of particular classes of visual applications, i.e. small/ medium sized RAD applications where a few components can be abstracted from the application domain and handled separately. We have widely experimented our approach by applying IVAG on a variety of case studies. This experimentation shows that IVAG offers a good compromise between rapid development, typical of RAD environments, and reusability, typical of object-oriented environments [19,20]. Moreover, software developers using our kind of model-based generative programming can also profit during the evolution of a software project. In fact, changes required, e.g. in the structure of the statetransition diagram of the application, which are not known at the beginning of the project, simply result in the automatic re-generation of large parts of the application. Further research includes the characterization of a set of templates suitable for other classes of practical applications, for example Multimedia- or Database-based ones. For these applications, the concept of Basic Layout should be extended to a Basic Configuration notion, defined as a set of characterizing components for the specific kind of application. For example, a Basic Configuration in a DB-based application may include the database states characterized by a set of rules that could be expressed using SQL queries. To embed this notion in IVAG, the tool interfaces and modules will have to be adapted accordingly.
Appendix In the following, we present a running session of the Visual Medical Diagnostician application showing a sequence of interactions with an end-user to obtain a diagnosis.
Fig. 14. VMD running session, step 1.
ARTICLE IN PRESS 458
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 15. VMD running session, step 2.
Fig. 16. VMD running session, step 3.
Step 1 (Fig. 14): The user gives the average temperature of the child selecting one of the three ranges provided by the interface. The selection is done with a mark. Since the child has not been vomiting or having convulsions, the corresponding checkboxes remain unmarked. Step 2 (Fig. 15): The user starts to input the symptoms shown by the child. First, he/she selects one of the five symptoms graphically represented by the icons at the
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
459
Fig. 17. VMD running session, step 4.
Fig. 18. VMD running session, step 5.
top of the interface, in this case the icon ‘‘Spots’’. The symptom icon is marked, indicating that the user now has to place that icon on the child image. Step 3 (Fig. 16): The user has clicked on an area of the child image, and the ‘‘Spots’’ icon has been automatically placed there. In this way, the user has specified that the child shows spots on the forehead. Step 4 (Fig. 17): The user has terminated the visual insertion of symptoms. He/she has specified that the child has spots and reddening on the forehead, and eye
ARTICLE IN PRESS 460
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 19. VMD running session, step 6.
inflammation. The average temperature is between 38 C and 40 C. Next, the user clicks the ‘‘Verify disease’’ button to ask the program which disease is characterized by these symptoms. Step 5 (Fig. 18): The system does not have all the elements needed to give a diagnosis, so it asks the user for additional information. Here, the user is asked to verify if the child has still rhinitis or conjunctivitis. The answer is ‘‘no’’. Step 6 (Fig. 19): Finally, after the user has answered the additional questions, the system gives the diagnosis: ‘‘the child has measles’’.
References [1] G. Della Penna, B. Intrigila, S. Orefice, Generating graphical applications from state-transition visual specifications, International Journal of Human Computer Studies 55 (2001) 861–880. [2] IEEE Computer. Special issue on visual programming, IEEE Computer 20 (1995) 14–16. [3] WWW-VISUAL. WWW Virtual Library: Visual Languages and Visual Programming, http:// cui.unige.ch/Visual. [4] K. Marriott, B. Mayer, Visual Language Theory, Springer, Berlin, 1998. [5] J.K. Jacob, A state transition diagram language for visual programming, IEEE Computer 18 (1985) 51–59. [6] J. Martin, Rapid Application Development, Macmillan Publishing Company, New York, 1991. [7] K. Rapley, RAD or TRAD or both? The future of software development, IEEE Colloquium on Rapid Application Development, 1998. [8] WWW-XML. Extensible Markup Language, http://www.w3.org/XML/. [9] WWW-XSL. eXtensible Stylesheet Language, http://www.w3.org/Style/XSL/. [10] G. Della Penna, B. Intrigila, A.R. Laurenzi, S. Orefice, An XML definition language to support scenario-based requirements engineering, International Journal of Software Engineering and Knowledge Engineering 13 (2003) 237–256.
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
461
[11] M. Green, A survey of three dialog models, ACM Transactions on Graphics 5 (1986) 244–317. [12] N. Green, G. Singh, Automating the lexical and syntactic design of graphical user interfaces: the UofA UIMS, ACM Transactions on Graphics 10 (1991) 213–254. [13] J.K. Jacob, A specification language for direct manipulation interfaces, ACM Transactions on Graphics 5 (1986) 283–317. [14] B.A. Myers, A new model for handling input, ACM Transactions on Information Systems 8 (1990) 289–320. [15] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, AddisonWesley, Reading, MA, 1998. [16] A. Bredenfeld, APICES—rapid application development with graph pattern, Ninth International Workshop on Rapid System Prototyping, 1998, pp. 25–30. [17] H.-T. Jung, D.-K. Kim, Y.-J. Yang, S.-D. Lee, A design and implementation of object-oriented framework-based RAD tool (INTRAD), 2000 IEEE International Conference on Systems, Man and Cybernetics, Vol. 3, 2000, pp. 2057–2061. [18] XJ Technologies. AnyStates, http://www.xjtek.com/products/anystates/. [19] G. Booch, Object-Oriented Design with Applications, Benjamin/Cummings, Redwood City, CA, 1994. [20] M. Burnett, A. Goldberg, T. Lewis, Visual Object-Oriented Programming: Concepts and Environments, Prentice-Hall, New York, 1995.
Journal of Visual Languages and Computing 15 (2004) 439–461
Journal of Visual Languages & Computing www.elsevier.com/locate/jvlc
An environment for the design and implementation of visual applications Giuseppe Della Penna, Benedetto Intrigila, Sergio Orefice Dipartimento di Informatica, Universita" di L’Aquila,Via Vetoio, Copito, I-67100 L’Aquila, Italy Received 7 October 2002; received in revised form 27 May 2003; accepted 30 March 2004
Abstract In this paper we present Interactive Visual Application code Generator (IVAG), a tool for the automatic generation of the code and the documentation of software applications. It is specifically tailored to support prototyping and rapid development of visual applications, where the user interface is a relevant part of the application. IVAG is currently being experimented on a variety of case studies, in particular web-based applications. r 2004 Elsevier Ltd. All rights reserved.
1. Introduction Visual programming has become a key component of multimodal communication and human–computer interaction and seems likely to gain even more importance in the future, [2,3]. For example, the explosive growth of visual communication on the World Wide Web is an indicator of the increasing use of visual languages and visual applications. In the past years, much research has been done in the theory of visual languages, [3,4], in order to give a systematic approach to their specification, analysis and implementation. On the contrary, no common methodology for handling general visual applications has emerged. Usually, programmers implement graphical applications in an ad hoc way by applying a general-purpose visual programming environment like Microsoft Visual Basict. As a consequence, whenever E-mail addresses: [email protected] (G. Della Penna), [email protected] (B. Intrigila), orefi[email protected] (S. Orefice). 1045-926X/$ - see front matter r 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.jvlc.2004.03.002
ARTICLE IN PRESS 440
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
an application has to be modified or augmented, this cannot be accomplished without substantial reprogramming. To this need, we have developed an environment for the design and the implementation of visual applications, namely the Interactive Visual Application code Generator (IVAG). IVAG is provided with a graphical front-end where the application requirements can be specified through state-transition diagrams describing the user interface and the behaviour of the application. These diagrams are directly compilable within the system that automatically generates the code of the application. The underlying formalism of IVAG is the Visual Automaton, a statemachine model for the specification of visual applications that we presented in [1] together with an early prototype of the system. The Visual Automaton extends the state-machine model first introduced in [5] for specifying user interfaces and applies it to the rapid development of visual applications. In this paper we discuss the architectural design of the advanced version of IVAG in detail and its new features and applications. The key characteristics of IVAG are the following: *
*
*
The generated code is highly modular, reusable, and preserves the logical organization of the application. The user interface portion is separated from the rest of the application, so that it can be easily updated without requiring reprogramming other parts of the application. IVAG supports the rapid development of small/medium code size applications.
Moreover, as opposed to most Rapid Application Development (RAD) tools [6,7] where fast delivery often results in poor or even missing documentation, IVAG also produces an appropriate documentation of the generated code, providing a sound platform for maintenance and further development. The paper is organized as follows. In Section 2, we illustrate the architecture of the IVAG system and its main software modules. Section 3 describes the structure of the code and of the documentation generated by IVAG. A prototype case study, the Web/WAP-based application WapNews, is presented in Section 4. Then, in Section 5 we discuss the practical applicability of the IVAG approach and report some experiments of usage in real settings. Related work is summarized in Section 6, where we compare IVAG with other similar tools. To conclude, some final remarks are outlined in Section 7.
2. The software architecture of IVAG In this section we describe the visual programming environment IVAG. The tool is provided with a graphical front-end that enables the user to specify an application through a state-transition diagram; this diagram describes the application interface and its behaviour. Then, IVAG automatically generates the code for the final program and a proper documentation. The theoretical aspects of the formalism
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
441
underlying the state-transition diagram specifications used in our methodology (i.e. the Visual Automaton) have been presented in [1]; however, the main features of the formalism are recalled in this section, thus making the present paper self-contained. IVAG has been developed using the Microsoftt Visual C++t language and runs on PCs under the Microsoftt Windowst operating system. The software architecture of IVAG is organized in three main modules: the Diagram Editor, the Layout Composer and the Code Editor. In the following, to exemplify the description of these modules, we will refer to the ‘‘Visual Medical Diagnostician’’, an IVAG-generated graphical application for the diagnosis of exhantematic diseases in children, whose specification has been taken from [1]. The application requirements are as follows: A non-expert user (for example one of the parents of the child) interacts with a graphical interface where he/she can visually indicate the disease symptoms. Then, the system may ask the user additional questions if they are needed to express a diagnosis. A running session of the application is shown in the appendix. For this application IVAG compiles the specification in C++ code for the Microsoft Visual C++t compiler on the Windowst platform. 2.1. The Diagram Editor The Diagram Editor allows the user to visually specify the application. It is composed of a working area and two docking toolbars. Fig. 1 shows the Diagram Editor in the IVAG main interface with the Visual Medical Diagnostician state-transition diagram. In the working area the IVAG programmer can use common graphical facilities to draw the state-transition diagram which models the overall organization of the application. For example, in Fig. 2B the programmer places a new node in the diagram, after having selected the appropriate tool from the main toolbar (see Fig. 2A). The nodes of the diagram correspond to the states of the application, whereas each transition corresponds to a particular process of the application. Using the property toolbar the user can give semantics to the diagram by assigning appropriate properties to the nodes and transitions. The user selects a node or transition directly from the diagram, and then he/she can modify its properties through an appropriate property toolbar, which is organized similarly to the property editor of typical visual programming environments such as Visual Basict (see Fig. 2C). In the following, we give a brief description of the node and transition properties: 2.1.1. Node properties *
*
The user assigns a proper name to each node, automatically displayed in the diagram. Among the nodes, he/she must define the initial node (corresponding to the starting configuration of the application) and the set of final nodes (corresponding to the states where the execution of the application terminates).
ARTICLE IN PRESS 442
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 1. The IVAG main interface.
Fig. 2. Steps for drawing a state-transition diagram in the IVAG Diagram Editor.
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461 *
443
The user may associate a specific basic layout name with a node. A basic layout contains a set of characterizing basic components specifying the visual configuration of the graphical interface of the application. A transition between two nodes with different basic layouts expresses a major change in the application interface. Transitions are a high level view of these changes, and do not show the overall computation that generates them.
2.1.2. Transition properties *
*
*
*
*
*
The user assigns a proper name to each transition, displayed as the transition label in the diagram. The transitions can be defined as user or system. A user transition is the abstraction of a process concerning the interaction between the user and the active part (e.g. a button) of the user interface. A system transition is the abstraction of a process corresponding to a procedure call. The programmer writes these procedures using the Code Editor of IVAG. The user assigns the name of the procedure implementing the corresponding process to each transition. User transitions can be specified as pixel or non-pixel. These correspond to two different modalities of interaction with the user interface. In pixel mode, an event acts only on the particular point that has been selected by the user, whereas if the modality is non-pixel it acts on the whole area containing that point. Once the programmer has specified a user transition as pixel or non-pixel, he/she must also define the coordinates of the point or the area, respectively, on which the event can act. Finally, the user assigns a measure to each transition, indicating the computational overhead of the underlying procedure: STRONG, if the overhead overcomes a predefined bound, WEAK otherwise. This measure can be used to show a different view of the diagram, where only the most meaningful (i.e. strong) transitions are displayed (see Fig. 3). Note that the strong transitions are drawn in the diagram with thicker lines.
2.2. The Layout Composer The Layout Composer enables users to specify the layouts of graphical applications. According to the structure shown in Fig. 4, each layout is composed of a basic scenario and of support structures. The scenario represents the working area of the application, which is divided into active areas and static areas. The active areas are those where the user can interact with the graphical interface of the application, while the static areas only contribute to form the graphics of the layout. The support structures contain the primitive graphical objects of the application and typical graphical facilities like windows, menus, dialog boxes and toolbars. As an example, the interface for the Visual Medical Diagnostician application has a human body layout as the basic scenario. The primitive graphical objects are icons
ARTICLE IN PRESS 444
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 3. A different view of the diagram in Fig. 1.
Fig. 4. The structure of the visual layout.
that visually represent some common symptoms. Transitions are activated by user events like the insertion of a new symptom or the answer to a dialog box asking for more information, and by system events corresponding to procedure calls verifying
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
445
Fig. 5. The Layout Composer in the IVAG main interface.
the recognition of a particular disease by querying the knowledge base of the application. Through the Layout Composer (see Fig. 5 for a sequence of interactions in the Layout Composer interface) a user can define the graphical objects of both the scenario and the support structures of the layouts. Then, he/she can use the property box at the bottom-left corner of the window to set the object properties. The Layout Composer also shows a preview of the visual layout appearance.
2.3. The Code Editor The Code Editor allows the user to write program fragments. This code will be embedded in the final application and can be of two types: testing functions and event handlers. Testing functions are code fragments that determine if a system transition can be fired, whereas event handlers are procedures implementing the processes associated to the transitions. For example, Fig. 6 shows the Code Editor window where the user is writing code for the OnFire event of the Choose Symbol Pain transition, and Fig. 7 shows the global declarations for the entire application. The user can select an object (node or transition) and a particular event associated with it. If such object is a system transition, the user may also select the corresponding testing function. Then, the user edits the C++ code implementing the selected event (or testing function).
ARTICLE IN PRESS 446
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 6. The Code Editor window in the IVAG main interface.
Fig. 7. The Code Editor showing Global Declarations.
In this phase, all the API of the underlying operating system are available to the programmer. Moreover, he/she can manipulate all the objects defined in each application layout through the Layout Composer. For example, he/she may update a property of a particular object, or call one of its methods. This is possible thanks to the object model underlying the IVAG generated code (see Section 3).
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
447
The programmer can use the Code Editor also to write general procedures in order to create a library to support the application implementation. Moreover, the programmer can write a set of #include directives to import the interface of external libraries (useful to reuse very complex procedures) that he/she will manually link to the final application. Once the programmer has completed the application specification through the software modules described above, he/she selects the compile button on the IVAG toolbar to integrate the various parts of the software specification and generate the final C++ code. This code is then passed to a standard C++ compiler for Windowst in order to produce the final application. Moreover, part of the specification of the implemented application can be saved as a template. A template contains the state-transition diagram and a set of pre-built graphical objects and facilities, active areas and static areas, and can be reused to start the implementation of other applications. Each template characterizes a specific class of applications. When it is loaded, the Diagram Editor and the Layout Composer of IVAG are configured to support the creation and the manipulation of the components for that kind of application. We introduced the notion of template to improve reusability and productivity in the development of small/medium software projects.
3. The generated code and documentation In this section we give some details on the generation of code and documentation through the use of the tool IVAG. 3.1. Code generation The overall organization of the IVAG application object model is shown in Fig. 8. There is a strict correspondence between the state-transition diagram components and the classes used in the object model. This makes the generated code highly modular, reusable and easily maintainable. The application code is divided in several files, corresponding to the output of the three IVAG modules: 1. The files AppName States.cpp, AppName Transitions.ccp and the corresponding header files contain a set of state classes and transition classes implementing the state-transition diagram input; 2. The file AppName Layouts.cpp and its header contain the definition of the layouts designed using the IVAG Layout Composer; 3. Finally, the file AppName Globals.cpp and its header contain the global code and declarations written with the IVAG Code Editor, while the other code entered using this module is embedded into the corresponding methods of states and transitions (e.g. the OnFire code is embedded in the OnFire method of the corresponding state).
ARTICLE IN PRESS 448
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 8. The IVAG application object model.
To build the final application, the user compiles and links the above files with a set of library files that contain the common runtime for all the generated programs (and possibly also a set of external libraries needed by the program code). We remark that, since the event-driven logic and the interface manager of the application are embedded in the base classes, IVAG produces code with limited size avoiding useless duplications. The current version of IVAG uses C++ as the target language, however other object-oriented languages could be used as well. In fact, the IVAG-generated applications rely on the set of external library files implementing the object model described in Fig. 8. This library covers all the basic functionalities of a visual application, like for example the state transitions and the application visual layout. The structure of the object model, which basically exposes a set
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
449
of interfaces to be implemented, is clearly suitable to be rewritten in the most common object-oriented languages that support the development of graphical user interfaces, e.g. Java. To allow the programmer to write applications in other target languages, the most substantial reprogramming work just consists in the rewriting of such external libraries. Indeed, the part of the code automatically generated by IVAG for a specific application is a simple object-oriented skeleton that is independent of the implementation details of a specific language and has a behaviour completely based on these libraries. In order to make this skeleton consistent with a new target language, only little reprogramming work has to be done on the code underlying the compile button of the IVAG application. Of course, the programmer has to write the program fragments through the IVAG Code Editor in the new target language.
3.2. Documentation generation In addition to the generation of code, IVAG produces an extensive and flexible documentation for the applications that can be compiled in different target formats, e.g. hypertextual, printable manual, etc. Once the programmer has completed the application specification, he/she can select the Write XML Documentation button on the IVAG main toolbar in order to produce an XML description of the entire application, written using an appropriate XML DTD (Document Type Description), [8]. Then, the XML file can be transformed into the final target format using a Extensible Stylesheet Language Transformations (XSLT) document [9]. In this way, the user can design personal documentation formats according to his/her specific needs. To support this functionality, the current version of IVAG has been provided with a sample XSLT document that generates a hypertextual description of the application. This documentation contains a short textual description of the application structure and a list of all the states, transitions and layouts with their properties. As an example, Figs. 9 and 10 show an extract of the hypertext generated for the Visual Medical Diagnostician application. The documentation can be browsed using a standard web browser. From each state, the user can move to the description of the corresponding basic layout or to that of all the outgoing transitions. For each transition, the user can read its firing conditions, move to the description of the specific object that activates it (see Fig. 10), and reach the new states (see Fig. 9). In this way, the hypertext can be used to trace an execution of the application and to debug it. Actually, the generated documentation can be viewed as a re-formatting of the application object model using XML/XSLT technologies. This kind of documentation results to be very helpful in all the software development process, and in particular it supports the maintenance during the evolution of the software project.
ARTICLE IN PRESS 450
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 9. Browsing through the Visual Medical Diagnostician documentation.
Fig. 10. Jumping from a transition to its object and expanding the firing code.
4. IVAG and web-based applications Web-based applications are a prototypical example of open, distributed, networked systems and are hard to manage without a structured approach. On the other hand, web-based applications are typical candidates for using graphical languages and applications as front-ends. For these reasons, IVAG is very suitable to be applied in this field, and we are currently experimenting the tool to design and build such kind of applications. In this section we present WapNews, a Web/WAP prototype application for the dynamic filtering and delivery of news through a web interface. Fig. 11 shows the
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
451
state-transition diagram for the application, whereas Fig. 12 shows the same diagram during the application definition in the IVAG Diagram Editor. To implement the WapNews application the Code Editor and the Layout Composer modules have been enhanced in order to allow the insertion of scripts in JavaScript language (see Fig. 13) and the editing of HTML pages, respectively. In this way, the final result produced by IVAG is a set of HTML pages with embedded JavaScript code, forming the client-side of the application. Of course, an adequate support from the server-side (e.g. DBMS, authentication procedures, etc.) is expected to handle the specific features of particular applications. The application allows the user to receive and read a selected list of news updated in real time and filtered according to the user profile. An interesting feature of this application is that the user preferences do not have to be set through the usual configuration interfaces of the web news services (where usually the user must specify its interests by choosing from a number of predefined categories and/or giving a set of keywords), but are regularly updated by observing what actions the user performs on the proposed articles. Different actions have different update weights, and the user profile is updated according to the keywords present in the articles by the weight associated to the action taken (i.e. read, read all, forward...). The service is divided on several pages: 1. First, the user must log in by writing his/her username and the password assigned by the service provider in the login page.
Fig. 11. The diagram for the WapNews application.
ARTICLE IN PRESS 452
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 12. The WapNews diagram in the IVAG Diagram Editor.
Fig. 13. The Code Editor showing JavaScript code for a transition.
2. After logging in, the starting page presents the user with a list of news headers. The headers contain the news titles and possibly a short summary, if available. This allows the user to choose which news to expand, avoids to transfer a large amount of possibly undesired text, and is particularly useful whenever the web
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
453
interface is accessed e.g. through a WAP device with small capabilities and bandwidth. The actions that can be taken from this layout are the following: The user can request a refresh of the news list (that is supposed to be updated on the server in real time). The user can page through the news headers, when these are presented in a multi-page layout (particularly on WAP or PDA devices). The user can access a keyword input page. From this page he/she can manually enter keywords concerning his/her areas of interest that will be added to those automatically deduced by the server. This function allows an expert user to quickly change its preferences without waiting for the server to adapt them automatically. The user can choose a news to read. 3. When the user selects a news, it is presented with the read page layout. The selected article (or its first page) is loaded and displayed. The server receives a feedback on the selected article, and uses the article keywords to update the user profile. The read action has a low update weight. From the read layout the user can take many actions: The user can scroll or page (depending on the page layout) through the news. Scrolling sends feedback to the server, since it means that the user is actually reading the article. If the user reaches the last page/line of the article, a more significant feedback is sent to the server. Moreover, a countdown timer is embedded in the page, starting from a number of seconds estimated from the length of the article. If the timer reaches zero, another feedback is sent to the server, telling that the user ‘‘viewed’’ the article for an amount of time that is enough to deduce that he/she is really interested in it. The user can forward the article to another user that is subscribed to the service, in which case the profiles of both users are updated, or simply send the header via SMS to the cellular phone of another person. Finally, an expert user can access an explicit rating page where he/she can manually express his/her interest in the article by choosing from a set of predefined values. From the read layout it is possible to return to the starting layout to select another news to read, etc.
5. System usability In this section we report the results of some experiments on using IVAG in real settings. Besides the Web prototype application discussed in Section 4, we have used our tool to generate graphical applications with layout templates ‘‘Chessboard’’ and ‘‘Human body’’ (like the ‘‘Visual Medical Diagnostician’’ application in the Appendix) and we reused these templates to obtain several variants of the starting applications. From this experimentation it results that IVAG significantly reduces
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
454
time and effort for application development and documentation. As an example, in our prototype case study, we constructed the WapNews application in 3 days with a minimal amount of code to be written manually (200 lines of Javascript code), that is about 60% of the generated final application code. It is worth noting that this application was already implemented in a traditional approach (with the use of Frontpaget to create the layouts and manually embedding the Javascript code), taking 4 days. Also for the other applications of small/medium code size tested, we observed that the IVAG programmer writes an amount of code that is still about 60% of the generated final application code, and saves about 70% of the time required to develop the application in a traditional way. Since the development of the other generation steps (application logic specification, interface design, etc.) is comparable to that of traditional programming environments, it follows that IVAG allows a substantial time saving in the overall application development process. Note that IVAG guarantees the correctness of the part of code automatically generated that results to be bug-free and full-featured, whileas the program fragments manually written by the programmer through the Code Editor may be normally debugged. Moreover, we performed several tests, both in academic and industrial context, involving groups of computer science students and managers and technicians belonging to industries. As an example, in the latter case IVAG was used to obtain rapid prototypes of specific components or parts of software projects specified through the SDML (Scenario Description Markup Language) language [10], which is an XML-based formalism that supports scenario based software specification. An industrial team of programmers and web developers was asked to use IVAG to develop a prototype of some relevant functionalities of the ItalGiureWeb application, which is a legal document retrieval system relying on a complex web interface. In the following, we report some findings: *
*
*
The underlying methodology of IVAG was judged useful, because the programmers were able to design a small state-transition diagram describing the required functionalities. All the team members became confident with the IVAG system after an initial trial session. Only 15% of the participants had some difficulties learning the underlying Visual Automaton formalism. It took an average time of 6 h to the participants to complete the prototype.
The team members were requested to fill in a questionnaire about the difficulties they found using IVAG. Each question required to indicate a difficulty level for each phase of the IVAG development process, according to the following schema: Level Level Level Level
1: 2: 3: 4:
Easy. Moderately difficult. Difficult. Very difficult.
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
455
A small percentage of the participants found Moderately difficult using the Code Editor, whileas the remaining members indicated Easy. The development of the Visual Automaton was Moderately difficult or Difficult for about 20% of the members, and all the participants were able to easily design the interfaces through IVAG. Moreover, about 45% of the programmers suggested precise applications of IVAG to other domains. Note that this team of programmers already implemented the same prototype with their conventional methodology, which includes tools like C++ and Visual Basict. Again, it was possible to note a substantial time saving in the IVAG reimplementation.
6. Related work State transition machines have been extensively used in the past for the definition of general graphical interfaces. Starting from the pioneer work of Jacob [5], the idea of using state machines to specify user interfaces was heavily explored for at least 10 years [11–14], and finally it seems to have failed in that scope because of the difficulty of handling the demands of direct manipulation interfaces. However, in [1] we have shown that the state-transition model is valid and effective when applied to rapid application development of visual applications. In Section 5, we have also given some experimental results that confirm the practical effectiveness of our approach. The ‘‘event-driven machine’’ notion is also included in some recent well-known modelling languages like UML [15]. However, such formalisms aim at the design of large-scale software projects, while the target of our approach are small/medium RAD applications. Generally speaking, RAD applications are characterized by the following issues: * * * *
Small or medium code size. Wide use of pre-existing components in the code assembling. Low formal level of specifications. Short release time.
The programmers of such applications usually write programs from scratch, rather than reusing existing code. As a consequence, whenever these applications have to be modified or augmented, this cannot be accomplished without substantial reprogramming. Generic RAD visual applications are usually produced using visual programming environments like Visual Basict, Visual Studiot or JBuildert. These environments could look like IVAG since they are composed of code editors and layout editors, too. However, unlike IVAG, these are general-purpose programming environments that lack a formal support methodology. In general, a programmer of such environments implements an application according to the development style issues above, in an ad hoc fashion and with intensive use of ‘‘cut & paste’’ operations. Moreover, although the programmer often designs an application using
ARTICLE IN PRESS 456
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
a well-organized event-driven logic, this organization is lost in the final ad hoc implementation. Several specific tools for rapid application development have been proposed in the recent literature. Among the others, the software design environment APICES, [16], suitable for the prototyping and rapid development of applications using network-like data structures, which are typical for CAD tools, and the framework-based tool INTRAD, [17], for developing intranet applications, where programmers can develop applications very easily by reusing not only source code but also design information. As opposite to most RAD tools of this kind where fast delivery often results in poor or even missing documentation, IVAG also produces an appropriate documentation of the generated code providing a sound platform for maintenance and further development. Moreover, thanks to its underlying rigorous methodology, IVAG does not skip the design phase and makes the underlying state-transition model available in a suitable format. The idea of using state-transition diagrams is also present in some commercial tools, like for example AnyStatest, [18]. However, what makes IVAG different from these tools is its methodologic counterpart. In fact, the development methodology of IVAG starts when it is possible to capture a precise and limited number of abstractions on the application domain. This happens, for example, when some components can be handled in a way substantially independent of the rest of the system. For instance, the formalism underlying IVAG contains a particular component (i.e. the visual layout, [1]) to abstract specific configurations of the user interface. Thanks to this methodology that directly embeds the abstraction idea in the underlying formalism, the state machines produced by applying our approach result to be of limited size and, therefore, can be easily manipulated. As a further benefit, any modification to the final application can be first designed using the statetransition diagram and then easily reported on the code by IVAG. This would be difficult to do with tools that are based on a general state machine model notion. In fact, in this case even small applications may produce state explosion resulting in complex automata that are hard to manipulate.
7. Conclusions In this paper we have presented a support environment for the design and the implementation of visual applications, namely the Interactive Visual Application code Generator (IVAG) system. The starting idea of the present research was to define a lightweight software development methodology based on a state-transition model avoiding the typical state explosion problem. We are confident that the current version of IVAG represents a good step towards this aim. In the Section ‘‘Related Work’’ we surveyed a number of related tools, remarking some advantages provided by the use of IVAG. In this discussion we do not mean that IVAG is more or less performing than these tools. Actually, the point is the particular application context that makes an approach more convenient respect to others. At present, we are encouraged by the experimental results and we feel that IVAG is suitable when
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
457
the application domain consists of particular classes of visual applications, i.e. small/ medium sized RAD applications where a few components can be abstracted from the application domain and handled separately. We have widely experimented our approach by applying IVAG on a variety of case studies. This experimentation shows that IVAG offers a good compromise between rapid development, typical of RAD environments, and reusability, typical of object-oriented environments [19,20]. Moreover, software developers using our kind of model-based generative programming can also profit during the evolution of a software project. In fact, changes required, e.g. in the structure of the statetransition diagram of the application, which are not known at the beginning of the project, simply result in the automatic re-generation of large parts of the application. Further research includes the characterization of a set of templates suitable for other classes of practical applications, for example Multimedia- or Database-based ones. For these applications, the concept of Basic Layout should be extended to a Basic Configuration notion, defined as a set of characterizing components for the specific kind of application. For example, a Basic Configuration in a DB-based application may include the database states characterized by a set of rules that could be expressed using SQL queries. To embed this notion in IVAG, the tool interfaces and modules will have to be adapted accordingly.
Appendix In the following, we present a running session of the Visual Medical Diagnostician application showing a sequence of interactions with an end-user to obtain a diagnosis.
Fig. 14. VMD running session, step 1.
ARTICLE IN PRESS 458
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 15. VMD running session, step 2.
Fig. 16. VMD running session, step 3.
Step 1 (Fig. 14): The user gives the average temperature of the child selecting one of the three ranges provided by the interface. The selection is done with a mark. Since the child has not been vomiting or having convulsions, the corresponding checkboxes remain unmarked. Step 2 (Fig. 15): The user starts to input the symptoms shown by the child. First, he/she selects one of the five symptoms graphically represented by the icons at the
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
459
Fig. 17. VMD running session, step 4.
Fig. 18. VMD running session, step 5.
top of the interface, in this case the icon ‘‘Spots’’. The symptom icon is marked, indicating that the user now has to place that icon on the child image. Step 3 (Fig. 16): The user has clicked on an area of the child image, and the ‘‘Spots’’ icon has been automatically placed there. In this way, the user has specified that the child shows spots on the forehead. Step 4 (Fig. 17): The user has terminated the visual insertion of symptoms. He/she has specified that the child has spots and reddening on the forehead, and eye
ARTICLE IN PRESS 460
G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
Fig. 19. VMD running session, step 6.
inflammation. The average temperature is between 38 C and 40 C. Next, the user clicks the ‘‘Verify disease’’ button to ask the program which disease is characterized by these symptoms. Step 5 (Fig. 18): The system does not have all the elements needed to give a diagnosis, so it asks the user for additional information. Here, the user is asked to verify if the child has still rhinitis or conjunctivitis. The answer is ‘‘no’’. Step 6 (Fig. 19): Finally, after the user has answered the additional questions, the system gives the diagnosis: ‘‘the child has measles’’.
References [1] G. Della Penna, B. Intrigila, S. Orefice, Generating graphical applications from state-transition visual specifications, International Journal of Human Computer Studies 55 (2001) 861–880. [2] IEEE Computer. Special issue on visual programming, IEEE Computer 20 (1995) 14–16. [3] WWW-VISUAL. WWW Virtual Library: Visual Languages and Visual Programming, http:// cui.unige.ch/Visual. [4] K. Marriott, B. Mayer, Visual Language Theory, Springer, Berlin, 1998. [5] J.K. Jacob, A state transition diagram language for visual programming, IEEE Computer 18 (1985) 51–59. [6] J. Martin, Rapid Application Development, Macmillan Publishing Company, New York, 1991. [7] K. Rapley, RAD or TRAD or both? The future of software development, IEEE Colloquium on Rapid Application Development, 1998. [8] WWW-XML. Extensible Markup Language, http://www.w3.org/XML/. [9] WWW-XSL. eXtensible Stylesheet Language, http://www.w3.org/Style/XSL/. [10] G. Della Penna, B. Intrigila, A.R. Laurenzi, S. Orefice, An XML definition language to support scenario-based requirements engineering, International Journal of Software Engineering and Knowledge Engineering 13 (2003) 237–256.
ARTICLE IN PRESS G. Della Penna et al. / Journal of Visual Languages and Computing 15 (2004) 439–461
461
[11] M. Green, A survey of three dialog models, ACM Transactions on Graphics 5 (1986) 244–317. [12] N. Green, G. Singh, Automating the lexical and syntactic design of graphical user interfaces: the UofA UIMS, ACM Transactions on Graphics 10 (1991) 213–254. [13] J.K. Jacob, A specification language for direct manipulation interfaces, ACM Transactions on Graphics 5 (1986) 283–317. [14] B.A. Myers, A new model for handling input, ACM Transactions on Information Systems 8 (1990) 289–320. [15] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, AddisonWesley, Reading, MA, 1998. [16] A. Bredenfeld, APICES—rapid application development with graph pattern, Ninth International Workshop on Rapid System Prototyping, 1998, pp. 25–30. [17] H.-T. Jung, D.-K. Kim, Y.-J. Yang, S.-D. Lee, A design and implementation of object-oriented framework-based RAD tool (INTRAD), 2000 IEEE International Conference on Systems, Man and Cybernetics, Vol. 3, 2000, pp. 2057–2061. [18] XJ Technologies. AnyStates, http://www.xjtek.com/products/anystates/. [19] G. Booch, Object-Oriented Design with Applications, Benjamin/Cummings, Redwood City, CA, 1994. [20] M. Burnett, A. Goldberg, T. Lewis, Visual Object-Oriented Programming: Concepts and Environments, Prentice-Hall, New York, 1995.