UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment
Daisuke Hashimoto
Technologic Arts Inc.
hashimoto@tech-arts.co.jp

Hiroshi Miyazaki
Fujitsu, Ltd.
miyazaki.hir-02@jp.fujitsu.com

Akira Tanaka
Hitachi, Ltd.
tanakaak@itg.hitachi.co.jp

Abstract
The advance of UML® 2.0 standardization work by OMG™
provides a good opportunity for ODP community to leverage
UML 2.0 to show the value of ODP. In this paper, we examine
issues in applying UML 2.0 to ODP Engineering andTechnology Viewpoint Languages, and show how we may beable to use UML to represent those ODP Viewpoint
specifications.

1. Introduction
With the wide acceptance of Unified Modeling Language [2]in the industry, there is a growing interest in applying UML torepresent ODP [1] viewpoint specifications. This direction isbeneficial to both sides, since ODP modelers will eventually beable to get ODP modeling tool based on UML tools, and UML
modelers will get a robust way of organizing their UML models.
This comes from ISO/IEC and ITU-T’s joint project called “Useof UML for ODP system specifications,” and also comes fromvarious “Enterprise Architecture [6]” practices where rows in
two-dimensional matrix are usually quite similar to ODP
viewpoints. The combination of UML and ODP with OMG’s
MDA initiative [3][4] will create a good foundation for systems’
lifecycle management. The content of this paper is awork-in-progress level, based on INTAP’s technical report [5],and is a result of elaborating current Committee Draft of “Use of
UML for ODP system specifications” standard by our group. In
this paper, we identify and examine issues in modelingEngineering and Technology Viewpoints with UML 2.0, andpropose one possible UML 2 model diagrams for thoseviewpoint specifications.

2. Engineering Viewpoint – Issues
discussion for UML modeling
2.1

Fig. R2 An example of a basic client / server channel

andFig. R3 An example of a multi-endpoint channel

Target Architectural Diagrams

First we need to identify kinds of architectural diagrams to be
described in UML. Some candidates are found in RM-ODP Part
3, Clause 8 Figure 2 to 6. The following figures (R2 to R8) are
extracts from RM-ODP Part 3 standard document. In order toavoid confusion, we will add “R” to refer to those diagrams.

Fig. R4 Example structure supporting a basic
engineering object

Fig. R5 Example structure of a capsule

Nucleus:
Nucleus may either be treated as Engineering Object orcontainer. It could be Engineering object, since it provides
Nucleus Services to all types of Engineering Objects. It could
also be considered as a container, in which Capsule andContainers may reside within.
Channel:Channel may either be treated as a container or a structured
Object or Class etc. The issue associated with Channel is thatboth Channel and Capsule shares the same Engineering Objects(Stub, Binder, and ProtocolObject) and we do not haveoverlapping diagrams even in UML 2.0.
Template:<X> Template is defined in RM-ODP Part 2 as “Thespecification of the common features of a collection of <X>s in
sufficient detail that an <X> can be instantiated using it. <X>
can be anything that has a type.” The templates in Engineering
Viewpoint Language are Cluster template, Checkpoint, Clustercheckpoint. However, the definitions of those Engineering
templates seem more like “snapshot” than the Part 2 definition
implies. The choice of UML model element for template has
impact on the choice of UML model element for Engineering
Object.

2.3

Fig. R6 Example structure of a node
From those example figures, we can identify essential target
diagrams, which are Channel structure diagram (covering
Figure R2 and R3) and Capsule structure diagram (covering
Figure R4, R5, and R6).
In addition, to cover all the Engineering concepts, we willneed UML diagrams describing domains and templates.

2.2

Representation of Engineering Concepts

