Modeling ODP Correspondences using QVT

Jos

e Ra

ul Romero

, Nathalie Moreno

and Antonio Vallecillo

Universidad de C

ordoba (Spain)

University of M

alaga (Spain)

Abstract. Viewpoint modeling is currently seen as an effective technique for

specifying complex softwaresystems.However, having a set of independent view-

points on a system is not enough. These viewpoints should be related, and these

relationships made explicit in order to count with a set of complete and consistent

speciﬁcations. RM-ODP deﬁnes ﬁve complementary viewpoints for the speciﬁca-

tion of open distributed systems, and establishes correspondences between view-

point elements. ODP correspondences provide statements that relate the various

different viewpoint speciﬁcations, expressing their semantic relationships. How-

ever, ODP does not provide an exhaustive set of correspondences between view-

points, nor deﬁnes any language or notation to represent such correspondences.

In this paper we informally explore the use of MOF QVT for representing ODP

correspondences in the context of ISO/IEC 19793, i.e., when the ODP viewpoint

speciﬁcations of a system are represented as UML models. We initially show that

QVT can be expressive enough to represent them, and discuss some of the issues

that we have found when modeling ODP correspondences with QVT relations.

1 Introduction

Viewpoint modeling is gaining recognition as an effective approach for dealing with

the inherent complexity of the design of large distributed systems. It comprises two

major elements: model-driven development (MDD) on the one hand, and viewpoints

on the other. The ﬁrst one uses models as the key elements to direct the course of

understanding, design, construction, deployment, operation, maintenance and evolution

of systems. Models allow to state features and properties of systems accurately, at the

right level of abstraction, and without delving into the implementation details—or even

without giving a solution of how these properties can be achieved [1]. Viewpoints divide

the system design according to several areas of concerns, and have been adopted by the

majority of current software architectural practices, as described in IEEE Std. 1471 [2].

The Reference Model of Open Distributed Processing (RM-ODP) framework [3]

provides ﬁve generic and complementary viewpoints on the system and its environment:

enterprise, information, computational, engineering and technology viewpoints. They

allow different stakeholders to observe the system from different perspectives [4]. In

addition, ﬁve viewpoint languages deﬁne the concepts and rules for specifying ODP

systems from these viewpoints.

ODP viewpoint languages are abstract, in the sense that the RM-ODP deﬁnes their

concepts and structuring rules, but independently from any notation or concrete syntax

to represent them. This allows focusing on the modeling concepts themselves rather

Raúl Romero J., Moreno N. and Vallecillo A. (2006).

Modeling ODP Correspondences using QVT.

In Proceedings of the 2nd International Workshop on Model-Driven Enterprise Information Systems, pages 15-26

DOI: 10.5220/0002486000150026

 SciTePress

than on notational issues, and also allows the use of different notations, depending on

the particular needs and on the appropriateness of the speciﬁc notation, e.g., Z for the

information viewpoint, or Lotos for the computational viewpoint. The RM-ODP archi-

tectural semantics [5] deals with the representation of ODP concepts in different lan-

guages. However, this notation-independence may also bring along some limitations,

e.g., it may hinder the development of ODP tools. The need to count with precise nota-

tions for expressing ODP speciﬁcations, and to develop ODP tools, motivated ISO/IEC

and ITU-T to launch a joint project in 2004 which aims to deﬁne the use of UML for

ODP system speciﬁcations [6]. This new initiative (hereinafter called UML4ODP) is

expected to allow the development of tools for writing and analyzing ODP speciﬁca-

tions, and to make use of the latest MDD practices for designing and implementing ODP

systems. UML4ODP deﬁnes a set of UML Proﬁles for represent each of the viewpoint

languages. In this way, the ODP viewpoint speciﬁcations are expressed as a set of UML

models of the system. This initiative introduces very interesting beneﬁts: ODP mod-

elers can use the UML notation for expressing their ODP speciﬁcations in a standard

graphical way, while UML modelers can use the RM-ODP concepts and mechanisms

to structure their UML system speciﬁcations.

So far, most of the ODP community efforts have focused on the deﬁnition of the ﬁve

viewpoints and their corresponding viewpoint languages. However, having a set of in-

dependent viewpoints on a system is not enough. These viewpoints should be somehow

related, and these relationships made explicit in order to provide a complete and con-

sistent speciﬁcation of the system. The questions are: how can it be assured that indeed

one system is speciﬁed? And, how can it be assured that no views impose contradic-

tory requirements? The ﬁrst problem concerns the conceptual integration of viewpoints,

while the second one concerns the consistency of the viewpoints.

RM-ODP tries to address these issues by establishing correspondences between

viewpoint elements. ODP correspondences do not form part of any one of the ﬁve view-

points, but provide statements that relate the various different viewpoint speciﬁcations—

expressing their semantic relationships. Hence, a proper ODP system speciﬁcation con-

sists of a set of viewpoint speciﬁcations, together with a set of correspondences between

them. ODP does not provide however an exhaustive set of correspondences between

viewpoints (ODP is silent about many of them), nor deﬁnes any language or notation to

represent correspondences. But without explicitly representing them we cannot reason

about them, nor properly tackle the integration and consistency issues mentioned above.

In this paper we explore the use of MOF QVT [7] for representing ODP correspon-

dences in the context of UML4ODP, i.e., when the ODP viewpoint speciﬁcations of

a system are represented as UML models. We show that QVT seems to be expressive

enough to represent them, and discuss some of the issues that we have found when

modeling ODP correspondences with QVT.

The structure of this paper is as follows. First, Section 2 provides a brief introduction

to ODP, and also discusses some previous proposals for representing ODP correspon-

dences. Section 3 provides a short introduction to QVT. Then, Section 4 presents our

initial proposal, describing how to represent ODP correspondences with QVT. Section 5

discusses some the issues that we have found during our work. Finally, Section 6 draws

some conclusions and outlines some future research activities.

2 ODP

RM-ODP is a reference model that aims at integrating a wide range of present and fu-

ture ODP standards for distributed systems, maintaining consistency among them. The

reference model provides the coordination framework for ODP standards, and offers

a conceptual framework and an architecture that integrates aspects related to the dis-

tribution, interoperation and portability of software systems—in such a way that hard-

ware heterogeneity, operating systems, networks, programming languages, databases

and management systems are transparent to the user. In this sense, RM-ODP manages

complexity through a “separation of concerns”, addressing speciﬁc problems from dif-

ferent points of view.

In ODP terms, a viewpoint (on a system) is an abstraction that yields a speciﬁcation

of the whole system related to a particular set of concerns. ODP deﬁnes ﬁve viewpoints,

covering all the domains of architectural design. These ﬁve viewpoints are:

– the enterprise viewpoint (EV), which is concerned with the purpose, scope and

policies governing the activities of the speciﬁed system within the organization of

which it is a part;

– the information viewpoint (IV), which is concerned with the kinds of information

handled by the system and the constraints on the use and interpretation of that

information;

– the computational viewpoint (CV), which is concerned with the functional decom-

position of the system into a set of objects that interact at well-deﬁned interfaces;

– the engineering viewpoint (NV), which is concerned with the infrastructure re-

quired to support distribution;

– the technology viewpoint (TV), which is concerned with the choice of technology

used to implement the system and to connect it with its environment.

These viewpoints are of course mutually related, but no temporal order of their de-

velopment is implied. They are (at least in theory) separately speciﬁed, and sufﬁciently

independent to simplify reasoning about the complete system speciﬁcation.

2.1 ODP Correspondences

ODP clearly states that a set of viewpoint speciﬁcations of an ODP system written in

different viewpoint languages should not make mutually contradictory statements i.e.,

they should be mutually consistent.

The key to consistency is the idea of correspondences between different viewpoint

speciﬁcations, i.e., a statement that some terms or structures in one speciﬁcation corre-

spond to other terms and structures in a second speciﬁcation.

The requirement for consistency between viewpoint speciﬁcations implies that what

is speciﬁed in one viewpoint speciﬁcation about an entity needs to be consistent with

what is said about the same entity in any other viewpoint speciﬁcation. This includes

the consistency of that entity’s properties, structure and behavior.

The speciﬁcations produced in different ODP viewpoints are each complete state-

ments in their respective viewpoint languages, with their own locally signiﬁcant names,

possibly with different granularity, and so cannot be related without additional infor-

mation in the form of correspondence statements that make clear how elements of

different viewpoints are related, and how constraints from different viewpoints apply to

particular elements of a single system to determine its overall behavior.

Correspondence statements relate the various different viewpoint speciﬁcations, but

do not form part of any one of the ﬁve viewpoints. They fall into two categories [8]:

– Some correspondences are required in all ODP speciﬁcations; these are called re-

quired correspondences. If the correspondence is not valid in all instances in

which the concepts related occur, the speciﬁcation is not a valid ODP speciﬁca-

tion.

– In other cases, there is a requirement that the speciﬁer provides a list of items in two

speciﬁcations that correspond, but the content of this list is the result of a design

choice; these are called required correspondence statements.

RM-ODP only provides required correspondences between the computational and

engineering viewpoints, and between the engineering and the technology viewpoints.

For the rest of the viewpoints, RM-ODP only states that elements of every viewpoint

should be consistent with the speciﬁcation of the corresponding elements in the rest of

the viewpoints, and with the restrictions that apply to them. For instance, the elements

of the information viewpoint should conform to the policies of the enterprise viewpoint

and, likewise, all enterprise policies should be consistent with the static, dynamic, and

invariant schemata deﬁned by the information speciﬁcation.

For illustration purposes let us include here some examples of ODP correspon-

dences, as described in Part 3 of RM-ODP [8], the Enterprise Language [9], and in

UML4ODP [6].

EC-1 Where there is a correspondence between enterprise and computational elements,

the speciﬁer has to provide, for each enterprise object in the enterprise speciﬁca-

tion, that conﬁguration of computational objects (if any) that realizes the required

behavior, and for each interaction in the enterprise speciﬁcation, a list of those

computational interfaces and operations or streams (if any) that correspond to the

enterprise interaction, together with a statement of whether this correspondence

applies to all occurrences of the interaction, or is qualiﬁed by a predicate.

CN-1 Each computational object that is not a binding object corresponds to a set of one

or more basic engineering objects (and any channels which connect them). All the

basic engineering objects in the set correspond only to that computational object.

CN-3 Where transparencies that replicate objects are involved, each computational in-

terface of the objects being replicated corresponds to a set of engineering interfaces,

one for each of the basic engineering objects resulting from the replication. Each

of these engineering interfaces corresponds only to the original computational in-

terface.

NT-1 Each engineering object corresponds to a set of one or more technology objects.

The implementable standards for each technology object is dependent on the choice

of technology.

2.2 Expressing Correspondences

Different authors have dealt with the problem of deﬁning and expressing correspon-

dences between viewpoints, mainly when trying to address the issue of viewpoint con-

sistency checking. Some of the proposals, e.g., [10, 1], highlight the need to explicitly

deﬁne and establish these correspondences but do not represent them as independent

entities. Rather, they form part of the logical framework they deﬁne for checking the

consistency of viewpoint speciﬁcations.

Other authors explicitly represent the correspondences, specially when viewpoint

speciﬁcations are expressed as UML models, using different alternatives. One inter-

esting possibility is the use of OCL to deﬁne relationships between the metamodel

elements that represent the appropriate modeling concepts, as suggested by, e.g., [11].

This approach works very well when the correspondences are deﬁned between all the

instances of certain modeling concepts, e.g., when every computational interface corre-

sponds exactly to one engineering interface (correspondence CN-2). However, there are

cases in which correspondences need to be established between particular objects of an

speciﬁcation. The problem is that it is not possible at the metalevel to determine which

particular objects should be related. Therefore, it is important that correspondences can

be established between speciﬁc model elements, too.

UML 2.0 abstraction dependencies, possibly constrained by OCL statements, are

the natural mechanism provided by UML to represent a relationship that relates two

elements or sets of elements that represent the same concept at different levels of ab-

straction or from different viewpoints. Thus, ODP correspondences between viewpoint

speciﬁcations (for example, between enterprise objects and information objects, or be-

tween enterprise policies and information schemata) can be expressed as UML abstrac-

tion dependencies between the corresponding UML model elements.

However, as suggested by [12,13], viewpoint correspondences can also be used for

other purposes, e.g., change management in multi-view systems. Change management

implies consistent evolution of system speciﬁcations: if a view is modiﬁed for any rea-

son (e.g., change of some business rules or some QoS requirements), several changes

may need to be performed in other views in order to maintain the overall viewpoint con-

sistency. In this context, correspondences act as “binds” that link together the related

elements, transforming them if a change in one of them occurs, i.e., propagating the

