DEUCE : A Declarative Framework for Extricating User Interface Concerns
Sofie Goderis, Programming Technology Lab, Vrije Universiteit Brussel, Belgium
Dirk Deridder, System and Software Engineering Lab, Vrije Universiteit Brussel,
Belgium
Ellen Van Paesschen, Laboratoire d'Informatique Fondamentale de Lille,
France
Theo D'Hondt, Programming Technology Lab, Vrije Universiteit Brussel, Belgium
|
 |
REFEREED
PAPER
PDF Version |
Abstract
Evolving a software system not only affects the source code responsible for the core
application, but also the user interface. Unfortunately user interface code is often
scattered through and entangled with the application code. In large and complex
user-interfaces, this tangling renders the implementation complex and hard to maintain.
Currently, the application needs to perform both the necessary changes to the
user-interface (e.g. disabling other buttons, propagating events, etc.) as well as invoke
the required application logic. The Deuce framework (Declarative User Interface Concerns
Extrication) intends to reduce the complexity of user-interface implementations
by applying separation of concerns on three UI concerns : presentation logic, business
and data logic, and connection logic. It does so by using a declarative meta-language
(SOUL) on top of an object oriented language (Smalltalk) such that an adequate language
is provided to describe the entire structure and behaviour of the user-interface,
as well as to link it with the application.
1 INTRODUCTION
Current software systems need to exhibit a high degree of flexibility to accommodate
a constant stream of change requests. This poses several challenges in standard
business systems, but is taken to the extreme in the case of context-sensitive devices
such as mobile phones and PDA's (a.k.a. Ambient Intelligence environments [9]).
These devices put the software under continuous strain to adapt to different user
capabilities, changing usage contexts, or even spatial information indicating whether
it is being held in landscape or portrait mode. It is clear that this context-sensitivity
does not only require special attention when writing the application's business and
data logic. It also challenges the user interface (UI) implementation which needs to
behave or present itself di erently according to the current usage-context. As we
will argue further on, the adaptation of the software is extremely complicated by
the fact that the UI and the application code are closely entangled. Related work
with respect to context-sensitivity [6] focusses on a language engineering approach, but not on UIs.
Figure 1: E-commerce requiring a Parent Approval for Minors upon 'check out'
Figure 2: Smalltalk code for the 'checkout' procedure in the e-commerce example
Consider for example an e-commerce application where orders cannot be processed
for children without the consent of their parents (see figure 1). Hence the
application needs to provide a way to obtain parental approval if applicable. As a
result of this requirement, the UI as well as the business logic are a ected on several
occasions. First of all adults should never be bothered with the existence of the
approval procedure for their own purchases. Secondly, whenever a minor clicks on
the checkout button, a (blocking) parental approval form must be shown. When a
parent enters the correct approval code, a second click on the checkout button will
start the standard checkout procedure. Handling the corresponding business and UI
logic behaviour, is typically the responsibility of the event-handler connected to the
checkout button. In figure 2 we illustrate the entanglement of several concerns in a
naive Smalltalk implementation of the checkout procedure.
In blue (regular font face) we highlight UI related functionality such as the
opening of a window and the enablement or disablement of particular buttons. In the future we refer to these types of concern as the presentation logic concern.
Functionality that is not related to the UI, such as the business logic for verifying
the age of a person, is shown in green (bold face). This concern is referred to
as the business and data logic concern. The connection between the UI and the
business logic is shown in red (italic). For example the code where the value of
the UI component shoppingBag is provided as an argument for the processOrder procedure. This concern is named the connection logic concern. It is exactly the
disentanglement of these di erent concerns which forms the subject of our work.
The entanglement and the associated evolution e ort becomes worse if an existing
implementation is adapted to incorporate new business requirements or to
accommodate new contexts. Consider for instance an extension of the e-commerce
application with a notion of discounts for returning customers. First of all, the fact
that these customers can benefit from a discount should be highlighted on the order
form (a UI visualisation concern). Secondly the code responsible for handling the
checkout button needs to be intertwined with code which opens up an informative
pop-up window (a UI behaviour concern). Moreover the same code should defer the
calculation of the amount due to a di erent method (a connection logic concern).
In many cases programmers will apply advanced techniques in order to reduce
the e ect of code entanglement, such as the use of design patterns [12], dynamic
object models [25] or state-machines [15]. Unfortunately this often results in the
creation of an ad hoc infrastructure which introduces an additional maintenance
hazard. Also it only delays and defers the problem of entanglement to a different
time and place.
Existing UI approaches, including the ones based on the Model-View-Controller
(MVC) architecture [23, 17], support a limited form of separation of concerns (see
also section 7). More precisely such approaches focus on separating UI visualisation
(in a view) from the business and data logic (in a model), and neglect the extrication
of UI behaviour. As a result, evolving the UI's behaviour still requires browsing the
source code, manually adding new UI behaviour and subsequently connecting it to
the business logic where appropriate. In addition the code handling for the contextsensitive
nature of the UI needs to be scattered throughout the application as well.
This is why we advocate a built-in solution that covers the separation of all concerns
in an integrated manner.
The DEUCE (Declarative User Interface Concerns Extrication) approach is
based upon the well-known principle of Separation of Concerns (SoC) [16] and aims
to provide programmer support for disentangling UI concerns. As already indicated,
we focus on the following three concerns: presentation logic, business and data logic,
and connection logic. In summary, inadequate support for separating the three UI
concerns results in the following problems:
- Evolving and maintaining the application is complicated. Since all UI concerns
are scattered throughout the business logic, the developer needs to browse
through the code to make adaptations at di erent places in the code. This could easily break or even corrupt the existing functionality.
- Reuse is difficult or even impossible. Due to entanglement there exists an
intrinsic connection between the presentation and the business logic. As a
result it is not possible to reuse either the one or the other.
In the next section we introduce the underpinnings of the DEUCE approach
which achieves the separation of concerns by means of a declarative language. Sections
3 to 6 present a proof-of-concept implementation for the important parts of
DEUCE. Sections 7 and 8 discuss DEUCE in relation to related and future work.
2 DEUCE : DECLARATIVE USER INTERFACE EXTRICATION
As already introduced, DEUCE separates three main UI concerns which are illustrated
in figure 3. Firstly, UI presentation covers concerns regarding the visualisation
aspects and the behaviour aspects of the UI. Speaking in general terms, UI
visualisation refers to how the UI looks and the widgets it contains (e.g. textboxes,
buttons, labels). It also refers to the visual properties such as colour, enablement/
disablement and state. For example, in the e-commerce application there
is a "checkout" button of size 25 by 150 pixels with a label "check out". DEUCE
will actually contain a deification of the UI which includes the widgets and their
properties. Visualisation also includes grouping components and specifying where
components are positioned in relation to one another, i.e. layout. For instance positioning
a component above another one, or putting all the components of one group
in a single column. DEUCE will contain a description for these relations.
UI behaviour specifies what actions take place upon an event on a widget, as well
as how widgets influence each other. For instance, when clicking on the checkout
button, the order is processed and the user gets a notification.
Secondly, business and data logic with respect to the UI, specifies 'hooks' in the
underlying code that link the UI with the application. These hooks describe where
the application and its UI are connected such that one can be called from within
the other. For instance, clicking the checkout button calls the checkout procedure.
Finally, connection logic makes the actual connection between the presentation
and business and data logic. These connections can depend upon the context. For
instance, if approval is needed, clicking the checkout button opens a parental approval
form instead of continuing with the standard checkout procedure.
The programmer needs support for disentangling the several UI concerns. Therefore
we need to satisfy the following requirements :
- Requirement 1: A separate high-level specification for every concern.
Separating the concerns allows for changes to concerns in isolation. Because
of the absence of disentanglement, concerns become possible reuse candidates. High-level specifications provide for a better understanding for the programmer
since he now deals with 'domain concepts' of the UI instead of low-level
technicalities of UI components.
Figure 3: Separating UI Concerns with DEUCE
- Requirement 2: A uniform medium for expressing all the concerns involved.
This reduces the overhead for the programmer of having to learn several formalisms
or mechanisms to specify the concerns.
- Requirement 3: A mechanism to map the high-level entities onto the actual
code level entities.
The high-level specifications (requirement 1) have to be translated into the
low-level UI specifics. Once a mapping between the two is established, the
actual translation happens automatically. This allows for reusing the mapping,
either because the UI has evolved or the mapping is reused amongst different
high-level UIs that translate to a same low-level platform.
- Requirement 4: An automated way to combine the different UI concerns.
The resulting application is created by combining the concerns with each other
and the underlying business application. Providing an automatic mechanism
for this combination is an important factor when o ering support to the programmer.
To meet these requirements, we propose the DEUCE (Declarative User Interface
Concerns Extrication) approach. It achieves a separation of concerns for UIs by using
a declarative meta-programming (DMP) language for expressing and combining
the concerns. Logic facts and rules describe and manipulate the UI concerns. The declarative reasoning mechanism of the declarative language puts the concerns and
business logic together. As a proof-of-concept we implemented DEUCE. We use
SOUL [28] as a declarative meta-programming language and the Cassowary constraint
solver [2] for supporting automated layout (as a part of the presentation
logic concern). Next, we shortly explain these declarative mechanisms. Logic programming languages such as Prolog [10] typically involve facts for
declaratively describing statements that are true and rules for indicating how the
facts interact, and what implications may be taken from them. A reasoning engine is responsible for determining the set of applicable rules. A rule usually has
the structure IF condition THEN action or conclusion or a variation thereof. The
engine tries to match a rule's conclusion or condition with facts and other rules in
order to come to a valid "solution". The benefit of logic programming is that the
focus lies on what is to happen or to be described, and not how this is done.
Declarative Meta-Programming is an approach that provides a logic programming
language as a meta-language on top of object-oriented programming languages. For
instance a Prolog-like language on top of Java or Smalltalk. Several implementations
have been developed of this approach, like TyRuBa [8] for Java and SOUL [28] for
Smalltalk. Note that similar to Prolog, the order of the rules is important. SOUL
makes it possible to retrieve information from the underlying Smalltalk system and
Smalltalk objects can be wrapped in SOUL. Therefore, Smalltalk expressions can
be used at the SOUL level and be parametrised with logic variables and evaluated
during interpretation of the rules. Hence, SOUL is in symbiosis with Smalltalk.
This symbiosis lies at the heart of the DEUCE implementation since it facilitates
connecting high-level and low-level entities (see requirement 3).
The Reasoning engine, as part of the declarative programming language, makes
use of a reasoning mechanism (algorithm). SOUL uses, in analogy to Prolog, a
backward chaining algorithm. Other alternatives exist, such as forward chaining
and regular expressions. For DEUCE we extended SOULs backward chainer with a
constraint solver. However, what algorithm is used, is of no importance for DEUCE.
What matters is that the reasoning mechanism uses the facts and rules of DEUCE's
rule-base (i.e. the logical description of the UI) during its process such that a
resulting application (i.e. the actual Smalltalk UI, linked with the application) is
created. The reasoning mechanism is used at runtime to decide which UI behaviour
to provide depending on the context (e.g. a parental approval procedure for minors).
The idea of a constraint system to represent a UI layout has been adopted in
DEUCE as this has shown to be a very intuitive idea [19]. With DEUCE the UI is
described (deified) at a higher logical level. This is also true for the layout relations
between components, which makes adding/removing and repositioning components
becomes less time-consuming. For instance, in figure 1 the approval form extends the
original window, which can easily be done by making components visible/invisible.
Nevertheless, if the obsolete components are positioned inbetween other components,
making them invisible creates 'holes' in the interface. Removing the components at
the high-level specification, will not necessarily change the abstract layout relations.
Given that these layout relations are translated into exact positions in the Smalltalk
UI automatically, the 'holes' in the UI are avoided. SOUL's setup where a high level
UI is 'downed' to the Smalltalk level through reasoning, created the opportunity
to add automated layout to DEUCE. To do so a Smalltalk implementation of the
Cassowary constraint solver [2] is used. A constraint is a logical relation between
some variables with a possible restriction on the value domain of these unknowns.
For instance, "a label should always be positioned to the left of an input field" is
a constraint that connects two objects, label and input field, without specifying
their exact coordinates. If the label or input field is repositioned, the constraint
relation between the two should remain valid and thus the other object will also be
repositioned. Constraints thus describe what relation should be maintained without
specifying that relation computationally. "Calculating" a result by means of a
constraint solver means searching for an actual solution with satisfied constraints.
In the following sections we zoom in on each of the aforementioned requirements
and how they are fulfilled by our implementation of DEUCE.
3 A SEPARATE HIGH-LEVEL SPECIFICATION FOR EVERY CONCERN
Being able to abstract away from the low-level specifics of a UI, allows the programmer
to better understand the UI and its flow. DEUCE facilitates the specification
of the concerns at di erent layers of abstraction. A high-level layer can contain
high-level (domain-specific) specifications for a certain application instance. For instance
what components are part of the UI, how these relate to one another in both
their visualisation and behaviour, and how they link to the underlying Smalltalk
application.
DEUCE uses SOUL as a declarative medium to express the UI concerns. The
underlying business and data logic is implemented in Smalltalk. SOUL's reasoning
mechanism combines the several layers of declarative concerns with the Smalltalk
code into the resulting application.
Presentation Logic Concern
The first concern, presentation logic, consists of visualisation and behaviour.
Visualisation deifies or 'ups' the actual UI such that its components and their visual
properties (colour, label, . . . ) can be accessed and updated from within SOUL.
For example, figure 4 shows rules for describing the components in the e-commerce
(standard) window and retrieving the contents of the shoppingBag component. The
rules that automatically link the logic level with the Smalltalk level, are described
in section 5.
As for the shoppingBag rule, the component(shoppingBag, ?comp) unifies comp
Figure 4: Presentation Logic : components and properties
Figure 5: Presentation Logic : component relations
with the component that is linked with shoppingBag in the fact-base (actually being
an upped UI fact). If this fact exists and unification succeeds, the contents(?comp,?bag) will retrieve the contents of the shoppingBag component and unify it with
the ?bag variable. Hence, calling the query shoppingBag(?bag), will unify ?bag with the contents of the shoppingBag component.
Relations between components are also part of the visualisation, such as specifying
that components belong together or specifying layout relations between components
that position them left to one another, in one column. For instance in figure
5, grouping a label and an input field together to form a nameInput, or positioning
the shoppingBag above the checkOutButton. These abstract layout relations are
transformed by DEUCE into constraint relations. The Cassowary constraint solver
resolves the constraints upon which DEUCE updates the layout property of the
components.
Behaviour logic specifies how visualisation is a ected by certain UI actions. For
instance, clicking the checkOutButton requires a parental approval form to appear
and some buttons to be disabled. In figure 6 the rule activateApprovalRequest specifies this UI behaviour, which will be linked with the clicking event through the
connection logic concern (as explained below).
Figure 6: Presentation Logic : UI behaviour
Figure 7: Business and Data Logic : hooks into the underlying application
Business and Data Logic Concern
A running application calls its UI and vice versa. 'Hooks' in the business application
are places where this link with the UI takes place. These are described at the logic
level by the business and data logic concern. This concern therefore represents part
of the underlying business and data logic such that they can be used in the rules.
For instance in figure 7, checking if a user received an approval to buy at the shop.
The second rule is used to translate the high-level approved into a lower-level hook.
[?inst orderApproval] is the actual hook into the application as it expresses a
piece of Smalltalk code where the message orderApproval is send to the Smalltalk
application (with ?inst being bound to the current application instance). This
mechanism is further elaborated on in section 5. Note that the orderApproval method is implemented as a standard Smalltalk method, and not as a logic rule.
Furthermore it is possible that the actual application hook depends on the context.
The reasoning mechanism is used to determine what rule succeeds and therefore
what hook to use. For instance in figure 8, an e-commerce application gives
regular customers an extra discount. For these customers the application method
calculating the discount will be di erent from the standard calculating method.
The "calculate price" button for regular customers will therefore link to another
calculating method, and use a di erent hook.
Connection Logic Concern
Connection logic is responsible for the actual connection between the presentation
logic and business logic. For the actual mechanism creating the connection,
Figure 8: Business and Data Logic : hooks depending on context
Figure 9: Connection Logic : linking checkout button with checkout query
we refer to section 5. In figure 9, the connection is called model, and links the checkoutButton with the checkout query. Clicking the button will launch this
query and therefore the checkout rules as shown in figure 9 are triggered. If no
approval is needed, either because the user is an adult or a child that already has
approval, the first rule will fail and the second one will be triggered. Otherwise the fi rst one will succeed. This means that, depending on the context (approval or not),
di erent presentation logic and business logic actions are performed.
4 A UNIFORM MEDIUM FOR REPRESENTING ALL THE CONCERNS
INVOLVED
As UIs are entangled with and scattered through the underlying business logic,
evolving and maintaining the UI often results in the programmer spending a reasonable
amount of time in browsing the code in order to get an understanding of where
and how to make the necessary adaptations. A good separation of concerns eliminates
this problem. The mechanism combining the several concerns into a solution,
needs to consider all concerns at the same time in order to provide for an integrated
solution. It therefore benefits from representing the concerns in a uniform medium.
On top of this medium, dedicated tools are provided for the programmer, such that
for each task an appropriate formalism can be used. For instance, in DEUCE the programmer can use the standard Smalltalk UI Builder to specify UI components,
which DEUCE then translates into SOUL facts.
Figure 10: Presentation Logic : accessing and updating component properties
5 A MECHANISM TO MAP THE HIGH-LEVEL ENTITIES ONTO THE
ACTUAL CODE LEVEL ENTITIES The high-level UI specifications (requirement 1) are transformed into low-level and
device/platform specific UIs. These transformation 'rules' can be reused by different
high-level UIs that translate to UIs on the same platform. On the other hand,
using di erent sets of transformation rules allow for reuse of the high-level UI and
translate it to UIs for di erent platforms. Translating the high-level entities to
the actual code level entities, or 'downing' the high-level UI specification to the
Smalltalk level, happens through the use of SOUL's symbiosis mechanism. Smalltalk
expressions, possibly annotated with logic variables, can be used at the SOUL level.
(In the examples these expressions are between square brackets). The following
examples show specifications at a lower level and make use of SOUL's symbiosis
with Smalltalk.
Presentation logic deifies the low-level Smalltalk UI and uses symbiosis rules to
access the components and their properties. For instance, to determine a component
or its name property. Symbiosis is also used to change a component's properties,
such as disabling a component (through the model(checkoutButton, checkout)
fact in figure 10).
High-level UI components are 'downed' to Smalltalk UI components by 'standard'
DEUCE rules. These rules are low-level, platform specific that are reused amongst
di erent high-level UIs that all translate to Smalltalk UIs. Figure 11 illustrates a
rule for adding an actionButton to the Smalltalk UI. The component's properties
are queried and used in creating a Smalltalk specification for the button, which then
is added to the UIBuilder of the Smalltalk UI.
Connection logic contains rules for linking presentation logic and business logic
together, as shown in figure 9. The actual linking happens as shown in figure 12.
The Smalltalk code behind a component, e.g. the checkout button, calls the SOUL evaluator to launch the query that was associated with the button in the first place
(figure 9).
Figure 11: Presentation Logic : creating low-level UI components
Figure 12: Connection Logic : using a component's model to launch SOUL
6 AN AUTOMATED WAY TO COMBINE THE SEVERAL UI CONCERNS
The declarative reasoning mechanism (that comes with a declarative programming
language) uses facts and rules to come to a 'solution'. This process happens automatically.
As this solution is the resulting application (with UI), the concerns are
combined automatically into this application. Note that depending on the context,
other rules will succeed and thus invoke other logic. This means that the UI flow
path is 'calculated' automatically by the reasoning mechanism. Before this path was
hard coded explicitly, for instance through 'if-statements'.
7 RELATED WORK
DEUCE brings several research areas together. First of all it aims for separation
of concerns. To a certain extent, other approaches have also applied this principle
to UIs. Automated layout in the presentation concern is crucial if the programmer
wants to specify high-level interfaces and no longer needs to bother with low-level positioning of components. For this DEUCE uses the Cassowary constraint solver,
but other possibilities exist. As for connection logic, we mention two approaches
that solve problems of entanglement because of call-back procedures.
Separation of Concerns for UIs
The principle of separation of concerns has been applied, to a certain extent, to UI
concerns by other approaches. However, these only focus on separating two of the
concerns. The Model-View-Controller (MVC) architecture [24, 17] for example is a
well-known approach, but is often misinterpreted such that MVC is thought of separating
certain concerns but actually does not [11]. In MVC the controller handles
input and transmits it to model and view. The view is the output towards the user,
but it only covers the visualisation aspect of the UI. However, the behaviour concern,
the business and data logic, and connection logic are captured by the model. These
remain entangled, which gets even more stressed in Smalltalk's implementation of
the MVC pattern [13]. For instance, when upon a button click other components get
enabled, the enabling code is still entangled with the application code. When evolving
UIs, this entanglement makes it difficult for the programmer to adapt the UI. Model-View-Presenter [21] is a generalisation of the MVC metaphor and is intended
to overcome some of the problems with MVC as it is implemented in Smalltalk
VisualWorks[5]. Unfortunately, in MVP they attribute the same meaning to model
and view as in MVC. Business and data code and the UI behaviour concern are still
entangled.
The User Interface Markup Language (UIML) is an XML-compliant language
designated to build interfaces that can be deployed on multiple appliances [1]. Interfaces
described with this declarative language consist of five parts: description,
structure, data, style, events. These correspond to UI visualisation and connection
logic. UIML separates the several UI concerns and provides rules to describe when to
select what event. However these rules are fully 'matched' at specification time and
cannot rely on a reasoning engine to reason with facts and other rules. Furthermore
dynamic changes to the UI are not possible if not anticipated in advance. If several
conditions are combined in order for an event to be triggered, they are combined
statically and can result in long complex structures (similar to the if-statements for
programmatic UI visualisation changes).
Model-based UI development environments divide a UI into four declarative models
[7]. The application model describes the properties of the application that are
relevant to the UI. The task-dialogue model describes what tasks a user can perform
with the application as well as how these tasks relate to each other. The abstract
presentation model provides a conceptual description of structure and behaviour of
the visual parts of the UI. The concrete presentation model describes the visual parts
of the UI in terms of widgets. Di erent model-based approaches (e.g. [27, 22, 14])
provide di erent techniques to specify (some of) these four models but not all of the
approaches apply a same level of SoC. DEUCE can actually be considered to be a model-based approach where models are immediately executable.
Automated layout
Current research in automated layout [18] focusses on constraint-based and machine
learning techniques, since both layout managers and templates are too limited. Layout managers [26] are part of UI toolkits and have simple layout policies built-in,
such as horizontal or vertical layout. Designing complex hierarchical layouts are
difficult and tedious. Templates [19], used in word-processing, focus on the format
of the presented material (e.g. font, colour) and layout floating objects. Although
most users of these systems overrule the simplistic placement policies for floating
objects by placing the objects by hand. Constraint-based automated layout systems [4] deal with more advanced layouting possibilities and enforce position and size
restrictions on components. A constraint solver is used to get to a solution, and
thus a valid layout. Machine learning techniques [29] learn about what constraints
to apply based on interaction with the user or by learning from a large provided
set of presentations (i.e. layouts made by a layout-expert). DEUCE incorporates a
constraint-based system for achieving automated layout.
Connection logic
Connecting the presentation concern with the business and data concern is achieved
in DEUCE by its declarative mechanism. Other mechanisms exists but often do not
provide, or provide only partially a mechanism to connect both concerns automatically.
Taps [3] are used to link the UI and the application and provide an extra level of
indirection between the two. Taps partially map application objects to the interface
objects and are triggered by user actions. The application and UI no longer know
about each other, which makes it possible to easily change either one. However, we
believe that the entanglement that before resided at application level, now resides
in the tap.
Myers et al. [20] observe that a lot of call-back procedures perform no actual
application work, but rather one of the following tasks: preparing data for the
application, preparing data to be shown to the user, error checking and controlling
connections between UI components. The authors present Gilt, a tool to generate
expressions for these tasks automatically. Call-backs that do call application functions,
are specified with high-level parameters instead of low-level widget properties.
This is an extra indirection between the UI and application but only solves part of
the connection concern. 8 CONCLUSION AND FUTURE WORK
Separation of Concerns is an important technique to come to possible more evolvable,
reusable and maintainable code. Although User Interfaces would benefit of the same
advantages, SoC is often limited or absent altogether. Three concerns related to UIs
(presentation logic, business and data logic and connection logic) are discussed in
this paper. To aid a programmer in achieving a separation of concerns we proposed
DEUCE, an approach for Declarative User Interface Concerns Extrication. We have
put the following requirements forward in order for providing programmer support
for creating UIs and disentangling the concerns:
- Requirement 1: A separate high-level specification for every concern.
- Requirement 2: A uniform medium for representing all the concerns involved.
- Requirement 3: A mechanism to map the high-level entities onto the actual
code level entities.
- Requirement 4: An automated way to combine the di erent UI concerns.
DEUCE uses declarative meta-programming for specifying the UI concerns and
its reasoning mechanism to construct a valid UI out of this. A constraint solver
is added to provide for automated layout. As a declarative meta-programming
language DEUCE uses SOUL, a prolog-like language built on top of and in symbiosis
with Smalltalk.
Requirement 1 is met because every concern is expressed by its own set of facts
and rules. Within these rule-bases, di erent levels of abstraction occur, going from
low-level platform specific towards high-level application specific. As we use the
same declarative medium for expressing all the concerns, the programmer is provided
with the uniform medium as proposed in requirement 2. The declarative
reasoning mechanism that is part of SOUL, and hence of DEUCE, combines the
facts and rules of the concerns rule-bases. Although di erent reasoning mechanisms
(e.g. forward reasoning, regular expressions) can be considered as an alternative
to SOUL's current backward chaining algorithm, they all combine the concerns automatically
(requirement 4). Finally, requirement 3 is achieved through SOUL's
symbiosis with Smalltalk. Smalltalk code can be called from within the SOUL level
and used during the reasoning process. Through this mechanism high-level entities
are transformed into actual low-level (Smalltalk) entities.
Because of SOUL's symbiosis with Smalltalk, we can switch from one to the
other during runtime. Smalltalk code can be used at the SOUL level and SOUL
queries can be launched from within the Smalltalk level. This allows for run-time
interaction between the UI and the declarative reasoning mechanism. Contexts will
be detected at runtime, and there is no need to anticipate all possible combinations
of contexts. The reasoning mechanism can be asked to trigger all rules for which theconditions are met. DEUCE has only recently started to take advantage of these
runtime possibilities, and further research and tool support in this area is required.
As the main focus of this research lies in separating UI concerns from a programmer's
perspective, currently layouting is limited to a basic set of rules. In the future
this set is to be extended with more advanced layouting schemes.
Also, even though the proposed solution is promising, further research needs
to investigate the scalability on real world applications, as well as how rules and
interaction schemes are to be reused.
REFERENCES
[1] M. Abrams, C. Phanouriou, and A. L. Batongbaca. Uiml: An appliance-independent
xml user interface language. Technical report, Harmonia, Inc, 1999.
[2] G. J. Badros, A. Borning, and P. J. Stuckey. The cassowary linear arithmetic constraint
solving algorithm. ACM Trans. Comput.-Hum. Interact., 8(4):267-306, 2001.
[3] T. Berlage. Using taps to separate the user interface from the application code. In ACM Symposium on User Interface Software and Technology, pages 191-198, November
1992.
[4] A. Borning and R. Duisberg. Constraint-based tools for building user interfaces. ACM Trans. Graph., 5(4):345-374, 1986.
[5] A. Bower and B. McGlashan. Twisting the triad: The evolution of the dolphin
smalltalk mvp application framework. In Tutorial Paper for ESUG 2000, 2000.
[6] P. Costanza and R. Hirschfeld. Language constructs for context-oriented programming:
an overview of contextl. In DLS '05: Proceedings of the 2005 conference on
Dynamic languages symposium, pages 1-10, New York, NY, USA, 2005. ACM Press.
[7] P. P. da Silva. User interface declarative models and development environments: A
survey. In P. Palanque and F. Paternò, editors, Proceedings of DSV-IS2000, volume
1946 of LNCS, pages 207-226, Limerick, Ireland, June 2000. Springer-Verlag.
[8] K. De Volder. Type-Oriented Logic Meta Programming. Phd thesis, Programming
Technology Lab, Vrije Universiteit Brussel, September 1998.
[9] K. Ducatel, M. Bogdanowicz, F. Scapolo, J. Leijten, and J.-C. Burgelman. Scenarios
for ambient intelligence in 2010. Technical report, EC Information Scociety
Technologies Advisory Group (ISTAG), 2001.
[10] P. Flach. Simply Logical. John Wiley and sons, 1994.
[11] M. Fowler. Gui architectures, 2006. [12] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: elements of
reusabel object-oriented software. Addison-Wesley, 1995.
[13] A. Goldberg and D. Robson. Smalltalk-80: The Language. Addison Wesley, 1989.
[14] T. Griffiths, P. J. Barclay, N. W. Paton, J. McKirdy, J. B. Kennedy, P. D. Gray, R. Cooper, C. A. Goble, and P. P. da Silva. Teallach: a model-based user interface
development environment for object databases. Interacting with Computers,
14(1):31-68, 2001.
[15] I. Horrocks. Constructing the User Interface with Statecharts. Addison Wesley Professional,
1999. [16] W. Hürsch and C. Lopes. Separation of concerns. Technical report, Northeastern
University, Boston, February 1995.
[17] G. E. Krasner and S. T. Pope. A cookbook for using the model-view-controller user
interface paradigm in smalltalk-80. JOOP, August/September 1988.
[18] S. Lok and S. Feiner. A survey of automated layout techniques for information
presentations. In SmartGraphics Symposium, pages 61-68, Mars 2001.
[19] S. Lok, S. Feiner, and G. Ngai. Evaluation of visual balance for automated layout. In IUI '04: Proceedings of the 9th international conference on Intelligent user interface,
pages 101-108, New York, NY, USA, 2004. ACM Press.
[20] B. A. Myers. Separating application code from toolkits : Eliminating the spaghetti
of call-backs. In UIST'91, 1991.
[21] M. Potel. Mvp: Model-view-presenter - the taligent programming model for c++
and java. Technical report, Taligent Inc, 1996.
[22] A. R. Puerta and D. Maulsby. Mobi-d: A model-based development environment for
user-centered design. In CHI Extended Abstracts, pages 4-5, 1997.
[23] T. Reenskaug. Models - views - controllers, december 1979.
[24] T. Reenskaug. Thing-model-view-editor : an example from a planningsystem. Technical
report, 1979.
[25] D. Riehle, M. Tilman, and R. Johnson. Dynamic Object Model. Pattern Languages
of Program Design 5. Addison-Wesley, 2005.
[26] SUN. Using layout managers. Java Tutorial, 2007.
[27] P. A. Szekely, P. Luo, and R. Neches. Beyond interface builders: Model-based interface
tools. Interchi, April 1993.
[28] R. Wuyts. A Logic Meta-Programming Approach to Support the Co-evolution of
Object-Oriented Design and Implementation. Phd thesis, Vrije Universiteit Brussel,
Programming Technology Lab, Brussels, Belgium, January 2001.
[29] M. Zhou and S. Ma. Toward applying machine learning to design rule acquisition
for automated graphics generation. Technical report, IBM Watson Research Center,
1999. About the authors
Cite this document as follows: Sofie Goderis, Dirk Deridder, Ellen Van Paesschen, Theo
D’Hondt: "DEUCE : A Declarative Framework for Extricating User Interface Concerns", in
Journal of Object Technology, Special Issue: TOOLS Europe 2007, vol. 6, no. 9, October 2007,
pages 87-104,
http://www.jot.fm/issues/issue_2007_10/paper5/
|
