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 application 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 synchronization and consistency problems in the system specifications. UWE is a Model-Driven Web Engineering approach that uses several viewpoints for addressing the different concerns involved in the specification and development of Web systems. In this paper we examine the explicit and partially automatic specification of correspondences between UWE views, and present a tool for helping synchronize them under the presence of changes to the view elements.
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 elements. 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 consistency 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 designers may have to add, remove and/or modify elements in the views, or in the correspondences. 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
Development and Viewpoint Modeling can be successfully applied. For example, existing
Model-Driven Web Engineering (MDWE) approaches such as OO-H, UWE, OOWS,
WebML, MIDAS or beContent (see [
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 [
The structure of this paper is as follows. After this introduction, Section 2 presents some preliminaries about viewpoint modeling and the synchronization process we propose. 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
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 [
Although separately specified, developed and maintained to simplify reasoning about
the complete system specifications, viewpoints are not completely independent:
elements 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 [
In a viewpoint modeling context, viewpoint languages are defined in terms of
metamodels, and the views are then models that conform to these metamodels.
Correspondences are defined as models, too, which conform to the appropriate metamodels. Such
Correspondence metamodels can be defined either ad-hoc (see, e.g., [
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 modifying, 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 correspondence, inconsistencies need to be found and solved.
There are several problems that may happen when trying to maintain the
synchronization and consistency between views, once a change has happened (either in an
element of a view, or in a correspondence, see [
This is why we need an automated process for change propagation. Hence, we propose 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 automatically 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 requirements of the application.
Build views of model
Generate correspondences automatically
Specify correspondences manually [add more correspondences] [else]
Check "with Beanbag" Change/Improve views of model & corresp.
[else]
Accept/Reject suggestions [no more improvements]
Visualize annotations
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 correspondences between their elements. The refined checking process (Check ”with Beanbag”) is depicted in Fig. 2, and further detailed in Sec. 5.2.
: Model&Corresp
Transform UML2Beanbag Run Beanbag
Transform
Beanbag2UML : Annotated-Model&Corresp
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 elements 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 (UWE) is a method for systematic and model-driven
development of Web applications. It follows the principle of “separation of concerns” by
modeling the content, the navigation structure, the business processes, and the
presentation 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 [
In order to illustrate UWE’s approach and our proposal we will use a running
example, the Simple Address Book [
The content model in UWE (represented by a UML class diagram, see Fig. 3) provides 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 Cat*egocryategories name : String c0a..t1egory id : Long 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.
<<processLink>> <<processClass>>
AddContact <<processLink>> <<navigationClass>>
AddressBook <<index>>
ContactList <<processLink>> <<navigationClass>>
Contact businessAddress privateAddress
Each process class in the navigation model is refined by a process structure (described in a class diagram) defining additional classes used in the process, and by a process flow (described by a UML activity diagram) modeling the data and control flow <<processLink>> <<presentationGroup>>
Contact <<text>> : NameField <<presentationGroup>> : BusinessAddressPanel <<presentationGroup>> : BusinessAddress <<text>> : email <<presentationGroup>> : PrivateAddressPanel <<presentationGroup>>
: PrivateAddress <<presentationGroup>>
: ButtonPanel <<anchor>> : RemoveContact <<anchor>> : EditContact of the process. For example, user interactions with the web application are modeled by UML actions stereotyped as ¿userActionÀ.
Finally, the presentation model provides an abstract view of the user interface (UI) of the application, where concrete aspects such as colors and fonts of UI elements are not considered. A structured class stereotyped as ¿presentationGroupÀ models the presentation of each navigation class. UI elements (e.g., text, images, etc.) contained in presentation classes are modeled by classes stereotyped accordingly (¿textÀ, ¿imageÀ, etc.), indicating the abstract type of the widgets to use. Presentation classes can be nested, modeling the hierarchical structural of Web pages. A presentation class that is not contained in another represents a top-level page of the Web application. In addition, a presentation class is defined for each user action. The presentation model therefore has the form of a forest of presentation classes. An excerpt of the presentation model of the address book application is shown in Fig. 5. 4
The objective is to build the correspondence model that comprises a set of correspondences between model elements of a pair of views. The specification of the correspondences is not a difficult but a tedious task. However the work is worth as it allows for synchronization of the different views of a model. It is then an unavoidable work. Therefore our focus is on the automation of the correspondence specification process. This is particularly easy in UWE due to the characteristics of its metamodel. There are then basically two approaches to model correspondences between the views of a system: extensional and intensional.
4.1
Extensional models describe correspondences between the particular elements of the
views. In UWE, views are expressed as UML models. The UML 2 language defines
abstraction dependencies, possibly constrained by OCL statements, as the natural
mechanism to model a relationship that relates two elements or sets of elements that represent
the same concept at different levels of abstraction or from different viewpoints [
Moreover, we mentioned above the importance of endowing correspondence
specifications with enough information to propagate the changes. In some approaches this
is accomplished by adding a constraint, which establishes a relationship that must
hold between the elements related by the correspondence. OCL can be the natural
language of choice here, enabling a very flexible and expressive way to specify such
constraints [
A more simple, pragmatic and practical solution is based on the characterization of the kinds of correspondences that are normally used, and the “componentization” of their behavior so that they can be easily re-used. For instance, one common kind of correspondence found in most UML models establishes that the two related elements should have the same name. Another usual correspondence dictates that an element in a view should have a subset of the attributes of the related element in the other view. For example, this is found in UWE models when relating an element in the Content model with its counterpart in the Presentation model: the attributes of the latter need to be a subset of the attributes of the former (no new attributes can be added in the presentation view).
Content::Class
Content::Class Content::Association
Navigation::Link BusinessProcess::UserAction
Navigation::NavigationClass Navigation::ProcessClass
Navigation::Index Presentation::Anchor Presentation::Button
sameName sameName validIndex validAnchor validButton
Table 1 shows some examples of the most common correspondences found in UWE specifications. Some of them are specific to UWE (e.g., validIndex), while some others can be used in any multi-view UML specification (e.g., sameName). The semantics of each kind of correspondence (i.e., the relation that must hold between the related elements) is predefined. For example, the semantics of a sameName correspondence can be defined by the OCL expression fclient.name = supplier.nameg. The fact that correspondences are defined using directed dependencies also indicates how the change should be propagated in case of de-synchronization (that is, from the supplier to the client).
<<profile>>
Synch <<metaclass>> Dependency
<<stereotype>>
CorrespondenceLink <<stereotype>> subtype <<stereotype>> equals <<stereotype>> namesSubset <<stereotype>> subsets <<stereotype>> sameName <<stereotype>> sameType <<import>> <<profile>>
UWE Synch <<stereotype>> validAnchor <<stereotype>> validButton <<stereotype>> validIndex
The idea is then to stereotype the UML dependencies that represent the correspondences with the identifier of the semantics they are expected to exhibit. For this reason we have defined a UML profile, which is shown in Fig. 6. It contains one stereotype for each kind of correspondence, and is currently structured in two related profiles. The first one, Synch, contains those correspondences which can be used in any UML multi-view specification. The second one, UWESynch, contains those kinds of correspondences which are specific to UWE. Fig. 7 show some examples of these correspondences.
It is not realistic that the system designer has to deal with definition and visualization of all the correspondences of a system. In particular, it is almost impossible to cope with their specification, management and maintenance in case of large systems, with thousands of correspondences between their elements.
Intensional approaches define correspondences as relations between types of model elements at metamodel level, instead of between the model element themselves — i.e., between viewpoint elements and not between view elements. However, this approach is not free from problems either: for typical users of the specification, correspondences are easier to use, visualize and understand when they are drawn as relationships between individual elements in the views, instead of expressed as formulae relating metamodel elements.
In UWE, some intensional correspondences are defined by its metamodel, which defines some relations between types of model elements: a navigation class is related to
Address id : Long name : String postalCode : String city : String country : String <<sameName>> a class of the content model; an anchor of the presentation model is related to a link in the navigation model, etc. For example, the relation for the validAnchor correspondence is specified by the following OCL expression: client . getPresentationContainer ( ) . getNavigationNode ( ) = supplier . getLinkSource ( ) and client . class . name = supplier . getLinkTarget ( ) . name
Note that for the evaluation of the expression we define a set of OCL helper functions, such as getPresentationContainer and getLinkTarget, which handle the UWE specific stereotyped elements.
In our approach, starting with a set of UWE views, our tool automatically generates the initial set of extensional correspondences from the intensional ones (see Fig. 1) by interpreting a collection of expressions like the one shown above. Once the whole set of correspondences is modeled, the designer can then add or modify those which are required in his/her particular case, although normally they are just a few. The fully automated generation greatly facilitates the task of defining correspondences in UWE models. 4.3
Apart from specifying the correspondences between model elements, any proper
multiview specification of a system should also allow the specification of required
correspondences, which describe the well-formed rules that the set of correspondences
between elements of views should obey [
In our proposal, this is expressed by a set of OCL constraints on the set of correspondences. They can be checked by any OCL engine, e.g., the MagicDraw validation engine that comes with some of its latest versions, or with any external OCL tool. In any case, validating these well-formed rules over the set of correspondences falls outside the scope of this paper, as it happens with the validation of the well-formed rules of the view elements (i.e., the intra-view consistency). 5
Synchronization of the different views of a model can be performed once inconsistencies in the views are detected. Inconsistencies can be found by checking that correspondences are valid for the existing model elements. If not, the synchronization tool proposes changes with the objective to achieve synchronized views again. 5.1
We have mentioned above that correspondences between the related elements in separate views are modeled by UML dependencies, stereotyped according to the kind of semantics we want to impose to the correspondence. UML dependencies provide a very convenient mechanism for drawing correspondences in a easy manner, and for visualizing them. However, UML dependencies are quite volatile, in the sense that the user may easily delete or modify them without the system being aware of the changes. For example, if the user removes one of the classes related by a dependency, the dependency is also removed, which may not be completely correct. This is why we need some kind of more persistent representation of correspondences, which in our approach is provided by classes stereotyped ¿CorrespondenceClassÀ. Each UML dependency that represents a correspondence is then associated to one of these classes.
Correspondence classes are managed by the reSynch tool in a transparent way, and therefore the user is completely unaware of them. Thus, if the user decides to delete or modify one UML dependency, the tool is able to know about the change. More precisely, the tool checks that every UML dependency has its associated correspondence class. In case of conflicts the tool reacts as follows: – If there is a UML dependency and it has a correspondence class with the same name and information, no action is needed (everything is Ok). – If there is a UML dependency with no associated correspondence class, it is assumed that the dependency has been added by the user, and therefore the correspondence class is created and added to the model. – If there is a correspondence class with no associated UML dependency, it means that the user has deleted the UML dependency or any of the associated classes. ² If the two related classes exist but the UML dependency does not, the correspondence class is removed. ² If the supplier class exists but neither the client nor the UML dependency do, the correspondence class is also removed. ² If the client class exists but neither the supplier nor the UML dependency do, a warning is raised because the user seems to have removed the supplier and left the clients with a “dangling” dependency to it. <<metaclass>>
Class
<<stereotype>> CorrespondenceClass +client : NamedElement +supplier : NamedElement +type : Stereotype
Fig. 8 shows the specification of the stereotype for correspondence classes, and Fig. 9 shows an example of the correspondence class associated to the top correspondence of Fig. 7. As we can see, we have also simulated that the designer has decided to change the content model, renaming class Address to C Address – probably without being aware that there was a class in the navigation model that was related to it (maybe even more elements in other models, not only that one). This has produced an inconsistency in the models, which could go easily unnoticed if no explicit correspondences have been specified. And even in this case, the propagation of changes to re-synchronize the model is not an easy task if it has to be manually performed. This is why we need the automated process for change propagation described in Sec. 2.
The synchronization process consists in the definition of the correspondences and — in case of need of synchronization — the automatic annotation of the model elements of the different views. The annotation is supported by a a set of UML stereotypes. Fig. 10 shows the UML profile used for annotating the models, while Fig. 11 shows an example of its application after the synchronization process (using the example model of Fig. 9). 5.2
The tool we have developed is called reSynch [
DeSynch <<stereotype>> AddElement <<stereotype>> RemoveElement <<stereotype>> <<stereotype>> <<stereotype>>
ChangeName ChangeType ChangeVisibility +newName : String +newType : Type +newVisibility : VisibilityKind <<stereotype>> ChangeMultiplicity +newUpper : Integer +newLower : Integer correspondences themselves. For instance, the example depicted in Fig. 9 gets transformed into the following Beanbag dictionaries: f / / Dictionary of model elements ”Content : : C_Address”¡>fname¡>”C_Address”g , ”Navigation : : Address”¡>fname¡>”Address”g , g f / / Dictionary of correspondences 1¡>ftype¡>”sameName ” ,
client¡>”Navigation : : Address ” , supplier¡>”Content : : C_Address”g ,
Then the Beanbag engine is executed using a set of synchronizing functions, one for each type of correspondence. These functions are defined in a Beanbag program and then compiled into a synchronizer. For instance, the Beanbag function we have defined for ¿sameNameÀ correspondences is the following: sameName ( entity1 , entity2 ) f entity1 . ” name” = entity2 . ” name ” ;
Please note that the direction of the change propagation (i.e., which element is the supplier and which one is the client) is deduced from the order in which the elements are listed in the corresponding entry in the dictionary of correspondences.
The result of the Beanbag execution is another Beanbag dictionary, with the changes required to synchronize both models. Such changes include additions, deletions and modifications to the data dictionaries. In our example, what we get is the following: ”Navigation : : Address”¡>fname¡>”C_Address”g , Finally, this information is used to annotate the UWE models with the required changes to restore the synchronization, producing in this case the model shown in Fig. 11.
There is a large number of approaches related to our work. In the first place we have the
works on synchronizing artifacts in software engineering, mostly influenced by the
original works on multi-view consistency mechanisms [
The approach of Cicchetti and Di Ruscio [
Ultimately, a key issue to realize and implement change management and
propagation is the availability of synchronizing tools that can detect the changes and show
them to the designer, so that he can decide what to do, and how to proceed. This may
imply propagating the changes either forwards, backwards, or even changing the
correspondences. In this respect, the most inspiring work for our proposal are the works
(and tools) by Benjamin Pierce and his colleagues in the Harmony group, who have
explored bidirectional transformations extensively in the context of trees [
Software development is increasingly shifting its focus from coding to modeling, thus evolution management techniques tend to encompass also the evolution of model-based artifacts. In particular, in multi-view design, model elements in a view are related by many-to-many correspondences to other view elements and thus any change propagation mechanism should manage the conflicting effects that changes may cause in the whole system.
In this paper we have proposed a synchronization process, a notation for the explicit
specification of correspondences between UWE views, and have briefly presented a tool
for synchronizing these related views under the presence of changes to the view
elements or to the set of correspondences. The tool, called reSynch, is currently in alpha
version and can be downloaded from [
There are many different lines of work that we plan to address in the very short
term. Firstly we want to fully integrate the tool with MagicUWE, the UWE plugin
for MagicDraw [
Acknowledgements. We would like to thank Yingfei Xiong and the people at the Japan National Institute of Informatics for their help and support with Beanbag. We would also like to thank the anonymous reviewers for their insightful comments and suggestions, that significantly helped to improve the paper. This work has been supported by the DFG Project MAEWA II, WI 841/7-2, the EU FET-GC2 IP project SENSORIA (IST-2005-016004) and the Spanish projects TIN2008-03107, TIN2008-00889-E and P07-TIC-03184.