changes to maintain consistency.

UML abstraction dependencies show to be insufﬁcient for these purposes. The main

reasons are that they cannot store all the required information about the correspondence

they represent, and because they can be used to express existence of the correspon-

dence but not to enforce it. Therefore, Yahiaoui et al. deﬁne a new viewpoint, the link

viewpoint, whose elements are “links” that establish binds between elements in differ-

ent viewpoints. These links explicitly represent the ODP correspondences, and store

the relevant information about the relationships between the views and the information

related to each one (as attributes of the class that represents the link), thus guarantee-

ing traceability. A (change manager) tool has been developed for deﬁning and enforcing

these links, thus providing automated support for change management and propagation.

We do not think that such correspondences constitute another ODP viewpoint. ODP

explicitly states that correspondences do not form part of any viewpoint. In addition,

ODP deﬁnes the concept of viewpoint on a system, whilst correspondences are de-

ﬁned between two viewpoints. However, we do agree that correspondences should be

represented by something more powerful than UML abstraction dependencies for the

reasons stated above: correspondences may require to store more information than a

single UML abstraction dependency can convey, and they may be required for other

purposes—e.g., for enforcing and propagating changes from one view to another.

The fact that change propagations can be considered particular cases of model trans-

formations suggests the use of QVT as the perfect solution to the problem of repre-

senting ODP correspondences. The use of relations was initially indicated by [14] for

relating concepts from different viewpoint at the metalevel but not explored any further

for relating instances, which is essential for establishing proper correspondences.

RM-ODP itself explicitly states that correspondences can be used to deﬁne trans-

formations between viewpoint elements to implement consistency checks: “One form

of consistency involves a set of correspondence rules to steer a transformation from

one language to another. Thus given a speciﬁcation S

in viewpoint language L

and

speciﬁcation S

in viewpoint language L

, where S

and S

both specify the same sys-

tem, a transformation T can be applied to S

resulting in a new speciﬁcation T (S

) in

viewpoint language L

which can be compared directly to S

to check, for example,

for behavioral compatibility between allegedly equivalent objects or conﬁgurations of

objects.” [8]

3 QVT

3.1 QVT Relations

MOF QVT (Query/View/Transformation) [7] is the OMG’s standard for specifying

MOF model queries, views and transformations. It is expected to play a central role

in the Model Driven Architecture [15]. QVT deﬁnes three different (but closely re-

lated) languages for specifying transformations using declarative and imperative styles.

Black-box implementations of operations can also be used to allow reuse of existing

algorithms or domain speciﬁc libraries in certain model transformations.

QVT Relations is a language to write declarative speciﬁcations of the relationships

between MOF models. The QVT Relations language supports object pattern matching,

and implicitly creates trace classes and their instances to record what occurred during

a transformation execution. Relations can assert that other relations also hold between

particular model elements matched by their patterns.

QVT Relations allow for the following execution scenarios [7]:

– Check-only transformations to verify that models are related in a speciﬁed way.

– Single direction and bi-directional transformations.

– The ability to establish relationships between pre-existing models, whether devel-

oped manually, or through some other tool or mechanism.

– Incremental updates (in any direction) when one related model is changed after an

initial execution.

– The ability to create as well as delete objects and values, while also being able to

specify which objects and values must not be modiﬁed.

3.2 QVT Transformations

In the relations language, a transformation between candidate models is speciﬁed as

a set of relations that must hold for the transformation to be successful. A candidate

model is any model that conforms to a model type, which is a speciﬁcation of what kind

of model elements any conforming model can have. An example is:

modeltype EL uses “odp.UML4ODP.EL UMLProﬁle”

modeltype IL uses “odp.UML4ODP.IL UMLProﬁle”

transformation EVtoIV (ev : EL, iv : IL) {

top relation EVrole2IVobjectType {...}

top relation EVobject2IVobject {...}

...

}

Relations in a transformation declare constraints that must be satisﬁed by the ele-

ments of the candidate models, and specify a relationship that must hold between the

elements of the candidate models. Top level relations are those that need to hold for a

transformation to be successfully executed.

A relation is deﬁned by two or more domains and a pair of when and where pred-

icates. For instance, the following relation EVrole2IVobjectType establishes a rela-

tionship between roles in the EV speciﬁcation and object types in the IV speciﬁcation,

