GUI

GENERATION BASED ON LANGUAGE EXTENSIONS

A Model to Generate GUI, based on Source Code with Custom Attributes

Marco Monteiro

School of Technology and Management, Polytechnic Institute of Leiria, Leiria, Portugal

Paula Oliveira, Ramiro Gonc¸alves

Engineering Department, University of Tr

as-os-Montes e Alto Douro, Vila Real, Portugal

Keywords:

Attribute-Oriented Programming, Source Code Model, GUI Generation, Data-Driven Application.

Abstract:

Due to data-driven application nature and its increasing complexity, developing its user interface can be a

repetitive and time-consuming activity. Consequently, developers tend to focus more on the user interface

aspects and less on business related code. In this paper, we’re presenting an alternative approach to graphical

user interface development for data-driven applications, that allows developers to refocus on the source code

and concentrate their efforts on application core logic. The key concept behind our approach is the generation

of concrete graphical user interface from a source code based model, which includes the original source

code metadata and non-intrusive declarative language extensions that describes the user interface structure.

Concrete user interface implementation will be delegated to specialized software packages, developed by

external entities, that provides complete graphical user interfaces services to the application. When applying

our approach, we’re expecting faster graphical user interface development.

1 INTRODUCTION

In this paper we propose an alternative approach to

Graphical User Interface (GUI) development for data-

driven applications. Nowadays developers tend to

create GUI by composition of various components.

Our ﬁnal goal is to allow developers to deﬁne GUI

by adding non-intrusive declarative language exten-

sions to the original source code and then acquire an

external software package to which they delegate the

implementation of the concrete GUI.

We start by introducing the research problem on

section 2, followed by a description of the proposed

model on section 3 and conclusions on section 4.

2 OVERVIEW

Currently, a large number of projects use Component

Based Development (CBD), which allows application

development by assembling a set of pre-manufactured

components. Each component is a black-box entity,

which can be deployed independently and is able to

deliver speciﬁc services (Szyperski, 1998).

GUIs are composed of various graphical elements,

such as buttons or input ﬁelds, each with its own pre-

sentation and behavior aspects that needs to be con-

sidered. Presentation concern the appearance and lay-

out of GUI elements and behavior is related to the

interaction between themselves or between them and

the underlying code. Using CBD, each GUI element

is mapped to a component and presentation or behav-

ior aspects are deﬁned by its properties, methods and

events. Also, by using Rapid Application Develop-

ment (RAD) tools, GUI layout design is made visu-

ally through composition of components. Compared

to older processes, the advent of CBD and RAD tools

has increased GUI development productivity.

However, CBD still hasn’t redeemed its promises

of reuse and ﬂexibility (Bruin and Vliet, 2002) and

there’s still a lot of risks, challenges and unresolved

issues in CBD (Vitharana, 2003). One of those is-

sues is related to the process of component compo-

sition and conﬁguration. On large or very large ap-

plications, the same component can be reused several

times on different contexts, which is a major factor to

the productivity improvement accomplished by CBD.

However, as the number of instances and complexity

449

Monteiro M., Oliveira P. and Gonçalves R. (2008).

GUI GENERATION BASED ON LANGUAGE EXTENSIONS - A Model to Generate GUI, based on Source Code with Custom Attributes.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - DISI, pages 449-452

DOI: 10.5220/0001691604490452

 SciTePress

of components increases, developer’s time is increas-

ingly spent on the tedious tasks of composing layouts,

conﬁguring components and maintaining consistency

in presentation and behavior aspects of the GUI com-

ponents through the entire application. Developers

tend to focus more on GUI aspects and components

internals and less on application core logic or busi-

ness related code. While there are some applications

where that makes sense, because User Interface (UI)

is the most critical factor for its success, on many oth-

ers it’s important to refocus development time and re-

sources to the core functionalities, as they’re the main

factor to the applications success. This is particularly

true for most data-driven applications

No matter how or where data comes from, as long

as applications devices uses the GUI paradigm, data

