=Paper=
{{Paper
|id=Vol-455/paper-4
|storemode=property
|title=Viewpoint Synchronization of UWE Models
|pdfUrl=https://ceur-ws.org/Vol-455/paper04.pdf
|volume=Vol-455
}}
==Viewpoint Synchronization of UWE Models==
https://ceur-ws.org/Vol-455/paper04.pdf
Viewpoint Synchronization of UWE Models
Daniel Ruiz-González1 , Nora Koch2 , Christian Kroiss2 , José-Raúl Romero3 , and
Antonio Vallecillo1
1
GISUM/Atenea Research Group. Universidad de Málaga, Spain
2
Web Engineering Group, Ludwig-Maximilians-Universität München, Germany
3
Atenea Research Group. Universidad de Córdoba, Spain
{daniruiz,av}@lcc.uma.es, {kochn,kroiss}@pst.ifi.lmu.de,
jrromero@uco.es
Abstract. Viewpoint modeling has demonstrated to be an effective approach for
specifying complex software systems by means of a set of independent views
and correspondences between them. As any other software system, a Web ap-
plication evolves during its lifetime, and its specifications change to meet new
requirements or to adapt to business changes. As a consequence, view elements
and correspondences can be added, modified or removed, which may cause syn-
chronization and consistency problems in the system specifications. UWE is a
Model-Driven Web Engineering approach that uses several viewpoints for ad-
dressing the different concerns involved in the specification and development of
Web systems. In this paper we examine the explicit and partially automatic spec-
ification of correspondences between UWE views, and present a tool for helping
synchronize them under the presence of changes to the view elements.
1 Introduction
Viewpoint modeling is currently seen as an effective technique for specifying complex
software systems by means of a set of viewpoints and correspondences between their el-
ements. Each viewpoint focuses on a particular aspect of the system, abstracting away
from the rest of the concerns. Correspondences specify the relationships between the
elements in the different views, together with the constraints that guarantee the consis-
tency among these elements.
During its life cycle, a software system evolves and its specification is subject to
changes in order to meet new requirements or to adapt to business changes. Thus de-
signers may have to add, remove and/or modify elements in the views, or in the corre-
spondences. One of the consequences of adopting a multi-viewpoint approach to system
design is that description of the entities that appear in different views must be consistent.
Thus, we should always keep them synchronized. One possible solution is the adoption
and implementation of synchronization mechanisms able to propagate the changes on
the related views. In particular, a modification in a view may induce a modification in
another view or, alternatively, a set of correspondences may need to be adapted.
Web Engineering is a specific discipline in which both Model-Driven Software De-
velopment and Viewpoint Modeling can be successfully applied. For example, existing
Model-Driven Web Engineering (MDWE) approaches such as OO-H, UWE, OOWS,
46
Viewpoint Synchronization of UWE Models 47
WebML, MIDAS or beContent (see [1] for a comprehensive survey covering the major-
ity of these proposals), already provide a set of suitable methods and tools for the design
and development of most kinds of Web applications. In particular, the UML-based Web
Engineering approach (UWE) is a well-known MDWE methodology that defines four
basic viewpoints on a Web system for structuring its specifications: Content, Naviga-
tion, Business Process and Presentation. However, very few MDWE approaches provide
notations and mechanisms for establishing correspondences between their viewpoints,
or for synchronizing them when they evolve.
In this paper we examine the explicit specification of correspondences between
UWE views, and present a tool for synchronizing them under the presence of changes
to the view elements or to the set of correspondences. Correspondences between UWE
model elements can either be derived automatically from relationships at metamodel
level (intensional approach) or specified individually for model elements (extensional
approach). We use classes and dependencies of the Unified Modeling Language (UML),
respectively, for expressing and visualizing the correspondences between UWE views.
Once the correspondences are specified, the possible changes are propagated using
Beanbag [2], a very flexible and efficient notation and engine for synchronizing gen-
eral data dictionaries.
The structure of this paper is as follows. After this introduction, Section 2 presents
some preliminaries about viewpoint modeling and the synchronization process we pro-
pose. Section 3 gives an overview of UWE. Then, Section 4 presents our proposal for
specifying correspondences between UWE views. Section 5 describes how the UWE
views can be synchronized using the information provided by the correspondences, and
the tool we have developed to support the change propagation. Finally, Sections 6 and 7
discuss some related works and present some conclusions, respectively.
2 Viewpoint Modeling and Synchronization
One way to cope with the inherent complexity of large distributed software systems is
by dividing the design activity according to several areas of concerns, or viewpoints,
each one focusing on a specific aspect of the system, as described in IEEE Std. 1471 [3].
This approach has been adopted by most MDWE methodologies that propose the con-
struction of different views (i.e., models) which comprise at least a content model, a
navigation and a presentation model — although naming them differently. Each view-
point addresses one particular concern, and normally uses its own specific (viewpoint)
language, which is defined in terms of a set of concepts specific to that concern, their
relationships, and their well-formedness rules. A view is a representation of the whole
system from the perspective of a viewpoint.
Although separately specified, developed and maintained to simplify reasoning about
the complete system specifications, viewpoints are not completely independent: ele-
ments in each view need to be related to elements in the other views in order to ensure
the consistency and completeness of the global specifications. Such relationships are
described in terms of correspondences [4].
In a viewpoint modeling context, viewpoint languages are defined in terms of meta-
models, and the views are then models that conform to these metamodels. Correspon-
48 D. Ruiz-González, N. Koch, J.R. Romero, C. Kroiss, A. Vallecillo
dences are defined as models, too, which conform to the appropriate metamodels. Such
Correspondence metamodels can be defined either ad-hoc (see, e.g., [5]) or use a model
transformation language in order to define viewpoint correspondences as model trans-
formations (see, e.g., [6]).
System specifications can evolve due to changes in the requirements or for many
other reasons. Thus, the designer may need to perform changes in the views by mod-
ifying, for example, one of their elements. Since the system is described as a set of
dependent views, any action on a view might cause a similar or a different action on
other views. If views are not explicitly related by correspondences, the modeler will
not be able to easily know which elements in the views have some relationship with the
modified element. Since any action on a model element can be affected by a correspon-
dence, inconsistencies need to be found and solved.
There are several problems that may happen when trying to maintain the synchro-
nization and consistency between views, once a change has happened (either in an
element of a view, or in a correspondence, see [7]). Sometimes the consistency can
be easily restored if the correspondences provide enough information to propagate the
change.
This is why we need an automated process for change propagation. Hence, we pro-
pose to implement the following synchronization process. Fig. 1 shows an overview of
the process, where some of the actions are further detailed in sub-activity diagrams
as shown e.g. in Fig. 2. The process starts from a set of models with the different
views as for example the views presented in the next section (Sec. 3), the tool auto-
matically builds the initial set of correspondences between the elements in the separate
views. These extensional correspondences could be derived from a set of intensional
correspondences defined in the corresponding metamodel (see Sec. 4). In addition, the
system designer can define more correspondences depending on the particular require-
ments of the application.
[add more correspondences]
Build views of Generate Specify Check "with
correspondences correspondences [else]
model Beanbag"
automatically manually
Change/Improve [else] Accept/Reject Visualize
views of model
suggestions annotations
& corresp.
[no more improvements]
Fig. 1. Overview of the synchronization process.
The consistency of the complete system specification can be checked based on the
different models (each one representing a different view) and the sets of correspon-
dences between their elements. The refined checking process (Check ”with Beanbag”)
is depicted in Fig. 2, and further detailed in Sec. 5.2.
Viewpoint Synchronization of UWE Models 49
: Model&Corresp
Transform Transform
UML2Beanbag Run Beanbag Beanbag2UML
: Annotated-Model&Corresp
Fig. 2. Consistency checking process detailing the ”Check with Beanbag” action of Fig. 1.
The result of this process is a set of annotations which are added to the original
model. These annotations are represented by means of stereotypes which decorate el-
ements of the model (including its correspondences) indicating that for these elements
the synchronization imposed by a correspondence has been broken, together with the
proposed changes to restore it. The user can then visualize the annotated model, being
able to modify some of the proposed changes if required. Once the designer is happy
with all the proposed changes, another process simply traverses all model elements and
implements the proposed changes, removing the annotations.
3 UML-based Web Engineering
UML-based Web Engineering (UWE) is a method for systematic and model-driven de-
velopment of Web applications. It follows the principle of “separation of concerns” by
modeling the content, the navigation structure, the business processes, and the presen-
tation of a Web application separately. UWE implements a model-driven development
process by defining model transformations of different types to derive platform specific
models from platform independent models and to generate running programs [8]. UWE
relies on standards: its modeling language is defined by an extension of the UML meta-
model [9] and mapped to a so-called UML profile; its transformations are defined using
(de-facto) standard transformation languages like ATL [10].
In order to illustrate UWE’s approach and our proposal we will use a running ex-
ample, the Simple Address Book [11]. It models an application that manages an address
book of contacts. Each contact contains a name, two phone numbers (business and pri-
vate), two postal addresses (business and private), and one e-mail address. The system
should offer a page with an introductory text and the list of contacts in the agenda,
which is stored in a database. For each object the set of its non-empty attributes values
is displayed. The address book Web application supports browsing of contacts, adding
new contacts, editing and removing of contacts.
The content model in UWE (represented by a UML class diagram, see Fig. 3) pro-
vides the specification of the domain-relevant information for the Web application. The
content model of our example contains contacts that are organized in an address book.
Based on the content model, the navigation model of the Web application is built
(Fig. 4) by a model transformation and a set of successive refinements. This model
specifies the hypertext structure of the system, which is described in terms of nodes and
50 D. Ruiz-González, N. Koch, J.R. Romero, C. Kroiss, A. Vallecillo
AddressBook
id : Long
contacts *
categories Contact Address
* privateAddress
Category id : Long id : Long
category contacts firstName : String 0..1 name : String
name : String lastName : String postalCode : String
0..1 * businessAddress city : String
id : Long email : String
phonePrivate : String 0..1 country : String
phoneBusiness : String
Fig. 3. Content model of the AddressBook example.
links. Classes stereotyped ¿navigationClassÀ (like AddressBook or Contact) represent
navigable nodes for information retrieval; classes stereotyped ¿processClassÀ (such
as AddContact and RemoveContact) define navigation nodes where transactions may
occur. Direct links are modeled by associations stereotyped ¿navigationLinkÀ (omitted
in Fig. 4); in particular, associations stereotyped ¿processLinkÀ lead to or leave from
process classes. Some special navigation nodes are used to organize links. For example,
several instances of a navigation class are reached by ¿indexÀ classes (like ContactList)
and choices of links are represented by ¿menuÀ classes, like ContactMenu (see Fig. 4).
In the address book application, users can navigate from the homepage either, using
an index with the contacts, to view the information associated to a selected contact, or
along another navigation path to add a new contact to the database.
<> <> <>
AddressBook
<> <>
AddContact ContactList
<>
businessAddress
<> <> <>
Contact privateAddress Address
<>
{guard = "outcome == 'CANCEL'"}
<> <