Engineering Object:
The issue is the choice of UML elements representing
Engineering Object, which includes at least Basic Engineering
Object (we will refer it as BEO in this paper), CapsuleManager,
ClusterManager, Stub, Binder, ProtocolObject, and Interceptor.
It could be modeled with UML Object (InstanceSpecification ofClass), UML Class, UML InstanceSpecification of Component,
or UML Component. In either case, UML 2’s Structured
Classifier will help us describe the internal structure of Channel
and Capsule.
Containers:
The next are containers such as Node, Nucleus, Capsule, andCluster. Those elements are defined as “a configurations of(basic) engineering objects …” in RM-ODP Part 3. It may bepossible to use UML Node to represent ODP Node. However, if
we take this approach, only available UML diagram will be
Deployment Diagram, and UML 2 only allows certain types ofmodeling elements (e.g. Node, Artifact) to be placed within aNode. Note that it was possible to take this approach with UML
1.4, since it was legal to place Component within a Node. The
UML diagram we need has to have a capability to show theinternal and logical structure of ODP Node, similar discussion
regarding Class or Component in Engineering Object may also
apply.

Interactions between Engineering Objects

In Computational Viewpoint, RM-ODP Part 3 provides
various concepts to deal with interactions with interface andsignature. In Engineering Viewpoint, however, we do not havespecific concepts for this purpose, and that makes it difficult tomodel interactions between Engineering Objects. One
possibility is to consider “recursive application of viewpoints.”
If we can apply Computational Viewpoint Language tointeractions between BEOs, we will get a capability to specify
this. In that case, the modeling element will represent
Engineering Object with Computational aspects. The issue
becomes how to do this in UML. For instance, do we want toallow UML Class or Component or InstanceSpecification
stereotyped as “«NV_BEO» «CV_Object»?”
In addition, if we are to allow “recursive application of
viewpoints” as described here, we would need to consider thealignment of base classes for corresponding viewpoint profile.

2.4

Engineering Functions

In Engineering Viewpoint, there are functionalities defined asa part of its language. Those are Checkpointing, Deactivation,
Cloning, Recovery, Reactivation, and Migration. Those aredifferent from other concepts, since they are representing
functions possibly including behaviors. One possibility is to
apply “recursive application of viewpoints” again, and make useof Enterprise Viewpoint’s Objective and Process etc. concepts tomodel those functions as «EV_Objective» with behaviors as«EV_Process» expressed with Activity Diagram.

2.5

ODP functions

In RM-ODP Part 3, many ODP functions are described.
When defining ODP viewpoint specifications, those common
functions may need to be explicitly included. An example of
ODP function is ODP Trader, where the ODP Trader standard
defines Enterprise, Information, and Computational Viewpoint
specifications of itself. The issues are how we can identify,

reference, and include those functions in Engineering Viewpoint
specifications.

2.6

Domains

Domain concept in RM-ODP is defined as follows. <X>
Domain is “A set of objects, each of which is related by acharacterizing relationship <X> to a controlling object. Every
domain has a controlling object associated with it.” It is a set ofobjects, rather than a configuration of objects. The issue is which
UML element is suitable for representing this “a set of objects”
concept.
Also, since the same Engineering Object may be a member ofseveral different kinds of domains at the same time (e.g.
NamingDomain_1, SecurityDomain_2, and PolicyDomain_3etc.), UML element representing domain should allow sharingof objects. If we choose Class, parts may be shared. If wechoose Component, it may become issues. If we choose
Package, we will need to use «import»/«access» etc. to haveaccess to those elements contained in other Packages.

are new types of middleware emerging for Grid and Utility
Computing, Wireless Networking, and Collaboration
Environment etc. Also, various best practices and architectural
styles (such as MVC) were developed and in use. Now may be
a good time to define architectural styles as Engineering
Templates and publish them for use in mapping Computational
Viewpoint specifications to Engineering Viewpoint
specifications. The issue is how to define those architectural
styles with UML.

3. Engineering Viewpoint – Possible UML 2
Models
3.1

Profile definition

The first step is to decide which UML element should be
used to represent Engineering Viewpoint Language, especiallyEngineering Object. We also need to consider about related
templates. The choice we made in this paper is use of UML
Component for Engineering Objects. A Component is closer toreal world software component than Class, and UML 2 also
provides Component with structuring capability. The following
is a Class diagram showing partial UML 2 Profile definition.
The stereotypes have prefix NV_, which is a rule for defining
stereotype names for Engineering Viewpoint in Use of UML for
ODP system specifications standard. Most (not all) stereotypes
extend metaclass Component.

