INTRODUCTION
During the last years a number of approaches were
proposed of how to design and create software and user
interfaces in a model-based manner. Many of them can only
be used for newly designed projects. Figure 1 gives an
impression of the general idea of this model-based UI
development process. Details on those tools and
methodology are for example found in [
Figure 1 sketches a generally agreed principle of modeldriven user interface development (MD-UID) for singlemodal UIs. A connection from “UI/Application” back to “Concrete UI” was omitted deliberately, as we don't consider UI-reengineering to be part of the general approaches.
It is a problem to apply the model-driven development (MDD) to already existing software systems. We aim to open MDD for legacy software as well. In this paper an approach is presented of how to extract a model of an application's user interface from the application itself. We start bottom-up by extracting a model of its concrete user interface (CUI). This model can be abstracted into an abstract user interface (AUI). While abstracting, connections to business logic and object model are preserved. Object model thereby refers to the classdefinitions of runtime objects. Figure 2 illustrates the general idea of our reengineering process. Dotted lines denote references, solid lines show the process flow.
By using AUI and CUI models we can transform and adapt the user interface to change appearance or concept, or to apply HCI patterns. Since we keep business-logic and object-model references, a generated user-interface from these models ought to be able to interact with the original software. In practice, we currently only are able to perform this process for very basic applications and in a restricted environment.
A lot of our tools are based on XUL and written in Java. This also applies to the reengineering tool-set. Hence this tool-set was intentionally planned to only examine and regenerate Java-Swing applications. We don't consider this as a confining restriction, but rather as a necessary simplification to actually deliver a sizeable proof-ofconcept application in appreciable time.
Comparable work of extracting user interface models from
existing applications and reengineering was also done by
Vanderdonckt et. al. [
To assist the reengineering of character based user
interfaces to graphical user interfaces a model based
approach was proposed by Tucker and Stirewalt [
Another of our main research topics is to integrate HCI
patterns into MDD. Object oriented design patterns, as
introduced by Gamma et. al., are considered as valuable aid
in software development. We expect comparable benefit of
HCI patterns as well and therefore try to integrate those
patterns into our model-based UI development process.
The main principle to achieve this is to translate HCI
patterns into machine-readable attributed components when
and where appropriate. We call these components “pattern
instance components (PIC)” [
Arnout's [
Our demonstration application is simple. It has two labelled
input fields for entering first name and surname. On
pressing “Propose User Id” a new string is calculated by
concatenating the first three letters of both name parts.
Afterwards this string is converted into lower-case form and
presented as “User-Id” in its own text field.
Figure 4 depicts how SeaMonkey's Gecko engine interprets
Swing2XUL's parsing result of the frame shown in figure 3.
We consider this XUL result as CUI of our application.
Taking it as input we are able to derive an AUI of this
application in an UIML [
BUSINESS LOGIC AND OBJECT MODEL Converting a Swing-UI to a similar looking XUL-UI is not difficult. Major problem is to get an object-model and keep the linkage from UI elements to that. Those references are needed later to synthesize a running application.
In a simple first attempt we tried to make use of XMI-UML
models, generated from an application's Java source code
by ArgoUML [
Check boxes, radio button and menus are handled in a similar manner. More complex references are needed for tables and trees to consider their respective internal models, renderers and editors.
REENGINEERING At this point we have a concrete user interface and our object-model. Thus the reverse engineering of our sample application, with respect to model based development, was successful.
We now are able to rearrange the user interface of our sample application and to generate a new running application with a different UI from that.
Assuming that usability testing has shown that users want
more guidance through the application, we decided to apply
the “Wizard” pattern [
A human designer has to decide which elements of the UI are to put in each single wizard page and also their sequence.
Application of patterns to a concrete user interface and
editing of XUL based CUI specifications is done by a
specialized editor named XUL-E [
PICs form the basis of pattern application. As mentioned before these are components consisting of transformation rules. Those rules allow the modification of concrete user interfaces in XUL based on an abstract model description, in this case “Wizard's” details.
An application of PIC “Wizard” generates a number of views, or pages, that are interconnected by “Next”, “Prev” and “Finish” controls.
Sequence and content of pages are determined by multiple area selections and their sequence. This is an interactive process. At first one draws a selection rectangle around the planned content for page one, afterwards one draws another selection rectangle around the future content of page two, etc.
This resulting CUI can be edited as in any other UI editor. The third view, counted top-down, does not meet our requirements and will be edited. It was modified manually by removing “Next” and “Finish” buttons and moving the buttons from the original application into their positions. This results in a user interface as shown in figure 7 for that wizard page. GENERATING THE REENGINEERED APPLICATION Our new user interface is still only displayable by XUL interpreters and it is not possible for them to interact with the original application.
We now need to generate a Java GUI that resembles our designed CUI and re-establishes connections to business logic and object-model. now we ourself created a small XUL to Java code generator, by using the interpreter engine of XUL-E. In this way it was easier to attach hooks for the original application's source code.
However, our code generator merges the newly designed CUI with object-model and business logic. It compiles the resulting source code and creates a new application that behaves like the original but with a different user interface. Figure 8 is a screenshot of our new application, a user id “karmül” for “Karl-Heinz Müller” was generated. CONSTRAINTS Presently our approach is not general enough to meet requirements of real-world applications. It requires the current GUI of an application to completely obey the Model-View-Controller concept of Swing, which most Java/Swing applications do not. If any data object or any part of business logic has associations to UI elements our approach eventually fails.
Also issues of technical nature do exist. For example threading and introspection done by the application itself. Another noteworthy constraint is to have an applications source code, respectively its UI relevant part. In most cases this limitation can be overcome by using Java decompilers. SUMMARY & FURTHER WORK We briefly reported on our ongoing work in the field of model-based reengineering of already existing, non-modelbased developed, applications.
The basic idea is to 1) derive a CUI from a running application, 2) derive its object-model and business-logic via its source code and 3) keep connections of CUI elements to those models of step 2. Using those models we can redesign the user interface and regenerate a functional application thereof. A short sample of this process, utilizing a pattern instance component, was presented.
Further work needs to be done to map more Swing components to XUL, most importantly trees and tables. And in doing so being able to derive more complex CUIs. Also some of the current constraints need to be resolved. Language: