Proposal for a Model Driven Approach to Creating a Tool to Support theRM-ODP
D.H.Akehurst
University of Kent
D.H.Akehurst@kent.ac.uk
Abstract
The potential for revising the RM-ODP standards is an
excellent opportunity to move the given specifications intoa form that is more amenable to the provision of tools that
support the standard. Adoption of the approachadvocated by the RM-ODP would be greatly increased iftools to support the approach were more readily
available. This paper proposes an approach to generatingsuch tools, directly, from a model based approach tospecifying the RM-ODP viewpoint languages andcorrespondences. In particular this paper highlights
certain requirements that the specification approach
would need to meet if the production of such tools were tobe achievable.

1. Introduction
The Reference Model for Open Distributed Processing(RM-ODP) [11] belonging to the International Standards
Organisation (ISO) was published about ten years ago.
Although originally developed with respect to thetelecommunications industry, as we move into a situation
where more and more software systems are essentiallydistributed, this reference model becomes similarly more
and more relevant to software development.
Over the last few years there has been more focus on
supporting distribution and an increase in the number ofdifferent technologies to support distributed softwaresystems; originally CORBA, COM, DCOM and lately
Web Service based approaches such as .NET and J2EE.
Even though these distribution technologies have been
proposed, the take up and use of the RM-ODP has notbeen as common place as its relevance and potential
usefulness would lead us to expect. Contrast this with theoutputs from the OMG, such as the UML and latterly their
MDA approach, which appear to be widely used and arecertainly commonly discussed.
There could be a number of reasons for this, marketingand publicity being one possible candidate. However,another reason is the accessibility of the OMG outputs
which are nearly always supported by tools (even if they
are not considered to be the best possible tools), thesegive practitioners a tangible artefact by which to evaluate
and try out the proposed technologies.
Where are the easy to use graphical language based
tools to support the RM-ODP? Perhaps such a tool cannot
be created and at the same time be technically sound.
However, it would be useful to have one that provides theeasy accessibility offered by the numerous UML tools,
which, it could be argued, are not always so technicallysound but do provide an easy way into the world ofOMG-Oriented Modelling.
Development of a simple graphical tool based on theRM-ODP is not quite as straight forward as it is forlanguages such as UML. Firstly, the RM-ODP proposes afive viewpoints approach to system design involving atleast as many separate but related sets of concepts but
specifically does not prescribe any particular languagewith which to write design specifications. Secondly, theconcepts recommended for each viewpoint are describedusing English text (as opposed to the OMG’s approach ofmodelling the language concepts – known asmetamodelling).
Thus, before we can build a tool that supports thedesign of systems using the RM-ODP approach, we needto address these two issues. This position paper proposes
using the OMG’s approach to solving the second issue, byforming metamodels that define the concepts described in
the ODP Standard documents, as has been done for someof the viewpoints already [2, 9, 10] The first issue, that ofviewpoints and languages, we can address by firstly
defining notations that map to the metamodel concepts
and secondly by specifying the inter viewpoint
relationships as relations between metamodel concepts.
Both of these (inter viewpoint correspondences, andnotations) can be defined using the relation basedtransformation specification technique taken from theMDA initiative [8].
In the following sections we first discus the five
viewpoint language concepts and their corresponding
metamodels; secondly we propose a technique fordefining notations for each viewpoint; thirdly we illustrate
an approach for specifying inter-viewpoint consistency
relationships. The paper ends with a discussion about theEngineering
Configuration

Foundations

Cluster0..*

EngObjectEnterprise

ClusterManager

Computational

BasicEngObject
Information

Engineering0..*

Technology

Figure 3 Engineering Objects
Figure 1 Viewpoint Metamodels
issues and problems to be addressed and a future direction
for the work.

2. Viewpoint Metamodels
A number of papers have proposed metamodels fordifferent RM-ODP viewpoints; [10] proposes anEnterprise Viewpoint metamodel; [9] and [2] discus
Computational Viewpoint metamodels; and [7] describes
a metamodel for the RM-ODP Foundation concepts.
A RM-ODP tool could be based on a set of five such
metamodels, with the addition of (at least) a common‘Foundations’ metamodel. Using an OMG MOF likelanguage we can illustrate the approach as shown inFigures 1-3. Figure 1 shows an overview of six packages
containing the metamodels for the five viewpoints and ametamodel for the common Foundations. Figure 2 andFigure 3 show example segments of possible
Computational and Engineering Viewpoint metamodels.
The specification of viewpoint (or language) concepts
in this manner makes it very easy to generate core parts oftools that support the viewpoints. Tools such as theEclipse Modelling Framework (EMF) [5] and Kent
Modelling Frameworks (KMF) [6] easily generate basic
repositories that can form the core of a design tool fromsuch models of a language.

3. Viewpoint NotationsIn addition to repository functions a useful design tool
requires a mechanism for populating the repository using
Computational
Configuration
0..* object

CompObject

interfaceappropriate notations (or concrete syntax). The ODP ISO
standards along with books such as [Blair/Stefani] makeuse of notations for describing various viewpoint designs.
However although clearly understandable the notations
are informally defined. If we can define these notations
more formally, then there is scope for auto-generation oftools to support the viewpoint languages.
In [1] and [4] a modelling approach to defining visuallanguages is described. The approach is to define theconcrete syntax of the notation as a model andsubsequently specify a model transformation (via a set ofrelations) between the concrete syntax model and theconcepts metamodel.
Using notation from the latest submission to theOMG’s QVT RFP [8] and the technique defined in [3], anexample for part of a Computational Viewpoint language
specification is illustrated in Figure 4. It shows thespecification of relations between Computational Objects
and Circles, and between Interfaces and Solid rectangles(or bars); an example of the notation is shown in Figure 5.
The detail of the relations must be added to thegraphical view of them, defining the domain and range ofthe relation and a matching condition expression thatspecifies which elements from one side (domain or range)of the relation are mapped to elements from the other. It isalso necessary to define characteristics of the relationsuch as whether it is functional, total, bijective, etc. (Thedetail of the relations is shown in an Appendix.)
This approach can be used to define notations for all of
the viewpoint concepts giving us a set of models andDiagram

ComputationalConfiguration

CircleCompObject

SolidRect

Interface

Interface0..*interface 2binding

Primitive
Binding

Figure 2 Computational Objects

Figure 4 Syntax-CompVP Relations

manager :ServiceManager

servicevsCtrlfilm1

vidWins1: VideoStream

servicevideoRec

videoTransbrowsers: Browser

vsCtrlfilm2

vidWins2: VideoStream

display

videoRec

videoTransu

Figure 5 A Computational Configuration
relations from which it is possible to generate a tool thatfacilitates drawing designs in each of the viewpoint
languages, including the necessary features of such a tool
offered by a model repository.
The KMF tool developed at the University of Kent [6]has been used to generate parts of such tools for visuallanguages from this type of specification.

4. Inter-Viewpoint Consistency
A key part of the RM-ODP is the inter-viewpointconsistency specifications that tie the information fromthe five viewpoints into a consistent design from which an
implementation can be produced.
Similarly to the specifications linking concrete syntax
to metamodel concepts, we can define relations that linkconcepts between the different viewpoints. However, forsome of the consistency relationships it is not possible todefine them at the meta-level. It is necessary for theconnections to be made at the design stage, for this weneed another language (or at least a tool mechanism).
Figure 6 shows inter viewpoint consistency relations
between concepts from the Computational Viewpoint andthe Engineering viewpoint. This relations model thefollowing correspondence:“Each computational object which is not a binding
object corresponds to a set of one or more basic
engineering objects (and any channels which connectthem). All the basic engineering objects in the set
correspond only to that computational object.”
CompObject(from Computational)

BasicEngObject(from Engineering)

inverseFunctional and onto and total
Channel(from Engineering)

inverseFunctional and onto and total

Figure 6 A Comp-Eng Correspondence

The relations are characterised as ‘inverseFunctional’(or 1-to-many), each ‘single’ CompObject maps to‘many’ BasicEngObjects (or Channels), but each
BasicEngObject (or Channel) maps to a single
CompObject. The relations are also defined as ‘onto’ and‘total’ specifying that every CompObject andBasicEngObject (or Channel) in the domain and range ofthe relations must be part of the relation.
It is not feasible to define a matching condition forthese relations (i.e. an expression that would define whichobjects from domain and range are mapped to each other)because there is no way at the meta-level to determine
which objects should be related. The correspondencesmust be set up by the designer on a per design basis;
however, the specification of these relations will enable a
generated tool to indicate whether on not thecorrespondences have been set up.