presentation and manipulation follows some patterns

that are easily recognizable. For example, there are

two typical ways of presenting data: record views and

grid views. Record views allows the presentation of

all attributes of only one entity instance, while grid

views usually presents the most relevant attributes of

various instances simultaneously (Figure 1).

Figure 1: Grid and Record View.

The main goal for the solution we’re proposing is

to improve GUI development by capturing the pre-

sentation and behavior aspects of these patterns and

therefore reducing or eliminating the need to conﬁg-

ure every different view. Analogous principles are

used by solutions like Cascade Style Sheets (CSSs),

templates, specialized or custom frameworks and au-

tomatic GUI generation.

2.1 Automatic GUI Generation

Proposed solutions to generate GUI automatically are

mainly model-based systems, that attempt to formally

describe the tasks, data, and users that an application

will have, and then use this formal models to guide the

generation of the GUI. Some systems automatically

design the GUI and others provide design assistance

to developers (Nichols and Faulring, 2005). Despite

In this article, we consider data-driven applications as

applications that allow users to access and manipulate large

amounts of complex data, located on data repositories.

a lot of research, model-based automatic GUI gen-

eration still hasn’t become common in GUI develop-

ment, in part because building models is an abstract

process and better results are often achievable by a

human designer in less time (Myers et al., 2000). Ab-

stract models can be complex to build and maintain,

thus keeping models and applications concrete GUI

synchronized can be problematic.

2.2 Attribute Oriented Programming

Attribute oriented programming is a program-level

marking technique, that allows developers to mark

language elements (e.g. classes, methods, and proper-

ties) in the source code, to indicate that they maintain

application or domain speciﬁc semantics. By hiding

the implementation details of those semantics from

source code, attributes increase the level of program-

ming abstraction and reduce programming complex-

ity, resulting in simpler and more readable programs

(Wada and Suzuki, 2005). Attributes can change ap-

plication runtime behavior by transforming its logic,

with the assistance of a supporting generation en-

gine. Dependencies on the underlying middleware

are thus replaced by attributes, acting as weak refer-

ences (Rouvoy and Merle, 2006). With the advent of

.Net attributes and Java annotations, attribute oriented

programming is now an widespread technique, used

in broad-range domains like logging, web services,

persistence or security, but also on speciﬁc domains

like fault-tolerance (Schult and Polze, 2002) or sys-

tem level modeling and simulation environment (La-

palme et al., 2004).

In the context of data-driven applications, at-

tributes can be used to address the problem of object-

relational impedance mismatch, which occurs due to

the fact that object-oriented and relational paradigms

represent information in manners that are quite differ-

ent from each other (Lodhi and Ghazali, 2007). Ob-

ject Relational Mapping (ORM) tools, deals with the

impedance mismatch problem by providing mappings

between the object model and the relational model,

which are usually deﬁned by external conﬁguration

resources. However, on tools like Hibernate Anno-

tations, Castle ActiveRecord or DevExpress Persis-

tent Objects for .Net, mapping conﬁguration is imple-

mented directly on the source code, using attributes.

This approach allows developers to concentrate only

on the object-oriented paradigm and delegate to ORM

tools the responsibility of handling persistence issues.

This leads us to the following question ”why don’t we

apply the same principles to handle presentation is-

sues”? That was the question that droves us to study

and propose the solution presented in next section.

ICEIS 2008 - International Conference on Enterprise Information Systems

450

3 PROPOSED MODEL

The key concept behind our approach is the automatic

generation of concrete GUIs from source code based

models, as opposed to specialized GUI models used

by most automatic GUI generation tools. In 2004, Je-

linek (Jelinek and Slavik, 2004) also used annotated

source code to generate GUI, but using a tree-rewrite

based language. Our model will use a mainstream

