Graphical user interfaces play a key role in human-computer interaction, as they link the system with its end-users, allowing information exchange and improving communication. Nowadays, users increasingly demand applications with adaptive interfaces that dynamically evolve in response to their speci c needs. Thus, providing graphical user interfaces with runtime adaptation capabilities is becoming more and more an important issue. To address this problem, this paper proposes a component-based and model-driven engineering approach, illustrated by means of a detailed example.
Graphical User Interfaces (GUIs) play a key role in Human-Computer Interaction (HCI), as they link the system with its end-users, allowing information exchange and improving communication. Nowadays, users increasingly demand \smart" interfaces, capable of (semi-)automatically detecting their speci c prole and needs, and dynamically adapting their structure, appearance, or behaviour accordingly.
GUIs are increasingly built from components, sometimes independently developed by third parties. This allows end-users to con gure their applications by selecting the components that provide them with the services that better t their current needs. A good example of this is iGoogle, as it provides end-users with many gadgets, allowing them to create personal con gurations by adding or removing components on demand.
Following this trend, the proposal presented in this paper considers GUIs as
component-based applications. Furthermore, it considers the components
integrating GUIs software architectures at two di erent abstraction levels: (
Our proposal does not only rely on a component-based approach but also, and
primarily, on a Model-Driven Engineering (MDE) approach. As detailed in the
following sections, we propose a GUI architecture description meta-model that
enables (
The remainder of the article is organized as follows. Section 2 reviews related works. Section 3 describes the proposed approach and its constituting elements, namely: the proposed GUI architecture meta-model, and a set of model transformations enabling runtime GUI adaptation. In order to illustrate the proposal, a GUI model evolution example is also described in detail in this section. Finally, Section 4 draws the conclusions and outlines future works. 2
There are many model-driven approaches in the literature for modelling user interfaces, as detailed in [1]. Some of them use a MDE perspective for web-based user interfaces [2]. However, in most cases, models are considered static entities and no MDE technique is applied to add dynamism, for instance, using model transformations.
Model transformations enable model re nement, evolution or even, automatic code generation. In [3], the authors investigate the development of plastic user interfaces (which have the context adaptation ability), making use of model transformations to enable their adaptation. However, these transformations are used at design-time and not at runtime, as we propose here. In [4], the authors propose an approach that makes use of model representations for developing GUIs, and of model transformations for adapting them. This work, in which the research described in this paper is based on, also considers these GUI models as a composition of COTS components.
The adoption of Component-Based Software Development (CBSD) proposals for software applications design and implementation is increasingly growing. An example can be found in [5], where the authors identify the multiple GUI evolution possibilities that come from working with component-based software architectures (e.g., addition of new components, interface recon guration, adaptation to user actions or task, etc.). However, this proposal implements GUI evolution by programming GUI aspects, instead of using model transformation techniques, as we propose in this work. Another example is shown in [6], which presents a combined MDE and CBSD approach to enable the modelling of structural and behavioural aspects of component-based software architectures. However, this proposal is aimed at general-purpose software architectures, and not particularly suited for GUI development. In [7], the authors focus their research on component retrieval, composition and re-usability in standalone DSLs (Domain Speci c Languages). This is useful in web applications, especially in those making use of the semantic web. However, as before, this work does not apply these ideas directly to compose GUI applications.
On the other hand, recent software engineering proposals advocate for the use of models at runtime (models@runtime) [8]. Existing research in this eld focuses on software structures and their representations. Thus, signi cant bodies of work look at software architecture as an appropriate basis for runtime model adaptation [9]. Our vision of models@runtime is completely aligned with this idea as our GUIs are, in fact, architecture models. In [10], the authors study the role of models@runtime to manage model variability dynamically. Their research focuses on reducing the number of con gurations and recon gurations that need to be considered when planning model adaptations. However, this work is not focused on GUIs, but in Custom Relationship Management (CRM) applications.
Next section presents the proposed GUI modelling and runtime adaptation approach, in which GUIs will be modelled as component-based architectures. These architecture models will be capable of evolving through model transformations in order to self-adapt according to the events detected by the system. 3
This paper focuses on applications with Graphical User Interfaces (GUI). In fact, our application models may contain any number of GUIs (e.g., one for each type of user). Each GUI, in turn, is built by assembling components, in particular COTS, which are well known in the CBSD literature. We call these components cotsgets for their similarity to the gadgets, widgets and other components frequently used in GUI development.
All the cotsgets included in each GUI, together with their behaviour and
the composition and dependency relations that may exist among them, conform
the GUI architecture. As we have opted for a MDE approach, we model GUI
architectures using a meta-model. This architecture meta-model can be seen as
an aggregation of three parts or subsets, namely: (
Firstly, the structural meta-model allows designers to model composition and dependency relationships among components. Dependencies are modelled by connecting component ports, which may provide or require any number of interfaces (sets of services). Secondly, the interaction meta-model is used for modelling the behaviour associated with user-level interactions, de ned in terms of the performed tasks. This meta-model includes concepts such as roles, subtasks, choreography, etc. Finally, the visual meta-model aims to describe the component behaviour from the point of view of its graphical representation on the user interface.
As a solution to the interface adaptation process, this work proposes a MDE
approach to GUI model evolution [11], where interface architectures are
considered as models capable of evolving at runtime. To achieve this, we have
implemented a two-stage process, where: (
Transformation phase
Architecture Modeli
Visual Interaction
Modeli Modeli Regeneration phase
Architecture Modelj abstract cotsget repository
Rules Transformer
Trader concrete cotsget repository
Architecture Modelj Visual Modelj
Structural Modelj
Interaction
Modelj Runtime Component
Modelj
The model-to-model transformation, implementing the rst stage of the
process, comprises a set of rules that de ne how to evolve the current abstract
interface architecture model depending on the events detected by the system.
As an output, the transformation generates a new abstract interface
architecture model, de ned in terms of the same meta-model as the input one (i.e., the
transformation evolves the input model rather than translating it from one
modelling language into another). For the sake of clarity, we have implemented this
transformation in two parts: (
Service 1..* 1 service
Structural metamodel Interaction metamodel Visual metamodel *
Interface 1..* provided Port r0e.q.*uired
* 0..1 * 1 endA Connector
1 endB ComponentAction 1..* ComponentActivity
PseudoState -type : pseudoType
1 State 1 currentState
ArchitectureModel 0..1 0..1 VisualBehaviuor * Component 0..1
ComplexComponent
*
SimpleComponentDefinition SimpleComponent
definition 1 InteractionBehaviour 1 InteractionActivity
StateMachine 1..*
Region 1..* Vertex *
* 1 target incoming * Transition 1 source outgoing * LaunchEvent launchedEvent 0..* eventLaunched
1 <<enumeration>> pseudoType -InitialState -JoinState -ForkState -FinalState
Event
* transtitionEvent 1 3.1
In this paper, we focus on the structural and the visual subsets of the architecture meta-model. The former enables the description of the software architecture in terms of its internal components and the connections existing among them. Similarly, the later enables the speci cation of the system visual behavior according to the expected runtime adaptation to certain user or application events. An excerpt of the architecture meta-model, showing the main concepts included in these two subsets, is shown in Figure 2.
ExecuteService
Create
Delete
Activate
Deactivate
The concept ArchitectureModel is the meta-model root, and it contains
component interfaces (Interface), simple component de nitions
(SimpleComponentDe nition), and all the events considered relevant for the system evolution
(Event ). Being de ned in the root of the model, these three kinds of elements
can be reused by all the other elements in the model. Both
ComplexComponent s and SimpleComponent s are subtypes of the abstract meta-class
Component. SimpleComponent s have a reference to their corresponding
SimpleComponentDe nition, while ComplexComponent s are de ned in terms of their internal
Component s, which can be, in turn, either simple or complex. Each Component
contains two behavioural descriptions: (
The StateMachines used to model the component visual behaviour may contain any number of orthogonal (i.e., concurrent) Regions which, in turn, may contain any number of States. Each State contains a ComponentActivity that models the work ow of ComponentActions that need to be executed when the component reaches that state. On the other hand, the Transitions between states are associated to one of the Event s de ned in the ArchitectureModel.
It is worth noting that this work is not intended not prescribe how to construct or deduce the state machine model that better describes each component visual evolution. Conversely, this work is focused on the model transformation supporting that evolution, which implementation is detailed next. 3.2
As previously stated, the runtime adaptation of the abstract inteface architecture model has been implemented by means of a model-to-model transformation (Figure 3). This transformation, de ned as a set of rules, takes the current interface model (AMA) and a detected event as its inputs, and generates an evolved interface model (AMB) as its output. Although the process seems quite straight forward, implementing it in one step is not that easy. Thus, for the sake of simplicity, we have splitted the transformation in two.
AMA
T1
T2
AMB
The rst part of the model transformation (T1) takes the interface architecture model and the event collected by the system as an input (AMA), and produces an intermediate interface architecture model (AMAi) where all the state machines being a ected by the collected event are appropriately updated. To achieve this, the transformation nds, for all the currentStates (one for each region in every state machines in every component), all the outgoing transitions being red by the collected event, and updates the currentState to the target of the red transition. Once the state machine models have been updated, the second model transformation (T2) is exectuted, taking the resulting AMAi model as an input. The role of this second transformation is to execute the ComponentActions contained in all the updated currentStates. As a result, a new interface architecture model (AMB) is generated. In this rst approach to model GUI evolution, we have de ned six types of actions that might be executed on a component (as a result of an event launched either by the user or by other component): Create, Delete, Activate, Deactivate, Execute Service and Launch Event (see Figure 2). Table 1 shows two example rules, each one belonging to one of the transformations. T
The rst of these example rules (RegionEvolution) belongs to T1 and is
related to Region elements. This rule only a ects those Regions containing a
transition that (
We have implemented our two model transformations using ATL (ATLAS Transformation Language) [14]. The ATL language is a Domain Speci c Language (DSL) aimed at describing model-to-model transformations. ATL is inspired on QVT and is a hybrid language that allows both declarative and imperative constructs. We decided to use ATL as its implementation is quite robust, and it is widely spread in use by the MDE community.
In this rst approach, random events are simulted and both transformations are manually launched one after the other. However, we are working on an improved implementation that automatically invokes both transformations every time an event is detected, making use of the ATL facilities for programatically executing transformations. 3.3
In order to illustrate the proposed approach, this section presents a case study on an example GUI runtime adaptation. It describes in depth a few steps of the adaptation process.
The example shows an interface architecture model composed by two graphical user interfaces (GUI1 and GUI2). Each of these GUIs has two simple components (C1 and C2). We will simulate an event that adds a Chat component to GUI1. This event will also produce the addition of a Chat component to GUI2. Finally, we will also simulate the generation of a new event that deletes GUI2 (and all its subcomponents) from the architecture model. Figure 4 shows a snapshot of the interface architecture model at the initial stage (ArchitectureModel0).
Events
(
C1
s1
(
Given the initial interface architecture model, when an event occurs the adaptation process starts. An example of this process is shown in Figure 5, which illustrates the model transformation steps executed after the GUI1.startChat event happens. As result, the rst transformation (T1) evolves the state machine associated to GUI1, changing its current state to s2, as indicated by the model. Then, when the T2 transformation is launched, it executes the Create(Chat) and LaunchEvent(GUI2.startChat) actions. The rst action implies the addition of a Chat component within GUI1, while the second action causes the launching of a GUI2.startChat event. We obtain Model B as result.
The adaptation process concludes when all the events haven processed. However, the GUI2.startChat event still needs to be attended. Thus, T1 is launched again and the GUI2 component changes its current state to s2. Finally, T2 executes the Create(Chat) action, resulting in the addition of a new Chat component within GUI2. In this case, we obtain Model C as a result.
Next, gure 6 shows another adaptation example starting from Model D (obtained by setting GUI2.closeComponents as the system currentEvent in Model C). In this case, we show the models involved in the adaptation process using the re ective model editor provided by the Eclipse Modeling Framework (EMF). In the rst step, T1 changes the current state of GUI2 to s3 and sets the `update' T2 T2
GUI1 C1 C2
GUI2 C1 C2
GGUUII11..ucuprdraetnetS=tatrtuee= s2 GGUUII11..ucuprdraetnetS=tafatels=e s1 currentEvent=null currentEvent=GUI1.startChat ArchitectureModel1i ArchitectureModel1 GUI1 C1 C2
GUI2 C1 C2 GUI1
GUI2 GUI1
GUI2
Chat GGUUCII11h..ucauptrdraetnetS=tafatels=e s2 currenGtEUvIeG2n.Uct=uI2nrr.uuelpnltdSattaete==truse2
GUGI2U.cI2u.rurepndtaStteat=ef=alsse1 ArchitectureModel2i currentEvent=GUI2.startChat ArchitectureModel2
GUI1
GUI2 Chat Chat
GUI2.currentState = s2
GUI2.update = false currentEvent=null
ArchitectureModel3 attribute to `true', as shown in Model Di (central column in gure 6). Then, T2 executes the Delete(all) action, producing the deletion of all the components in GUI2, including itself, as shown in Model E (right column in gure 6).
Fig. 6. From Model D to Model E 4
Nowadays, the increasingly growing number and complexity of Information Systems force developers to make them more exible, easy to adapt and evolve, and accessible for being manipulated at runtime. Graphical User Interfaces play a key role in this kind of systems, as they ease communication between applications and their end-users. Thus, it is necessary to obtain GUI dynamism and adaptability to user pro les and context. It is also very important to get this adaptation while the system is running, without stopping its execution and without re-modelling its components; in other words, to support a runtime adaptation process. However, most GUIs are still built based on traditional software development paradigms, which do not take into account that they have to be distributed, open, changeable and adaptable. In contrast, GUIs should be able to regenerate themselves at runtime depending on the context, the user interactions, and the changing application requirements.
In this paper, we have presented a MDE approach for the development of
adaptable graphical user interfaces. The proposed approach aims to build these
applications as assemblies of GUI components. These GUIs will be
architecture models that can evolve over time through model transformations with the
purpose of changing and adapting on system events. We describe a combined
MDE and CBSD proposal to GUI architecture modelling and runtime
adaptation. This approach revolves around (
As future work, we would like to develop a graphical tool using the Eclipse Graphical Modeling Framework (GMF) [15] in order to easily draw new GUI models conforming to the proposed architecture meta-model. We also plan to evaluate how the use of other MDE tools, in particular those enabling the inclusion of action semantics in meta-models (e.g., Kermeta [16] or AMMA [17, 18]) can help us improving our runtime adaptation process. Besides, we plan to enable the inclusion of alternative behaviours that can be appropriately activated depending, e.g., on previous GUI evolution records or on any relevant contextual information (i.e., enabling the adaptation not only of the interface models but also of the model-to-model transformation itself, also at runtime). Furthermore, we also plan to automate the adaptation process by making use of the ATL facilities for programatically executing the transformations.
Finally, we are interested in studying possible change detection in the interaction meta-model (not covered in this article) by means of automated co-evolution mechanisms and meta-model adaptations [19, 20].
Acknowledgments. This work has been supported by the EU (FEDER) and the Spanish MICINN under grant TIN2007-61497 and TIN2010-15588 project.