Multi-platform Ur Interface Construction –
A Challenge for Software Engineering-in-the-Small
Judith Bishop
Department of Computer Science
University of Pretoria
Pretoria 0002
South Africa
jbishop@cs.up.ac.za
ABSTRACT
The popular view of software engineering focus on managing teams of people to produce large systems. This paper address a different angle of software engineering, that of development for re-u and portability. We consider how an esntial part of most software products – the ur interface –
can be successfully engineered so that it can be portable across multiple platforms and on multiple devices. Our rearch has identified the structure of the problem domain, and we have filled in some of the answers. We investigate promising solutions from the model-driven frameworks of the 1990s, to modern XML-bad specification notations (Views, XUL, XIML, XAML), multi-platform toolkits (Qt and Gtk), and our new work, Mirrors which pioneers reflective libraries. The methodology on which Views and Mirrors is bad enables existing GUI libraries to be transported to new operating systems. The paper also identifies cross-cutting challenges related to education, standardization and the impact of mobile and tangible devices on the future design of UIs. This paper eks to position ur interface construction as an important challenge in software engineering, worthy of ongoing rearch.
Categories and Subject Descriptors
D.2 SOFTWARE ENGINEERING: D.2.6 Programming Environments Graphical environments, Integrated environ-ments, D.2.7 Distribution, Maintenance, and Enhancement, portability, D.2.13 Reusable Software, Reusable libraries. General Terms
Performance, Design, Reliability, Human Factors, Languages, Standardization, Languages
Keywords
Graphical ur interfaces, GUI library reu, platform independence, portability, reflection, mobile devices, tangible ur interfaces, , XUL, XAML, Views, Mirrors 1.INTRODUCTION
1.1Software engineering
Software engineering as a discipline is perceived as tackling computing in-the-large. It elevates tools and techniques from the level of a craft, to where they can be efficiently and reproducibly harnesd for the successful completion of large projects.
Thirty years ago in 1975, Fred Brooks introduced us to the mythical man month of software development [Brooks 1975] and followed this with the “no silver bullet” paper, in which he talked about software engineering as being a process of building software with “specifications, asmbly of components, and scaffolding” [Brooks 1987]. Boehm, too, found in 1976 that software engineering was, encouragingly, concentrating on the “requirements analysis design, test, and maintenance of applications software by technicians in an economics-driven context [Boehm 1976]. In the same era, [Basili 1986] concurs with the notion of software engineering being concerned with “development not production”, yet emphasising the importance of being able to experiment with and replicate the proce
ss.
The common thread in the early minal papers by pioneers of software engineering is the desire to manage the complexity of building something big. Although software engineering is a many faceted discipline, the facets are most often viewed as forming a progression of phas from requirements through construction, testing and quality control. Fast forwarding to the SWEBOK report [SWEBOK 2004], we find the latest definition from the IEEE Computer Society: “Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.”
A more unusual definition from a text book [Ghezzi 1991] states that “Software engineering is concerned with the multi-person construction of multi-version software”. The popular view of software engineering focus on the first part of this definition, that of managing teams of people to produce a (implied) large product. The cond part is as important: successful software engineering has come from identifying specific parts of a product, so that they can be designed by experts, and mass-produced, free of dependencies on language and environment. 1.2Graphical ur interfaces
Graphical ur interfaces are an example of such a specialization. In this paper, we consider how GUIs can be successfully engineered, not in multiple versions (reminiscent of
Permission to make digital or hard copies of all or part of this work for personal or classroom u is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwi, or republish, to post on rvers or to redistribute to lists, requires prior specific permission and/or a fee.维生素b1副作用
ICSE'06, May 20–28, 2006, Shanghai, China.
Copyright 2006 ACM 1-59593-085-X/$5.00.
751
product lines), but so that it can be portable across multiple platforms and on multiple devices, now and in the future. Our rearch has identified the structure of the problem domain, and we have filled in some of the answers. This paper eks to position ur interface construction as an important challenge in software engineering, worthy of ongoing rearch.
The key issues are that for a given program (existing or planned) it is desirable to decouple the following four elements: •programming language
•graphical toolkit or library
•virtual machine or runtime environment
•operating system.
In this way, we achieve paration of the GUI specification from the program so it can be reud in other programs, possibly written in other languages; and a portability path for the whole system onto other existing, or future, operating systems, with possibly different virtual machines. We investigate promising solutions to the problems, by comparing XML-bad specification notations, evaluating multi-platform toolkits, and describing our new work on reflective libraries.
Throughout the paper, we note the challenges that ari in terms of the technical, production and professional aspects of GUI constructions. The focus is primarily on the technical issues of programming, particularly on the obstacles raid by portability and adaptability. However, there are also cross-cutting concerns relating to education, standardization and acceptance by the community, as well as the impact of mobile and tangible devices. It is the message of this paper that GUIs are en to be operating behind the forefront of computing. They are not getting the attention they derve, and they need to be brought firmly into the software engineering fold1.
2.BASIC UI PRINCIPLES
2.1Reference models
In the 1990s, considerable work was done on reference models for UI design, with mappings to graphical and multimedia interfaces following. As far back as 1991, Coutaz [1991] propod a multi-agent framework applicable to the software design of interactive systems, and Dewan and Choudhary’s framework tackled flexible multi-ur interfaces [1992]. The issues that had to be addresd at that time were more prominently tho of cognitive psychology and hardware performance. Most of the architectural rearch at the time refers to the baline 1985 Seeheim Reference Model [1985] which presaged the model-view-controller (MVC) architecture with which we are now familiar.
课题界定
By the mid 1990s, the advent of Apple’s superb window interface, split the rearch community into tho concerned with human computer usability and tho who developed and promoted toolkits. One early such kit is Interviews from Stanford [1989], which was notable in that it already ran on four hardware platforms, all on top of one operating system, X 1 In this regard, it is interesting to note that Microsoft has recently coined the new acronym UX for Ur Experience, which is intended to address this gap.
Windows. We wish to take all of that a step further and abstract
from the operating system as well. In this paper we are not
focusing on GUI design or toolkit functionality, but on the engineering principles involved in the construction of modern,
adaptable GUIs.
Our premi is that it should be a software engineering tenet that
a GUI can be specified as a parate component in a system, and
then linked in a coherent way to the rest of the computational
logic of the program. The current practice is for GUIs to be
specified by creating objects, calling methods to place them in
the correct places in a window, and then linking them to code
that will process any actions required. If hand-coded, such a
process is tedious and error-prone; if a builder or designer program is ud, hundreds of lines of code are generated and
incorporated into one’s program, often labeled “do not touch”.
Either approach violates the software engineering principles of
efficiency and maintainability.
One of the problems of extracting a t of principles for GUIs is
that many of the terms are already language specific. However,
this confusion is not confined to GUIs: consider that we have
ca versus switch statements and ba vs super class. We will
choo and stick to one t of terms, initially giving the alternatives. We start off by considering conventional screen-
keyboard-mou GUIs. Such a GUI consists of the following
five parts:
•controls (or components or widgets)
• a window (or form or frame)
• a menu bar
•layout
•interaction.2
A GUI is en as a window on the screen and contains a number
of different controls. Controls can, for example, be labels, buttons or text boxes. The GUI very likely has a menu bar
across the top that typically contains the name of the program or
window and buttons for hiding, resizing and destroying the GUI
display. Additional options can be added to the menu bar. The
menu bar offers options similar to controls, but it is different in
the way in which it is created and displayed.
The controls are said to have a certain layout that defines their
欣赏是一种美德position relative to each other and/or directly in the window.
Both the choice of the controls and their correct layout are the
concern of the programmer, even if a GUI design is specified.
Once the controls are on the screen, the ur interacts with some
of them via devices such as the mou and keyboard. Moving
the mou over a control, and then clicking can make things
happen (as with a button). Other controls allow typing from the
keyboard, defining areas for outputting data, including text, images, video and sound. It is this area of interaction that is the
most challenging in GUI development, and to which we shall
return in Section 2.3.
2.2Controls
Most GUI libraries3 or toolkits offer upwards of 30 or 40 controls, each with numerous options or attributes. The
2 It is fascinating to note the clo correspondence between this list and
that of the 1989 toolkit, Interviews [16].
752
attributes can be size, color, font type and so on. The attributes are t at the time the control is created, but in most systems, they can be changed dynamically. For example, a text box created as
TextBox password = new TextBox();
can later have its background t to yellow by:
password.BackColor = Color.Yellow; Enumerating all the controls and all their attributes, even for one language, is a large task, but the appropriate choice of a control is important. For example, if we want to have an image and be able to click on it, we could u a button and t the image attribute, or we could u a picture box, which can respond to double clicking on the image specified. The picture box has extra scaling facilities, so the developer would have to choo.
Challenge 1.Indexing and navigating through the
control library.
What is needed is a compendium of controls that would be indexed not only by control names, but cross-indexed by attributes, such as clickability. Then the programmer can e what controls have this attribute, and can make an appropriate choice. Not all languages will have the same t of matches for controls and attributes, but at least, having learnt the principles, the developer knows what to look for.
2.3Layout
When developing a GUI, we can just add controls to the window as we think of them, but that would
not usually make for a very pleasing arrangement. A key feature of GUI design is to group similar controls together. Thus a designer could stipulate that all the buttons be at the top, or at the bottom of the window. We can split the screen in half, and have input boxes on one side, and output on another, and so on. The question is, how does the developer manipulate controls like this? There are two options: 2.3.1Drag and drop tools
We can u a tool which allows us to create the code for a GUI by dragging a control from a list showing all the possibilities and dropping it onto the spot which looks right visually. We can change the placement of controls by dragging them with the mou, and change their sizes and other attributes just as easily. Such tools are not in themlves very complex, but when they are integrated with development environments, such as JBuilder or Visual Studio, they have a large footprint. Fortunately for the large cohort of programmers who do not favour IDEs, standalone GUI Builders are available, such as Glade. The builders output both program code (not recommended) and XML (which is discusd in Section 4.1)
2.3.2Positioning
Without using drag and drop, we can parameteri calls to library methods that precily position a c
ontrol down to the last pixel. The code to place a button at position x=300, y=150 would be something like the following:
3 Library and API (application programmer interface) can be ud interchangeably: for clarity we u library consistently in this paper.
Button submit = new Button();
submit.Location = new Point(300, 150);
In itlf, this is not difficult to write or understand, but working
with many controls in absolute coordinates brings with it many
extra small details to specify, and can become very long-winded.
Another problem is that the size of screens varies with devices
and with time, in which ca absolute positioning has to be done
most carefully to obtain results that will endure.
刺猬馒头
A more flexible and enduring method is relative positioning, as
popularized in Java’s layout managers. They offer standard
arrangements such as flow, border and grid, into which
components can be placed, with the system handling the actual
positioning of components with suitable gaps between them. For
most GUIs they work very well, though they can have the same
scaling problem mentioned above.
With both methods, there is a lack of abstraction, too much
hard-coding, and little commonality across libraries.
Challenge 2.Encouraging standard and device
independent positioning techniques for controls
2.4Interaction
The definition and layout of controls is mostly a static exerci.
Interaction is dynamic, in that it will continue through the life of
the program, and requires careful programming to cover all
possibilities. Active controls such as buttons are linked to event
handlers early in the life of a program through listeners. For
example, our submit button could be linked to an actionPerformed method by:
submit.Click += new
System.EventHandler(actionPerformed);
Listeners esntially watch one or more controls and, when an
action takes place, activate all registered event handlers. Once in
a handler, we can interact with a control by calling methods
defined to get data from it and put data into it. The lection of
methods available depends on the language and library.
The interplay between listeners and handlers is the most
complex part of GUI programming becau it usually involves
higher-order programming constructs, such as delegates or
callbacks, and the previously assumed quential ordering of
statements is disrupted. The confusion caud in the mind of the
developer can be alleviated by a better division of responsibility,
and by shifting some of the work to a common engine, as
discusd Section 3.1.2.
Challenge 3.Reducing the complexity of the
event-handling paradigm
3.THE PROBLEM STATEMENT
Given that writing a GUI can be a messy and labour-intensive
task, a sound software engineering principle should be brought
into play: re-u. However, GUIs are very ldom reud
becau they are cloly coupled to a specific GUI library or
toolkit, and the have proven to be not very portable. Let us
introduce some definitions to support this statement.
753
Consider Figure 1. The GUI code is embedded in program P, written in language LA. The calls (to cr
eate, layout and handle controls) are to methods in the library or toolkit TK G. The toolkit can be written in a language other than LA, but will be compiled down to the same code as LA, running on virtual machine VM N. There is also a direct link between TK G and the underlying operating system OS X for the rendering of controls on output devices and the catching of events. For example, program P in C# (=LA) using System.Windows. Forms (=TK G) would run on the CLR (VM N) on Windows (OS X).
Figure 1. Normal operation of a GUI
The objective is to decouple the four elements in the following ways:
•GUI paration. Have the GUI specification parate from the program, so that it can be reud across programs; •Language independence. Be able to link a GUI specification into a program written in a different language; •Platform portability. Be able to move the whole system onto a differe
nt operating system platform.
Altering TK and VM is not as critical, but we shall e that they play important intermediary roles.
Example scenarios:
1.Re-using a GUI designed for a C# program in a VB
program. With the traditional method-oriented GUI, the
code would have to be identified, extraced and re-tooled in
VB. However, the library (Windows.Forms), run-time
system and the operating system could remain the same.
许多小鱼游来了
2.Moving a given program running on Windows to Linux.
This is more difficult: it depends on whether the toolkit
being ud is implemented on Linux, and a runtime system
exists. For C# and Windows.Forms, no such bidings
existed before our work.
Thus the problem is one of having invested in developing a program bad on a particular library, and then finding that the program cannot migrate to a new platform, becau of the library’s reliance on hardware or low-level software. If the library is a large and critical one, such as a GUI, then any alternative to a complete re-implementation of the GUI or the library would be desirable.
4.PROMISING SOLUTIONS
4.1Reu across languages
With the advent of Java and , the possibilities for cross platform and cross language computing have incread greatly. However, libraries that support GUIs have, for the most part, not
been included in this advance. For example, in the shared source
version of , the Windows.Forms library is specifically
excluded [Stutz 2003]. There is therefore an opportunity to
provide something that will travel better. Rather than design a
new library – which would suffer from the same problems as
other libraries – an alternative is to u XML for the
specification. XML has the advantage that it is universal, and
can be written by hand or emitted from a tool very easily.
The first step towards gaining independence of the operating
system, is to introduce a language-independent GUI specification notation to specify the function of the library, in
other words the programmer’s interface. The theory for such
specifications is called declarative ur interface models [da
Silva 2000], which describes ur interfaces in terms of the
controls displayed to the ur, their composition and their
layout. Two examples of the genre of declarative ur interface
models are IUP/LED [Levy 1996] and CIRL/PIWI [Cowan
1993]. In both cas, a declarative language (LED and CIRL)
was provided to describe the ur interface in terms of its
controls and layout. On the library front, they contain functions
for hooking events signaled by the interface to call-back
methods defined in the ur’s application, and functions to
query and alter attributes of the controls displayed. The call-
back event model is ud so that the usual native windowing
toolkit’s events are filtered down to tho relevant to the
application.
Such declarative ur-interface models are not new and XML is
broadly being adopted as the favourite notation for the
models. Our work on the Views4 project has also defined a
notation that draws on the underlying Windows.Forms toolkit,
but exercis freedom in improving the layout structure, more in
the line of Java.
For example, instead of the label, textbox and button code:
Label label = new Label();硫化氢中毒
label.Text = “Password”;
Textbox entry = new Textbox();
Button button = new Button();
button.Text = “Submit”;
we would write an XML specification such as:
<Label text=”Password”/>
<Textbox name=entry/>
<Button name=button text=“Submit”/>
Using XML in this way was propod almost ten years ago, and
it is gaining in acceptance. We will look at the XML-bad
systems XUL, XAML, and Views. For comments on Glade e
3.1.
4.
4.1.1XUL
XUL is the model ud by the Mozilla family of browrs. XUL
has a rich notation for creating widgets, and us Box, Grid and
other layout models. An example of a the specification of a
simple currency calculator in XUL is:
<window onload="loadWindow();"
id="win" title="Currency calculator"
4 Throughout this paper, projects and products who primary source of
information is a website are listed at the end of the paper, but the
sources are not cited in the text.
754
orient="horizontal"
<script src="calculator.js"/>
<grid>
<rows>
<row>
<label id="l1" class="small"
value="Paid on hols"/>
<textbox id="eurobox"/>
</row>
<row>
<label id="l2" class="small"
value="Charged"/>
<textbox id="GBPbox"/>
</row>
<row>
<label id="l3" class="small"
value="Exchange Rate is"/>
<textbox id="ratebox"/>
</row>
<row>
<button label="="
oncommand="equals();"/>
<button label="Ret"
oncommand="clear();"/>
<button label=">>"
oncommand="next();"/>
</row>
</rows>
</grid>
</window>
that will produce the window:
唯美空间By virtue of its being embedded in html. the XUL code is inherently cross-platform. The scripts for th
e handlers are not in the program, but written in Java Script, for example:
function clear() {
}
This breaks the paration of concerns between the GUI and the computational logic, which should be in program, written in its language.
XUL has a sister language, XBL (Extensible Binding Language) in which additional customization of the widgets can be written.
仿写秋天的怀念4.1.2Views
Views is the result of a rearch project with Microsoft Rearch to extend GUI functionality to the shared-source Rotor version of the platform, which did not include the GUI library [Bishop 2004]. The Views system consists of an XML-notation and a runtime engine which initiates the rendering of controls and handles events.
By means of 10 standard methods, the engine is able to trap events that come from the operating system and pass them on to the program. Unlike XUL, no code is included with the GUI specification. The calculator shown before would be entered as a string in the program (or read from a file) as:
static string specEn =
@"<form Text='Currency calculator'>
<horizontal>
<vertical>
<Label text='Paid on hols'/>
<Label text='Charged'/>
<Label text='Exchange rate is'/>
<Button name=equals text='='/>
</vertical>
<vertical>
<Textbox name=eurobox/>
<Textbox name=GBPbox/>
<Textbox name=ratebox/>
<Button name=clear text='Ret'/>
</vertical>
</horizontal>
</form>";
The handlers can be t up with callbacks, or can u a simple
event loop, part of which is
ca "clear":
euro=1; GBP=1;
f.PutText(
"eurobox",euro.ToString("f"));
f.PutText(
"GBPbox",GBP.ToString("f"));
break;
A recent extension of Views Views 2.0, allows the inclusion of
style sheets and other customisable information, similar to
XUL’s XBL [Mason 2005].
4.1.3XAML
XAML is the declarative markup language Microsoft is making
available with Version 2 of the Framework, as part of the
Windows Prentation Foundation (WPF) component of the
upcoming Vista platform for Windows. XAML is very similar to
Views in that it rides on the language interoperability of .
Unlike Views, there are no push-bad event methods, and all
handlers are also indicated as method names in XAML, in a
similar way to XUL. Of cour, Microsoft does not intend that
anyone would actually write XAML: it is more the output
notation from the GUI-builder of Visual Studio. There is
nothing intrinsically cross-platform in XAML, since it still relies
on Windows.Forms for events and rendering, and thus remains
cloly couple to the Windows operating system.
XAML is more verbo than the other notations, especially in
layout. The control specification for an equals box would be: <Button Grid.Row="3" Grid.Column="0"
ID="equals"
Click="EqualsClicked">=
</Button>
The handlers are kept in a parate file, making u of partial
class (a 2.0 feature) and connected by name to the
XML, e.g.
private void EqualsClicked
(object nder, RoutedEventArgs e) {
double euro = 1;
double GBP = 1;
euro = double.Par(eurobox.Text);
GBP = double.Par(GBPbox.Text);
ratebox.Text =
(euro / GBP).ToString("f");
}
4.1.4Comparison
All the notations achieve the goal of re-usable GUI specifications. The design of the XML, in each ca, is
somewhat tied to the expected underlying library, but the 755