Figure 1 Engineering objects and domains

2.7

Selective Transparencies

Computational Viewpoint specifications are defined in
distribution transparent manner, and the degree of distribution
transparency may be specified in a “transparency schema”
associated with “a specification that uses specific ODP functions
and engineering structures to provide the required form ofmasking.” This may be considered as a mapping specificationfrom Computational Viewpoint to Engineering Viewpoint.
And, this implies that given one Computational Viewpoint
specification, there will be a variety of Engineering Viewpoint
specifications, each corresponding to different transparency
schema. Although this issue may be mainly related with
Computational Viewpoint, it has an impact on Engineering
Viewpoint specification and Engineering Viewpoint’s
correspondence to Computational Viewpoint specification.

2.8
Architectural
Templates or Patterns)

Styles(orEngineering

Since the day RM-ODP Part 3 became International Standard,
five or more years have passed, and now there are various typesof commercial and open source middleware which in fact
implements most of the Engineering Viewpoint concerns, e.g.
CORBA ORBs, J2EE application servers. .NET, Web Services,
SOA, and Message Oriented Middleware, etc. Even more, there

Figure 2 UML 2 Profile for Engineering Viewpoint
Language

3.2

Node configuration

The computational to engineering correspondence, or modeltransformation, is not within the scope of this paper. However, toachieve this, we will at least need a transformation pattern andmechanism. Assuming that there is one, the output N-tierdistributed system’s node configuration may look like thefollowing. In this case, there are a Node for user interaction, aNode for front-end, a Node responsible for business logic, andtwo Nodes for persistent data. In essence, BEOs derived form
computational objects and engineering objects for providing
specified transparency scheme will be deployed on those nodes.

Interesting observation is whether Capsule and Cluster shouldhave interfaces or not, since Capsule is a unit of resource
assignment, Cluster is a unit of activations/deactivations, andthey have associated Managers. If they have interfaces, thenwhat kind of interface should they be?

3.3

Figure 3 Example Node Configurations

3.3

Node Structure Diagrams

As discussed before, we need to be able to model structure ofeach Node. Sample structural UML Diagram is shown in Figure
4, which is a UML Component Diagram. We have a Nodecontaining two Capsules, one of which has two Clusters
containing two BEOs. There are BEOs (e.g. BEO_1AA) whichhave access to the services provided by Cluster Manager, which
in turn has access to services provided by Capsule Managers.
Other BEOs (e.g. BEO_1AB) have access to a Stub forcommunication, and the Stub interacts with a Binder, and the
Binder interacts with a Protocol Object.

Channel Diagrams

A Channel may be represented with the following UML 2
diagram. The same Engineering Objects appear in Figure 4 andFigure 5 (i.e., Stub, Binder, Protocol Object and Interceptor).
Figure 4 shows the structure, interfaces with ports, and services
in the hierarchy. Figure 5 shows membership of the Channel
Package. Those two diagrams complement with each other toprovide different views to the same set of Engineering Objects
that make up a part of Node and a Channel. In Figure 5, achannel is defined as a package containing engineering objects,
which are the components necessary for enabling
communication between Nodes. There are three BEOs involved(not shown): a BEO interacting with Stub_1, a BEO interactingwith Stub_2, and a BEO interacting with Stub_3. This channel
is defined to serve for those BEOs interacting with each other.
The structural aspect, e.g. Stub_1 interacts with Binder_1, is
described in structural diagram like Figure 4, and therefore thischannel diagram just defines the member engineering objects.

Figure 5 Example UML 2 model for Channel

Figure 4 Example UML 2 model for Node, Capsule,
Cluster, and BEO

Figure 4 and 5 together cover most of the figures (R2 to R8)from RM-ODP Part 3, except for control interfaces, which arejust one kind of interfaces we can add to engineering objects.
From other perspective, a channel diagram is a package
importing necessary member engineering objects from Node

structure packages for communication.

include it in this diagram.
In Figure 9, CommunicationDomain_A is defined as a
package containing a CommunicationControllingObject,
ProtocolObject_1 to 3, and an Interceptor_A. Those objects
share the same communication protocol, and are able tocommunication with each other. Note that not all
ProtocolObjects included in this package may be instantiated atcertain location in time.

Figure 6 Example Channel

3.4

BEO configuration

Like in computational viewpoint, it is sometimes necessary to
specify interactions between BEOs. One of the issues is that the
diagram will become complex if BEO configuration is placed in
Node Structure diagram (Figure 4). One possibility is to isolate
Clusters from the Node Structure and use component diagram(in our case) to describe the interaction. We may need to use e.g.
double stereotypes to represent computational aspects ofengineering object, e.g. for interfaces, signatures, andinteractions for engineering objects. In Figure 7, a Cluster
contains two BEOs providing services through the Cluster’sPort and Interface.

Figure 9 Example Communication Domain
Also from different perspective, a CommunicationDomain canbe described as the package importing necessary member
engineering objects.
The following diagram shows CommunicationDomain package
containing only one engineering object (in this case it is acontrolling object) accessing other member engineering objects
from various Node structure packages.

Figure 7 Example basic BEO Configuration
Figure 8 shows a case where two BEOs in a same Cluster havedependency, or interaction. If we need to specify this interaction,interface, and signatures, we may need to borrow stereotype
elements from already defined Computational Profile.
Figure 10 Example Communication Domain (2)3.5

Figure 8 Example BEO configuration including
computational aspects

3.4

Correspondence

From Engineering Viewpoint to Computational Viewpoint
Our assumption is that each BEO has one to one relationshipto corresponding Computational Object (from Engineering toComputational, not vice versa). This could be expressed as
dependency from BEO sub-Package in Engineering Viewpoint
Package to Computational Objects in Computational Viewpoint
Package in UML. Note that the distribution support mechanism
part of Engineering Viewpoint Language model elements may
have one to one relationship with specified transparencies intransparency schema.

Domains

Domain may be represented with the following UML 2
diagrams (Packages). One missing element is a Policy thatControlling Object is enforcing. Since Policy concept, at least
the base class for it, should be aligned with other viewpoint (i.e.
Enterprise Viewpoint), and that is not concluded yet, we did not

From Engineering Viewpoint to Technology Viewpoint
This correspondence is closely related to OMG’s MDA
initiative where Platform Independent Model is transformed to
Platform Specific Model. In this case, Platform means real
software and hardware platforms. It is our expectation that when

MDA standards get mature, they will become an enabling
technology for specifying Viewpoint Correspondence.
Each Engineering Objects may be implemented with multiple
Technology Objects, and multiple Engineering Objects may be
implemented with one Technology Object. This could be
expressed also as dependency between two Viewpoint
Packages.

defining stereotype names for Engineering Viewpoint in Use of
UML for ODP system specifications standard.

4. Technology Viewpoint – Issues and discussion
for UML modeling
4.1

Hardware, Software and Network

In UML Deployment Diagram, main modeling elements are
Node and Artifact. Typical representation of hardware elements
such as CPU and memory is by the use of tagged values toNode, and we follow this approach. For operating systems andmiddleware, UML 2 introduced new metaclass
ExecutionEnvironment to Node. We can add, if necessary, ODP
semantics to this model element. Software implementing BEOs
can be modeled as Artifact. CORBA Middleware and
POSIX-compliant Operating System, for instance, may bemodeled as or based on ExecutionEnvironment. Network likethe Internet and LAN can be modeled as a Node, althoughhardware/software aspects of network can be treated differently.
The discussion may be regarding the extent for defining UML
Profile for Technology Viewpoint, since UML 2 provides asimilar set of modeling elements. Our approach is to define
minimal extensions and to see what is missing based on users’
experience.

4.2

Figure 11 UML 2 Profile for Technology Viewpoint
Language

5.2

Node Configuration

In technology viewpoint, we can show network components
and hardware components as well as software components. Thisis the difference with Node Configuration of engineering
viewpoint.

Representation of Technology Concepts

Technology Object
Technology Objects, covering software, hardware andnetwork, may be represented with UML Artifact or Node(including Node within Node).
Implementable standard may be considered as a part ofspecification Technology Objects implements. It could bemodeled as UML Class or Component.
Implementation is defined as “a process of instantiation whose
validity can be subject to test.” A process may be represented
with UML Activity Diagram. Since “Process” concept has beenrefined in Enterprise Language, we may need to refer to related
modeling elements in Engineering Viewpoint.
IXIT (Implementation eXtra Information for Testing) may be
represented with UML Comments as annotations to Technology
Viewpoint specifications. However, there may be a case where
an IXIT contains a lot of information and could not be describedwithin a UML Comment, we may need to introduce amechanism to refer external documents.

Figure 12 Example Node Configuration

5.3

Node Structure Diagram

The following is an example diagram showing physicalstructure of a node with hardware, software, and network
elements. In this diagram, there is a Node which is connectedwith the Internet, and which hosts POSIX compliant operating
system and J2EE compliant middleware, and two applications
are introduced as Artifacts to run under those execution
environments.

5. Technology Viewpoint – Possible UML 2
Models
5.1

Profile definition

The following is a diagram showing a partial UML 2 Profile
definition. In order to represent hardware, software, and network
as Technology Object, two base classes are used for Technology
Object. The stereotypes have prefix TV_, which is a rule for

Figure 13 Example Node Structure

5.4

IXIT

IXIT stands for Implementation eXtra Information for Testing,and is one of technology viewpoint concepts. Since this isassociated with technology objects, and since we do not haveformal way of modeling “extra information,” UML Comment isused.

Figure 14 Example IXIT

5.5

Correspondence

From Technology Viewpoint to Engineering Viewpoint
Each Technology Object has one to one relationship tocorresponding Engineering Object. This could be expressed as
dependency from Technology Objects in Technology Viewpoint
Package to Engineering Objects in Engineering Viewpoint
Package.

6.

Conclusions

There may be multiple ways to represent ODP viewpoint
specifications with UML 2.0. Regarding approaches, we
believe we have choices e.g. on class-based modeling vs.
component-based modeling and on class/component basedmodeling vs. instance (object/component instance) basedmodeling. In this paper we took component-based modelingapproach. And, if you compare the diagrams presented in thispaper with the diagrams in RM-ODP Part 3 (i.e. Figure R2 to
R8 in 2.1), we believe we have successfully demonstrated mostof the Engineering Viewpoint Specifications with UML 2.0 and
its Profiles. We also have demonstrated a possible UML Profile
for Technology Viewpoint, which also works. However, weneed to develop consistent UML Profiles for all the ODP
viewpoints to allow describe different viewpoint’s concern incertain viewpoint’s specification. Another important point isthat the UML mapping should be practical and the results
should be accessible and usable. We hope that UML Profile for
ODP to be standardized soon and the profile data be developed,
published, and become openly available to interested parties,
that is, UML modelers and ODP modelers.

Acknowledgements
The work described here was mostly done within INTAP
Open Distributed Processing Committee, and includes someideas and discussions from International and JapaneseCommittee for SC7/WG19. The authors would also like tothank Mr. David Frankel for his contribution in [5] to this UML
and ODP work.

References[1] RM-ODP, ITU-T Recommendation X.901 to X.904 and ISO/IEC
10746-1 to 4
http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/ITTF.htm??Redirect=1[2] UML 2.0 Superstructure, OMG,
http://www.omg.org/cgi-bin/doc?ptc/2004-10-02[3] Model Driven Architecture, Document number: ormsc/01-07-01[4] MDA Guide, Document number: omg/03-06-01[5] Applying EDOC and MDA to the RM-ODP Engineering andTechnology Viewpoints, INTAP Technical Report, David Frankel
Consulting, http://www.net.intap.or.jp/e/odp/odp-techguide.pdf[6]FederalEnterpriseArchitecture
Reference
Model,
http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html