5. Conclusion, Issues and Future Work
The previous sections have given an idea of how
model based specifications of language concepts andrelations between them can be given to define aspects
from the RM-ODP standard. Using code generation
techniques these types of specification can be used togenerate tools that support designing a system from thedifferent ODP viewpoints.
This paper has illustrated the ideas using languages
provided by the OMG However, OMG languages are notessential, any precise approach to defining the languages
and relationships would provide the necessary starting
point for generating tools. In particular the following
specifications should be given:
1. Precise definitions of the viewpoint language
concepts – beyond the textual descriptions currently
given – i.e. metamodels.
2. Precise specification of the correspondences
between concepts in each viewpoint, along withsuggested mechanisms for specifying these – i.e. a
Correspondence Specification Viewpoint.
3. Precise specification of example notations for eachviewpoint. Perhaps both graphical and textual.
In addition, a number of full example system designs
should be provided illustrating intended use of theframework.
The approach to generating tools presented in the paper
is an initial idea, a number of issues and problems arelikely to make it difficult. Some of these are discussed
below:• Metamodelling – What concepts should be used todefine the metamodels? Sections 6 and 7 of Part 2 ofthe standard informally define some language
definition concepts, is it possible (or even a goodidea!) to extend these to give a full and sufficient
metamodelling language.

• Relations – Is the proposed technique for specifying
relations expressive enough for the proposed task.
Some correspondences are not at all easy to define!
How useful or possible is it to define them all as
relations?
• Correspondences - we need a mechanism for adesigner to specify correspondences, i.e. we need aviewpointfordefining
inter-viewpoint
correspondences.
• Technology Viewpoint – the concepts for ametamodel of this is not obvious, in fact theconcepts currently in the standard are minimal. Is it
necessary to have something more and if so whatshould be in it?
Extending the idea of a supporting tool; it would bevery useful to provide MDA like support for generation ofsystem implementations (or simulation/analysis models)from the given designs. To facilitate this we certainly
need good definitions of Technology models.
Generating an implementation could be achieved using
an MDA like approach of transforming information drawn
from designs given in the five viewpoints and providing a
set of implementation source code, configuration, anddeployment files.

6. References
[1]

[2]

[3]

[4]

[5]
[6]
[7]

[8]
[9]

Akehurst D. H., "An OO Visual Language Definition
Approach Supporting Multiple Views," in proceedings
VL2000, IEEE Symposium on Visual Languages,
September 2000.
Akehurst D. H., Derrick J., and Waters A. G.,"Addressing Computational Viewpoint Design," inproceedings Enterprise Distributed Object Computing
Conference, EDOC 2003, Brisbane, Australia, pp. 147,
September 2003.
Akehurst D. H., Kent S., and Patrascoiu O., "A relational
approach to defining and implementing transformations
between metamodels," Journal on Software and Systems
Modeling, vol. 2, pp. 215, November 2003.
Clark A., Evans A., and Kent S., "Engineering modelling
languages: A precise meta-modelling approach," inproceedings ETAPS 02 FASE Conference, LNCS,Springer, April 2002.
IBM, "Eclipse Modeling Framework,"
http://www.eclipse.org/emf/, 2003.
KMF-team, "Kent Modelling Framework (KMF)," 2002,
www.cs.kent.ac.uk/projects/kmf
Naumenko A., Wegmann A., Genilloud G., and FrankW. F., "Proposal for a formal foundation of RM-ODP
concepts," in proceedings ICEIS 2001, Workshop On
Open Distributed Processing - WOODPECKER`2001,
Setúbal, Portugal, pp. 81-97, July 2001.
OMG, "Request for Proposal: MOF 2.0 Query / Views /Transformations RFP," Object Management Group,
ad/2002-04-10, April 2002.
Romero R. and Vallecillo A., "Formalizing ODP
Computational Viewpoint Specifications in Maude," in[10][11]

proceedings EDOC 2004, Monterey, California,
September 2004.
Steen M. and Derrick J., "ODP Enterprise Viewpoint
Specification," Computer Standards and Interfaces, vol.
22, pp. 165-189, September 2000.
X.901-5, "Information Technology - Open Distributed
Processing - Reference Model: All Parts," ITU-T
Recommendation, 1996-99.

Appendix A
The detail of a relation specification needs to define amatching condition that indicates which elements ofdomain and range should be related. In addition the links
between relations should define the contents of thedomain and range sets for the sub relations. The following
specifications indicate the approach for the relations given
in Figure 4. Depending on the level of difference there is
between the related components, the complexity of theexpressions in the relation specification will vary.
relation {domainType : Diagram
rangeType : ComputationalConfiguration
matchCond : true
subRel : { CircleRelCompObj(diagram.circles,config.objects ) }}relation {domainType : Circle
rangeType : CompObject
matchCond : compObj.name = circle.label.text
subRel : { RectangleRelInterface(circle.connections,object.interfaces ) }}