whereby every enterprise role is related to one information object type with the same

name (but not necessarily vice-versa, i.e., not every information object type should cor-

respond to an enterprise role).

relation EVrole2IVobjectType { /* maps e-roles to i-objectTypes */

domain ev er:Class {name=r}

domain iv iot:Class {name=r}

when { er.stereotypedBy(”EV Role”) }

where { er.stereotypedBy(”EV Role”) and iot.stereotypedBy(”IV ObjectType”) }

}

More precisely, relation EVrole2IVobjectType checks that for each role in the EV

speciﬁcation (i.e., a class stereotyped EV

Role) there is an object type with the same

name in the IV speciﬁcation (i.e., a class stereotyped IV

ObjectType).

A transformation can be invoked either to check two models for consistency or to

modify one model to enforce consistency. In the ﬁrst case, the transformation checks

whether the relations hold in all directions, and report errors when they do not hold.

In case of enforcement, one model acts as source and the other as target; the execution

of the transformation proceeds by ﬁrst checking whether the relations hold, and for

relations for which the check fails, attempting to make the relations hold by creating,

deleting or modifying only the target model, thus enforcing the relationship.

QVT transformations can also be used for propagating changes from one model to

other. As mentioned in the QVT standard [7], “the effect of propagating a change from

a source model to a target model is semantically equivalent to executing the entire trans-

formation afresh in the direction of the target model. The semantics of object creation

and deletion guarantee that only the required parts of the target model are affected by

the change. Firstly, the semantics of check-before-enforce ensures that target model el-

ements that satisfy the relations are not touched. Secondly, key-based object selection

ensures that existing objects are updated where applicable. Thirdly, deletion semantics

ensures that an object is deleted only when no other rule requires it to exist.”

4 Modeling ODP Correspondences

We have seen how QVT transformations can be speciﬁed to deﬁne general relationships

between elements of two ODP viewpoint speciﬁcations (e.g, between enterprise roles

and information object types, or between enterprise objects and information objects).

However, these kinds of correspondences are not very common in the speciﬁcation of

any ODP system. Usually, correspondences are deﬁned between particular elements of

the speciﬁcation (e.g., between particular objects, types, templates, or actions).

For instance, suppose that we have an ODP speciﬁcation of a Banking system, in

which bank accounts are modeled in the computational viewpoint as objects that sup-

port a couple of interfaces for accessing their services. In the engineering viewpoint

speciﬁcation, we want each of these computational objects to correspond exactly to

two basic engineering objects that support the same interfaces (plus possibly other in-

terfaces only relevant to the engineering objects concerned). The speciﬁcation of such

part of the system at the object template level, and using the UML proﬁles deﬁned in

UML4ODP, is shown in Figure 1.

In order to represent such a correspondence, we could use a set of UML abstraction

dependencies between the related elements. However, this could be done in a more

precise and effective way using QVT.

At the object level, we need to deﬁne a relation that establishes a correspondence

between a computational object which is an instance of an Account object template,

and two engineering objects that represent it in the engineering speciﬁcation:

