=Paper=
{{Paper
|id=Vol-445/paper-2
|storemode=property
|title=Applying Interaction Patterns: Towards a Model-Driven Approach for Rich Internet Applications Development
|pdfUrl=https://ceur-ws.org/Vol-445/02icwe2008ws-iwwost02-valverde.pdf
|volume=Vol-445
|dblpUrl=https://dblp.org/rec/conf/icwe/ValverdeP08
}}
==Applying Interaction Patterns: Towards a Model-Driven Approach for Rich Internet Applications Development==
https://ceur-ws.org/Vol-445/02icwe2008ws-iwwost02-valverde.pdf
ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008
Applying Interaction Patterns: Towards a Model-Driven Approach for Rich
Internet Applications Development
Francisco Valverde, Oscar Pastor
Department of Information Systems and Computation
Universidad Politécnica de Valencia, Spain
{fvalverde, opastor}@dsic.upv.es
Abstract with richer client UIs have been developed. For instance,
the Google Maps (maps.google.com) application is a well-
Recently, a wide array of Web Applications has known example that uses the RIA paradigm to request on
evolved to Rich Internet Applications (RIAs). This new demand map pictures.
application paradigm emphasizes the use of client-side In recent years, Web Engineering Methods [8] have
technologies in order to provide more responsive and improved Web Application development applying the
interactive Web Interfaces. The main contribution of this Model-Driven Engineering principles. These methods
work is an Interaction Model to specify the new semantics have provided promising results to enhance the develop-
to deal with the Model-Driven RIA development. This ment of traditional Web Applications. However, they do
model is made up of Interaction Patterns that describe, not properly support the interaction and presentation re-
from a conceptual point of view, a generic solution for quirements [1] and the behavior expressiveness [3] re-
a common user-system interaction. Following the HCI quired by RIAs. Firstly, the interaction between the users
principles, this model has two views: 1) an Abstract view and the system, which is mainly implemented in the cli-
made up of Abstract Interaction Patterns that describe the ent-side, is not described with the same detail than the
interaction without taking into account technological de- system functionality and navigation. And secondly, there
tails and, 2) a Concrete view made up of RIA Interaction is not a clear distinction between the interaction, which
Patterns which specify the new interaction and interface describes the set of actions that the user can perform to-
requirements. Applying this Interaction Model within gether with the Web System, and the interface, which
a Model-Driven software process, a functional RIA can be constitutes the graphic elements that support that interac-
obtained. Finally, to illustrate this approach, two RIA tion (buttons, grids, multimedia components, etc.).
Interaction Patterns are described. Regarding the HCI community, several approaches
have been proposed to specify the interaction between the
1. Introduction user and the system. A common agreement [12] is to de-
fine two abstraction views in order to model the UI: an
Latest Web Applications are providing rich interfaces Abstract view to describe interaction without taking into
with a more intuitive interaction experience for the end- account technological issues and a Concrete view to deal
user. The traditional Web Application paradigm implies with the specific technological requirements. This ap-
that for each user interaction (for instance, a button click) proach is more flexible than the definition of a single
the client browser must request a new Web Page. In order Presentation Model that has traditionally been proposed
to improve the interaction, a reasonable approach is to by several Web Engineering Methods.
request only the new content required and to avoid the full The main objective of this work is to define a Model-
page refreshing. As a result, from the end-user perspec- Driven approach to support the RIA development. Since
tive, the interaction is automatically performed. The Web the main improvements in RIAs are defined in the Presen-
Applications that use this new paradigm are called Rich tation Layer, the models to introduce must address the
Internet Applications (RIAs) [2]. Around the RIAs devel- RIA interaction specification. Taking into account the
opment field have arisen several technologies (Adobe HCI principles, an Interaction Model is proposed that de-
Flex, Microsoft SilverLight, OpenLaszlo etc.), which use fines the RIA Presentation layer from the user-system
AJAX, REST Services or JavaScript frameworks. Using interaction point of view. In order to define this Interac-
these new development technologies, Web Applications tion Model, the Interaction Pattern (IP) concept has been
introduced. An Interaction Pattern describes a solution for
7
ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008
a common user-system interaction in terms of the Problem actions (Interaction Presentation) to define RIA interface
Space (Conceptual Models) components.
This paper is focused on the Concrete view in which The approaches mentioned above, propose mainly so-
the semantics to produce RIA interfaces are introduced. lutions for supporting the data synchronization and the
Therefore, a RIA Interaction Pattern describes precisely specification of the client-side behavioral aspects. Though
an interaction which is used in the RIA domain. Using these approaches point out a key issue, our approach must
these patterns as guidelines, a set of transformation rules also address the richer RIA UIs, which are defined using
can be defined to produce the RIA interface code. To il- new graphical widgets, and the complex interactions be-
lustrate this approach, two common RIA Patterns (Auto tween the server and the client rich interface. These new
Complete and Information Summary) are defined using improvements have widely been described by the RIA
the Interaction Model proposed. development community using UI Design Patterns [15].
The rest of the paper is structured as follows: Section 2 Therefore, the final goal of this work, is to define how the
describes the background of this work and the related knowledge from those patterns, can be introduced in
work regarding RIA development in the Web Engineering a Model-Driven development process.
community. Section 3 presents an overview of the Model-
Driven approach proposed. Next, section 4 describes 3. A Model-driven approach to produce RIAs
briefly the Abstract view of the Interaction Model. Section
5 is focus on the description of the RIA Interaction Model. When an Information System is specified, the interac-
Finally, the concluding remarks are stated. tion is usually described in different models. For example,
several Web Engineering methods have described naviga-
2. Background and Related Work tional and data retrieval interactions inside the Naviga-
tional Model. However, some aspects related with the
The use of patterns at modeling level is an approach interface of those interactions, are described in a Presenta-
that has been previously applied in the context of our re- tion Model in where aesthetics requirements (colors, fonts,
search group. For instance, the Presentation Model for the etc.) are also included. This approach to define a RIA
OO-Method [9] software production method was defined Presentation Layer is not flexible enough, because implies
using the JUST-UI [11] approach. JUST-UI proposes to introduce changes in different models related to differ-
a language made up of Conceptual Modeling patterns for ent concerns. Our approach to model the RIA Presentation
the specification of UIs and code generation techniques. Layer introduces a single model, the Interaction Model, to
The work presented in this paper, reuses the concepts de- define all the interaction requirements.
fined in the JUST-UI approach and previous experiences In the context of this work, the interaction is defined as
in the OOWS Web Engineering method [10], to define the the actions that take place between a human user and the
Abstract View of the Interaction Model. Therefore, the software system in order to perform a task. Therefore, the
main contribution of this work is to extend those previous interaction comprises both the UI specification (the inter-
approaches, with a set of Interaction Patterns to support face components) and the integration with the system
RIA development. functionality (the UI-system communication interface). To
Several works in the Web Engineering field have pro- model these two requirements, an Interaction Model is
posed methodological extensions to face the RIA devel- introduced as Fig.1 illustrates. The aesthetic requirements
opment. Firstly, Bozzon et al. [5] extend the WEBML of the UI are not considered in this model.
method to support the RIAs specification. The proposed The Abstract view of the Interaction Model is made up
extensions allow the definition of which data, operations, of two main elements (Fig. 1 up): tasks and Abstract In-
hypertext links and page content must be processed by the teraction Patterns (AIPs). The different users have visibil-
client-side. In the context of the OOHDM method, Urbieta ity over a set of tasks that describes the interactions avail-
et al. [6] propose and approach to designing RIA inter- able. The basic units to specify these tasks are the AIPs.
faces, dealing with the separation of the interface structure An AIP models two kinds of user-system interactions:
and behavior. This work uses an aspect-oriented perspec- population retrieval or service execution. It is important to
tive, to combine different concerns related to the interface mention that the specific technological details (UI compo-
composition. nents, events) are not defined with these patterns.
In contrast, several works have addressed the RIA de- The AIPs are specialized in Concrete Interaction Pat-
velopment using HCI principles. Firstly, a metamodel for terns that define the Concrete view of the Interaction
defining RIA UIs from an Abstract Interface Model is Model. These Concrete patterns address the technological
proposed in [4]. And secondly, the RUX-model [7] pro- details related to the interaction: the specific interface
poses how to define at Concrete level the time-related components, the available events, the communication
behaviors (Temporal Presentation) and the event-response mechanisms etc. Different sets of Concrete IPs can be
8
ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008
defined to specify the requirements of several technologi- this Interaction Model inside the OO-Method develop-
cal platforms. In this work, the RIA Interaction Patterns, ment process, a final functional RIA can be obtained.
which extend the AIPs with semantics from the RIA do-
main, have been introduced. However, the same approach 4. The Abstract Interaction Model
can be used to define HTML IPs (as Fig. 1 illustrates) or
Mobile device IPs. This approach is very flexible because Each type of user has a set of tasks that describe the
the analyst can firstly describe abstract interactions and available interactions. For instance, in an e-commerce
later, those interactions can be specialized in terms of sev- application, the tasks available may be ‘Log in to the sys-
eral technological platforms. tem’ or ‘Checkout the order’ among others. These tasks
are defined in the Interaction Model using an Interaction
Map associated to each user. This map is a directed graph,
whose nodes represent the tasks available, and whose arcs
represent the transitions between tasks. The two main ob-
jectives of the Interaction Map are:
• To define which interactions are available for each
user, or in other words, to restrict the access to spe-
cific interactions.
• To provide a global view, very close to a Naviga-
tional Map, about how the user can access to the sys-
tem.
From the analysis of several UIs in different platforms
and devices, we have detected a set of generic interactions
which can be abstracted as technologically-independent
Figure 1. Model-driven approach overview. patterns. The different tasks can be described as an aggre-
gation of one or more of these Abstract Interaction Pat-
From both the Abstract and the Concrete view of the terns (AIPs). Therefore, the main objective of AIPs is to
Interaction Model, a set of model-to-code transformations provide a detailed description of each task defined in the
generate the final client UI. This code can be divided into Interaction Map. An AIP describes the interaction in terms
two parts: 1) the final RIA Interface implemented using of two main communication flows between the users and
a JavaScript UI framework (EXT-JS, Google Web Tool- the Information System: a) a population retrieval flow,
kit) or a RIA technology (Adobe Flex, Open Laszlo, etc.) that provides information from the system to the user, and
and 2) a business façade which communicates with the b) a service execution flow started by the user, which per-
server- side by means of XML Messages using AJAX and forms a change of the state of the Information System.
REST Services. Nevertheless, some interoperability code Considering both flows, two main AIPs can be defined:
should be added to the business façade. • Population AIP: it represents an information retrieval
In order to integrate this approach with the Information from the system. The Population AIP is defined as
System two requirements must be satisfied: a view over the model that represents the system data
entities, for example an UML Class Diagram.
1. The Information System must have been described • Service AIP: it abstracts a service (for example
using a Conceptual Model that represents the under- a Class method or a Web Service operation) that
lying functionality. modifies the state of the system. The Service AIP is
2. The Business Logic must be accessible by means of defined as a view over the arguments from one ser-
an interoperable XML API. vice. For each argument from the service signature,
an Input Argument AIP is created to insert the corre-
In the OO-Method development process these two re- sponding value.
quirements have been fulfilled. Firstly, the OO-Method is
made up of a set of Conceptual Models from which the Since all the interaction specification with a system
system functionality can be generated. And secondly, be- cannot be defined using only the Population and the Ser-
cause an approach to produce XML Web Services from vice AIPs, auxiliary AIPs are introduce to constraint the
those models [17] have been proposed. Therefore, using behavior and/or to refine more accurately this two main
interactions. Two examples are:
9
ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008
Figure 2. Metamodels for the RIA Interaction Patterns.
• Filter AIP: By default, a Population AIP retrieves all Interaction Patterns that extends the same abstract interac-
the information that is defined by the interaction. tion: for instance, a Population AIP can be represented as
This pattern defines a well-formed formula that re- a data table, as several dynamic text items or as an edit-
stricts the information to be retrieved. able grid. For that reason, the analyst must select for each
• Defined Selection AIP: this pattern defines a set of AIP, the RIA Interaction Pattern more suitable for the
values associated to an Input Argument AIP. Hence, interaction to be modelled.
the user can only choose, from the provided list, one According to previous works [14], [11], the Interaction
value to fill the input. Patterns have been defined using a pattern template with
these sections: 1) Problem: the problem that the pattern is
Currently, ten AIPs which can be consulted in [16] intended to solve, 2) Context: in which scenario is rec-
have been detected. These patterns define an abstract pat- ommended to use the pattern, 3) Solution: a brief descrip-
tern language to model the interaction. From this Abstract tion of the proposed solution and, 4) Example: a real sce-
Interaction Model a preliminary and functional UI can be nario to show how the pattern can be applied.
generated. For example, a direct transformation from However to apply these patterns in a Model-Driven de-
a platform-independent model (PIM) [10] can be applied velopment process, a more precise description is required.
to generate a Web Application interface. Nevertheless, to For that reason, three more sections are introduced to the
take advantage of the rich features provided by the RIA pattern template:
development technologies, a RIA Interaction Model is
recommended. • Metamodel: it defines using a metamodelling lan-
guage the concepts that the pattern abstracts (See
5. The RIA Interaction Model Fig 2.). This representation must be used to create
specific instances of the pattern.
The Web Development Community [15] and the UI • Metamodel Specification: it describes the different
design literature [13] have defined several patterns to im- entities, relationships and properties defined in the
prove the RIA development. These patterns are validated metamodel. Specific constraints about the metamodel
solutions because they have been applied in real-world must be explained here.
examples. The proposal of this work is to apply the • Interaction semantics: it specifies precisely the inter-
knowledge described in these patterns in order to define action expected when the pattern is applied. There-
a Concrete view for the Interaction Model: the RIA Inter- fore, it describes the interface components, the inter-
action Model. As the Abstract view, this model is made up face events and the communication with the business
of Interaction Patterns but fitted into the RIA domain. logic. Additional models, as UML Interaction dia-
RIA Interaction Patterns are defined as a specialization grams, can be used to explain the semantics.
from an AIP, with the aim of extending the interaction
semantics required for RIA development. In these pat- Using this template, the RIA Interaction Patterns can
terns, technological concepts related to the RIAs are in- be applied as guidelines to define a Model-Driven code
troduced; for example the client-request and server- generation process. On the one hand, the metamodel de-
response flow or which widget implements the interaction. scribes the conceptual primitives from which the trans-
In addition, an AIP can be specialized to different RIA formation rules must be defined. On the other hand, the
10
ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008
interaction semantics provide the translation from the the user deletes the first set of characters, the population
metamodel to the expected code. To better illustrate the request interaction must be performed again.
concepts presented here, two RIA Interaction Patterns are
described next. 5.2. Information Summary Pattern
5.1. Auto Complete Pattern Problem: the user receives high amount of information
but he only wants to focus on a single piece of informa-
Problem: the user must select or introduce a text value tion.
from a huge defined list. Context: the data shown to the user is composed by
Context: there is a huge list of possible text values to be several pieces of information with a high density (for in-
chosen by the user and it has to introduce one without stance, large texts). However, the user wants to see only
mistakes. one piece of information at the same time.
Solution: as the user writes the text, a dropdown list Solution: provide a brief summary, i.e. a single text
shows the values from the list that match with the intro- line, for each piece of information. When the user selects
duced characters. Then, the user selects the desired value this summary, the rest of the information is displayed. If
or, considering the reported information, he introduces the the user selects another summary, the previous informa-
correct text value. tion is hidden again.
Example: in a form for uploading an academic paper, Example: the user wants to find the latest news about
the user must input the author’s full name that is stored in computer technology. Since there are a huge amount of
the system. The user knows the first name but he does not news, to simplify this task only the headlines are shown.
remember the last name. Applying the Auto Complete When the user selects a particular headline the rest of the
pattern, all the system authors that match with the first information is displayed. The Fig. 4 illustrates this pattern.
name introduced by the user will be shown. The figure
below shows the expected UI.
Figure 4. UI for the Information Summary Pattern.
Figure 3. UI for the Auto Complete Pattern.
Metamodel Specification: this pattern extends a Popu-
Metamodel Specification: this pattern is specialized lation AIP (see Fig. 2. right) that must have two attributes
from an Argument Input AIP (see Fig. 2 left). To define defined at least: one for describing the summary and an-
this pattern a Defined List AIP linked to a Population AIP other for recovering the detailed information. To specify
is needed to constraint all the possible values that the user the summary information, a new relationship (DefinedBy)
can introduce. These values are represented by the only is required between the pattern and an attribute from the
attribute associated to the Population AIP. When the user Population AIP. A DetailEvent property is added to define
types a set of characters, a Filter AIP establishes auto- which UI event will trigger the display of the detailed in-
matically a string-like condition over the defined Popula- formation.
tion AIP. The filtering result defines the available values Interaction semantics: The client side must request all
for the Defined List AIP. the information defined by the Population AIP. This in-
Interaction semantics: the widget that is used for in- formation is stored and, for each information item re-
serting the text value (an input textbox), must raise an trieved, only the summary attribute is shown. When the
event to detect that the user has introduced a set of charac- user triggers the event attached to the summary text, the
ters. When this event is detected by the client interface, an rest of the information will be shown without any addi-
interaction requesting the population values is sent to the tional request. When the user selects another summary,
server. Next, the client receives the data and renders the the previous information item must be hidden again.
received values as a drop-down list widget. If the user
introduces more characters, the values are filtered in the
client interface and no new request is needed. However, if
11
ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008
6. Concluding Remarks [6] M. Urbieta, G. Rossi, J. Ginzburg, and D. Schwabe "De-
signing the Interface of Rich Internet Applications," in
Fifth Latin American Web Congress (LA-WEB) Santiago
In this work, a Model-Driven approach to improve the de Chile, 2007.
RIA development has been presented. This approach in- [7] M. Linaje, J. C. Preciado, and F. Sánchez-Figueroa, "Engi-
troduces an Interaction Model, with uses the concept of neering Rich Internet Application User Interfaces over
RIA Interaction Pattern to capture the new semantics re- Legacy Web Models," IEEE Internet Computing, pp. 53-
quired. The use of Interaction Patterns provides two ad- 59, 2007.
vantages: [8] G. Rossi, O. Pastor, D. Schwabe, and L. Olsina, Web En-
gineering: Modelling and Implementing Web Applications:
• Since they have been defined using real world exam- Springer, 2008.
[9] O. Pastor and J. C. Molina, Model-Driven Architecture in
ples, the analyst is dealing at modeling level with
Practice. A Software Production Environment Based on
concepts close to the final UI. Conceptual Modelling: Springer, 2007.
• They provide a mechanism to interaction knowledge [10] F. Valverde, P. Valderas, J. Fons, and O. Pastor. A MDA-
reuse. Hence, an abstracted interaction can be im- Based Environment for Web Applications Development:
ported to another Model-Driven approaches. From Conceptual Models to Code. in 6th International
Workshop on Web-Oriented Software Technologies. 2007.
With the goal of using industrially the described RIA Como (Italy).
Interaction Patterns, a Model-based tool to define the In- [11] P. J. Molina, S. Meliá, and Ó. Pastor, "JUST-UI: A User
teraction Model and to generate the RIA related code is Interface Specification Model" in Proceedings of Com-
puter Aided Design of User Interfaces, Valenciennes,
needed. Further work, will define the tool support for
Francia., 2002
building the Interaction Model presented as well as the [12] G. Calvary, J. Coutaz, D. Thevenin, Q. Limbourg, L.
model transformation rules. Once the proposed environ- Bouillon, and J. Vanderdonckt, A Unifying Reference
ment has been developed, it should be validated by means Framework for multi-target user interfaces. Interacting
of several case studies. These case studies will provide an with Computers, 2003.
interesting feedback about the most suitable patterns to [13] J. Tidwell, Designing Interfaces: O'Reilly Media, 2005
implement RIAs. [14] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design
The final step is to include the proposed Interaction Patterns: Elements of Reusable Object-Oriented Software:
Model inside the OO-Method software generation proc- Addison Wesley, 1995.
[15] Yahoo Design Pattern Library.
ess. As a result a complete RIA, which satisfies the ex-
http://developer.yahoo.com/ypatterns/
pected interaction requirements, can be generated. [16] F. Valverde, J. I. Panach, and Ó. Pastor, "An Abstract In-
teraction Model for a MDA Software Production Method,"
Acknowledgements in 26th International Conference on Conceptual Modeling
(Posters). Auckland, New Zeland, 2007.
This work has been developed with the support of [17] M. Ruíz, F. Valverde, and V. Pelechano. Desarrollo de
MEC under the project SESAMO TIN2007-62894. servicios Web en un método de generación de código diri-
gido por modelos. in II Jornadas Científico-Técnicas en
Servicios Web. 2006. Santiago de Compostela, Spain.
References
[1] J. C. Preciado, M. Linaje, F. Sánchez, and S. Comai, "Ne-
cessity of methodologies to model Rich Internet Applica-
tions," in 7th IEEE International Symposium on Web Site
Evolution Budapest, Hungary, 2005.
[2] J. Duhl, " White Paper: Rich Internet Applicattions - IDC
Report," 2003.
[3] S. Comai and G. T. Carughi, "A Behavioral Model for
Rich Internet Applications," in 7th International Confer-
ence in Web Engineering Como, Italy, 2007.
[4] F. J. M. Ruiz, "A Development Method for User Interfaces
of Rich Internet Applications" DEA Thesis. Université ca-
tholique de Louvain, 2007.
[5] A. Bozzon and S. Comai, "Conceptual Modeling and Code
Generation for Rich Internet Applications," in 6th Interna-
tional Conference on Web Engineering (ICWE) California,
United States, 2006.
12