language (C#), with the purpose of reusing available

components and therefore simplifying concrete GUI

development. Source code based models main ad-

vantage is the proximity between the model and the

code we want to execute, improving the integration

and interaction between application core logic and ap-

plication GUI. Also, the process of model creation is

quicker and simpler, because part of the model is al-

ready deﬁned by original source code. However, mix-

ing business and GUI related code in the same mod-

ule, it’s against separation of concerns principle. To

minimize this problem, the model will be deﬁned by

new language elements (attributes) that are declara-

tive only, meaning that they will not interfere with

original structures or execution ﬂows. Also, to avoid

cluttering of source code with GUI related details, it’s

important to restrict the scope of the model so that it’ll

describe only structural information about the GUI.

The proposed model, explores some conceptual

similarities between data-driven applications GUI and

object-oriented languages. On the applications, there

are GUI elements such as textboxs or grids that pro-

vide data for the user to read or write. Objects can

also provide data to external entities, through struc-

tures like C# properties. Application users perform

operations by activating events on GUI elements, like

clicking on a button. Objects also perform operations

using methods, which are accessible to external enti-

ties through its interface. It’s possible to map source

code structures into GUI elements, using source code

metadata. GUI elements are chosen according to

the language element kind, data type or accessibility.

However, as original metadata is not enough to de-

scribe the GUI completely, language extensions (cus-

tom attributes) were added to enrich the metadata with

structural information about GUI. Analyzing the ex-

ample in Figure 2, we can verify that GUI elements

were generated according to: the kind of language el-

ement, where methods (e.g.

Sell

) maps into buttons

and properties into labels, textboxs or checkboxs; the

data type, where string properties (e.g.

Title

) and

boolean properties (e.g.

Rented

) generates different

type of GUI elements; the accessibility, where read-

only properties (e.g.

ISBN

) are mapped differently of

read and write properties. The

Show

attribute (which

is our model ﬁrst attribute) affected the GUI by allow-

ing to deﬁne what language elements are meant to be

available (e.g.

Keywords

property is hidden, because

it doesn’t have a

Show

attribute) and deﬁning which

text is used to describe it.

public class Book {

[Show]

public string ISBN

{ get {...} }

[Show("Book Title")]

public string Title

{ get {...}

set {...} }

[Show("Is Rented")]

public bool Rented

{ get {...} set {...} }

public string Keywords

{ get {...} set {...} }

[Show("Sell this book")]

public void Sell() {...}

public void RentBook() {...} }

Figure 2: GUI generation from extended source code.

3.1 System Architecture

To prove the viability of the proposed model, a proto-

type system was developed on Microsoft .Net Frame-

work using C# language. This system conceptual ar-

chitecture (Figure 3), is composed of three parts or

layers: the GUILX Model, the Binding Framework

and Smart Templates.

GUILX Model

Smart

Template (A)

GUILX ExtensionsBusiness Code (C#)

Binding Framework

Smart

Template (B)

Smart

Template (Z)

...

Figure 3: Conceptual architecture.

The language extension model, which we’ve called

the GUILX Model

, incorporates both the original

source code (the business code) and language exten-

sions or attributes, as referred on section 3. By prin-

ciple, these extensions only includes structural GUI

information. Concrete GUI details, if applied, should

be deﬁned outside the source code model by Smart

Templates. However, the GUILX Model must be rich

enough to ensure that a functional prototype (even if a

very simple one) can be created. Language deﬁnition

GUILX is the acronym for Graphical User Interface

Language eXtensions.

GUI GENERATION BASED ON LANGUAGE EXTENSIONS - A Model to Generate GUI, based on Source Code with

Custom Attributes

451

is still in progress, but besides the

Show

attribute it

also includes the

Query

attribute, that’s applied only

to method parameters. Methods that have at least one

parameter marked with the

Query

attribute, are in-

tercepted by GUILX system, so that ﬁnal application

may ask user to input parameter values before method

execution (check Figure 4).

[Show("Rent this book")]

public void Rent(

[Query("How many Days?", QueryKind.allways)]

int Days)

{

...

}

Before Method

Execution

Figure 4: Example of ”Query” attribute.

Solution architecture is designed to delegate the im-

plementation of concrete GUI, to external software

package, which we’ve called Smart Templates. The

idea is allowing developers to deﬁne a GUILX Model

and then adquire a Smart Template that’s suitable for

the application GUI. Smart Templates are specialized

frameworks, developed by external entities that pro-

vide complete GUI services to the GUILX Model.

There can be Smart Templates developed by different

suppliers, for different devices and using completely

different methods. One can generate GUI automat-

ically, other can generate GUI partially and another

can create GUI from manual deﬁnitions.

The Binding Framework is responsible for

the interoperability between Smart Templates and

GUILX Model, so that these two layers don’t in-

teract directly, thus keeping them independent from

each other. It allows the Smart Template to query the

GUILX Model metadata, to create object instances

and to invoke methods of that objects. Also, it serves

as a controller, maintaining the execution context for

the GUI elements, thus controlling navigation through

entire application.

4 CONCLUSIONS

Proposed model provides an alternative approach to

create application GUI, allowing developers to refo-

cus on business code development and delegate com-

plete GUI creation to external software packages,

called Smart Templates. Although GUILX language

deﬁnition is still in an embryonic state, preliminar

results already produces functional prototypes, thus

proving the viability of our solution. Compared to

other methods of automatic GUI generation, we be-

lieve our solution is easier to use because it simpliﬁes

the process of GUI model creation. Instead of rely-

ing on specialized abstract models, it uses a source

code based model, which is partially deﬁned by infor-

mation already present on the original metadata and

complemented by the GUILX language extensions.

REFERENCES

Bruin, H. and Vliet, H. (2002). The future of component-

based development is generation.

Jelinek, J. and Slavik, P. (2004). Gui generation from an-

notated source code. In TAMODIA ’04: Proceedings

of the 3rd annual conference on Task models and di-

agrams, pages 129–136, New York, NY, USA. ACM

Press.

Lapalme, J., Aboulhamid, E. M., Nicolescu, G., Charest,

L., Boyer, F. R., David, J. P., and Bois, G. (2004).

Esys.net: a new solution for embedded systems mod-

eling and simulation. SIGPLAN Not., 39(7):107–114.

Lodhi, F. and Ghazali, M. A. (2007). Design of a simple

and effective object-to-relational mapping technique.

In SAC ’07: Proceedings of the 2007 ACM symposium

on Applied computing, pages 1445–1449, New York,

NY, USA. ACM.

Myers, B., Hudson, S., and Pausch, R. (2000). Past,

present, and future of user interface software tools.

ACM Transactions on Computer-Human Interaction

(TOCHI), 7(1):3–28.

Nichols, J. and Faulring, A. (2005). Automatic interface

generation and future user interface tools. ACM CHI

2005 Workshop on The Future of User Interface De-

sign Tools.

Rouvoy, R. and Merle, P. (2006). Leveraging component-

oriented programming with attribute-oriented pro-

gramming. In Proceedings of The 11th ECOOP In-

ternational Workshop on Component-Oriented Pro-

gramming, Nantes, France. Monday, July 3, 2006 at

ECOOP 2006, (July 3-7, 2006).

Schult, W. and Polze, A. (2002). Aspect-oriented pro-

gramming with c# and .net. Object-Oriented Real-

Time Distributed Computing, 2002.(ISORC 2002).

Proceedings. Fifth IEEE International Symposium on,

pages 241–248.

Szyperski, C. (1998). Component Oriented Programming.

Springer.

Vitharana, P. (2003). Risks and challenges of component-

based software development. Communications of the

ACM, 46(8):67–72.

Wada, H. and Suzuki, J. (2005). Modeling turnpike fron-

tend system: a model-driven development framework

leveraging uml metamodeling and attribute-oriented

programming. In Proceedings of The 8th ACM/IEEE

International Conference on Model Driven Engineer-

ing Languages and Systems, Montego Bay, Jamaica.

ISBN: 978-3-540-29010-0.

ICEIS 2008 - International Conference on Enterprise Information Systems

452