relation cv-account2twonv-accounts {

domain cv a:InstanceSpeciﬁcation {name=n, classiﬁer = “Account”}

domain nv a1:InstanceSpeciﬁcation {name=n + ’1’, classiﬁer = “Account1”}

domain nv a2:InstanceSpeciﬁcation {name=n + ’2’, classiﬁer = “Account2”}

when { a.stereotypedBy(”CV

Object”) }

where { a.stereotypedBy(”CV

Object”) and a1.stereotypedBy(”NV BEO”) and

a2.stereotypedBy(”NV BEO”) and DuplTemplates(a.classiﬁer,a1.classiﬁer,a2.classiﬁer)

}

We can see how it establishes that if there exists a UML InstanceSpeciﬁcation

stereotyped CV

Object, whose classiﬁer is an Account, then there should be two UML

InstanceSpeciﬁcations stereotyped NV BEO, whose classiﬁers are Account1 and Ac-

count2, respectively. In addition, a relation called DuplTemplates should also hold

between the classiﬁers of all these instance speciﬁcations. Such a QVT relation is pre-

Fig.1. Bank Account comp. objects and interfaces should be related to the corresponding eng.

objects and interfaces.

cisely the one that establishes the correspondence between the appropriate computa-

tional object templates (Fig. 1):

relation DuplTemplates{

domain cv a:Component {name=n}

domain nv a1:Component {name=n + ’1’}

domain nv a2:Component {name=n + ’2’}

when { a.stereotypedBy(”CV

ObjectTemplate”) }

where { a.stereotypedBy(”CV ObjectTemplate”) and

a1.stereotypedBy(”NV ObjectTemplate”) and

a2.stereotypedBy(”NV

ObjectTemplate”) and

sameODPInterfaces(a,a1) and sameODPInterfaces(a,a2)

}

This relation establishes that a given computational object template should be re-

lated to two engineering object templates (whose names should be the same, but suf-

ﬁxed with ‘1’ and ‘2’), and that the ODP interfaces of the computational object tem-

plate should be supported by the corresponding interfaces of the engineering object

templates—as stated by the ODP required correspondence CN-3. This required corre-

spondence is expressed using the sameODPInterfaces relation, that checks that every

interface deﬁned for a computational object template is supported by an interface of

a given engineering object template. In the UML4ODP context, both computational

and engineering object templates are modeled using UML components, and both com-

putational and engineering interfaces are represented by UML ports. Thus, the QVT

relation checks that every port of the UML component representing the computational

object template has an associated port with the same name in the given UML compo-

nent representing the basic engineering object template, and that the set of provided and

required interfaces of each port are the same in the two speciﬁcations.

relation sameODPInterfaces {

domain cv cot:Component {}

domain nv eot:Component {}

when {

cot.stereotypedBy(”CV

ObjectTemplate”) and eot.stereotypedBy(”NV ObjectTemplate”)

}

where { eot.ownedPort.name->includes(cot.ownedPort.name)

and cot.ownedPort->forAll(p | p.required =

eot.ownedPort->select(name=p.name).required)

and cot.ownedPort->forAll(p | p.provided =

eot.ownedPort->select(name=p.name).provided)

}

This last relation can be reused as-is in other QVT relations to enforce the required

correspondence, CN-3, in other ODP correspondence statements.

5 Issues for Discussion

Once we have brieﬂy seen how QVT could be used to represent both ODP correspon-

dence statements and ODP required correspondences, let us discuss in this section some

issues that may require further investigation.

5.1 Bi-directionality and Cardinality of Correspondences

The RM-ODP is silent about the possible bi-directionality of the ODP correspondences.

However, we believe such correspondences must be bidirectional so it is possible to

navigate from any of the two views to the other. The idea is to be able to trace elements,

i.e., given an element of a viewpoint, ﬁnd all the elements in the rest of the viewpoints

which are related to it (objects, policies, rules, actions, etc.).

In addition, RM-ODP seems to deﬁne correspondences just between pairs of view-

points. However, sometimes correspondences between one and more viewpoints might

be required, i.e., between one element in one viewpoint and several elements in other

viewpoints. Deﬁning this kind of 1-M correspondences is possible with QVT relation-

ships, although something not deﬁned in RM-ODP.

5.2 Transitivity of Correspondences

The QVT relations presented here can be used for change propagation. This occurs

when a change happens in one of the viewpoint speciﬁcations, and we want to propagate

the change to all related elements in the rest of the viewpoint speciﬁcations. In this case

we can consider QVT relations as model transformations, enforcing the relationships

on the target models as mentioned earlier. However, this may raise some redundancy or

duplication issues due to transitivity of the relations.

Suppose elements α, β and γ in viewpoints A, B and C respectively, related as

follows: α is related with β and γ, and β is related with γ. How to deal with the poten-

tial redundancy that may happen when a change in element α is propagated to γ both

directly from α to γ, and indirectly through β? There are cases where this does not im-

ply any problem, as it happens when the relations just check that the elements have the

same name, and we change the name of α. However, what happens when the relations

add something to the elements’ structure or behavior? E.g., suppose they add a sufﬁx to

the name of the element? Will we end up with a duplicated sufﬁx in the name of γ?

Please notice how this is an example that could justify the need for establishing

N-M correspondences between viewpoints.

5.3 Full Consistency of Speciﬁcations

In order to check the consistency of the speciﬁcations, we can use the ODP correspon-

dences if we consider them as model transformations, as mentioned in the RM-ODP

standards. However, complete consistency between viewpoint speciﬁcations cannot be

guaranteed by ODP correspondences only. Analysis of consistency depends on the ap-

plication of speciﬁc consistency techniques, most of which are based on checks for

particular kinds of inconsistency, and thus cannot prove complete consistency.

This latter issue has been addressed by several people, from different perspectives.

The interested reader can consult, e.g., the works by Derrick, Bowman et al. [10], the

interesting book [1], and also the recent and complete work done by Remco Dijkman in

his PhD thesis [11]. How to combine the use of model-driven techniques and QVT in

those contexts is something we would like to explore further as part of future research.

6 Conclusions

In this paper we have sketched how QVT relations can be used to represent ODP cor-

respondences in the context of the UML4ODP project, in an initial attempt to show

that this approach is feasible. QVT relations provide more powerful mechanisms than

those provided by plain OCL or UML abstraction dependencies for relating elements in

different ODP viewpoints, can be modularly and independently speciﬁed, be reused to

build more powerful QVT transformations, and serve both for checking the correspon-

dences and for enforcing them.

There are still several issues open for investigation. Apart from the questions men-

tioned above, it is not clear whether this method is better or not than the other ones dis-

cussed here, e.g., the one proposed by Remco Dijkman [11], or by Yahiaoui et al. [12,

13]. Furthermore, apart from specifying the correspondences, can the QVT relations

provide any other advantages? Can they be used, for instance, to reason about the sys-

tem speciﬁcations and their consistency? And if so, how this can be achieved? Which is

the underlying logic in which the reasoning can be done? Apart from consistency, what

other properties can be proved from the QVT speciﬁcations of the correspondences?

These are interesting questions, some of them we plan to address in a near future.

Acknowledgements

The authors would like to thank the anonymous referees for their constructive comments

and suggestions. This work has been partially supported by Spanish Research Project

TIN2005-09405-C02-01.

References

1. Große-Rhode, M.: Semantic Integration of Heterogeneous Software Speciﬁcations.

Springer-Verlag, Berlin (2004)

2. IEEE Std. 1471: Recommened Practice for Architectural Description of Software-Intensive

Systems. IEEE Standards Association. (2000)

3. ISO/IEC 10746-1 to 10746-4, ITU-T X.901 to X.904: RM-ODP. Reference Model for Open

Distributed Processing. ISO & ITU-T. (1997)

4. Linington, P.: RM-ODP: The architecture. In Milosevic, K., Armstrong, L., eds.: Open

Distributed Processing II, Chapman & Hall (1995) 15–33

5. ISO/IEC 10746-4, ITU-T Rec. X.904: Information technology – Open distributed processing

– Reference model: Architectural Semantics. ISO & ITU-T. (1998)

6. ISO/IEC CD 19793, ITU-T Rec. X.906: Information technology – Open distributed process-

ing – Use of UML for ODP system speciﬁcations. ISO & ITU-T. (2005)

7. OMG: MOF QVT Final Adopted Speciﬁcation. Object Management Group. (2005) OMG

doc. ptc/05-11-01.

8. ISO/IEC 10746-3, ITU-T Rec. X.903: Information technology – Open distributed processing

– Reference model: Architecture. ISO & ITU-T. (1996)

9. ISO/IEC 15414, ITU-T Rec. X.911: Information technology – Open distributed processing

– Reference model – Enterprise language. ISO & ITU-T. (2006)

10. Boiten, E.A., Bowman, H., Derrick, J., Linington, P., Steen, M.W.: Viewpoint consistency in

ODP. Computer Networks 34 (2000) 503–537

11. Dijkman, R.: Consistency in Multi-Viewpoint Architectural Design. PhD thesis, University

of Twente (2006)

12. Yahiaoui, N., Traverson, B., Levy, N.: Adaptation management in multi-view systems. In:

Proc. of WCAT’05, Glasgow, Scotland, UK (2005) 99–105

13. Yahiaoui, N., Traverson, B., Levy, N.: A new viewpoint for change management in RM-ODP

systems. In: Proc. of WODPEC 2005, Enschede, The Netherlands (2005) 1–6

14. Akehurst, D.H.: Proposal for a model driven approach to creating a tool to support the RM-

ODP. In: Proc. of WODPEC 2004, Monterey, California (2004) 65–68

15. OMG: Model Driven Architecture. A Technical Perspective. Object Management Group.

(2001) OMG doc. ab/2001-01-01.