UML 2.

0 Diagram Interchange RFP ad/2001-02-39

Object Management Group

250 First Avenue, Suite 201
Needham, MA 02494
U.S.A.

Telephone: +1-781-444 0404

Facsimile: +1-781-444 0320

UML 2.0 RFP

Request For Proposal
UML 2.0 Diagram Interchange RFP
OMG Document: ad/2001-02-39

Submissions due: October 22, 2001

Objective of this RFP

The Unified Modeling Language is a language for visualizing,
specifying, constructing and documenting the artifacts of software
systems. It is a general-purpose modeling language that can be used with
all major object and component methods and applied to all application
domains. The OMG adopted the UML 1.1 specification in November
1997. Since then UML Revision Task Forces have produced several
minor revisions, the most recent being the UML 1.4 specification, which
is to be adopted in early 2001.

This Request for Proposal (RFP) is the 4th in a series of RFPs under the
UML 2.0 umbrella. The first three RFPs have already been issued and
focus on (a) UML Infrastructure (b) UML Superstructure and (c) OCL
respectively. Please see www.omg.org/technology/uml for more
information on OMG UML™.

The fourth (this RFP) focuses on the problem of diagram interchange.

RFP March 07, 2001 1

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

1.0 Introduction

1.1 Goals of OMG

The Object Management Group (OMG) is the world's largest software
consortium with a membership of over 800 vendors, developers, and end
users. Established in 1989, its mission is to promote the theory and
practice of Object Technology (OT) for the development of distributed
computing systems.

A key goal of OMG is create a standardized object-oriented architectural

framework for distributed applications based on specifications that
enable and support distributed objects. Objectives include the reusability,
portability, and interoperability of object-oriented software components in
heterogeneous environments.To this end, the OMG adopts interface and
protocol specifications, based on commercially available object
technology, that together define an Object Management Architecture
(OMA).

1.2 Organization of this document

The remainder of this document is organized as follows:

Chapter 2 - Architectural Context - background information on OMG’s

Object Management Architecture.

Chapter 3 - Adoption Process - background information on the OMG

specification adoption process.

Chapter 4 - Instructions for Submitters - explanation of how to make a

submission to this RFP.

Chapter 5 - General Requirements on Proposals - requirements and

evaluation criteria that apply to all proposals submitted to OMG.

Chapter 6 - Specific Requirements on Proposals - problem statement, scope

of proposals sought, mandatory and optional requirements, issues to be
discussed, evaluation criteria, and timetable that apply specifically to this
RFP.

Additional RFP-specific chapters may also be included following

Chapter 6.

RFP March 07, 2001 2

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

1.3 References
The following documents are referenced in this document:

Richard Soley (ed.), Object Management Architecture Guide, Third

Edition, Wiley, June 1995. OMG Document ab/97-05-05, or successor.

The Common Object Request Broker: Architecture and Specification,

Revision 2.1, August 1997. OMG Document formal/97-09-01, or
successor.

CORBAservices: Common Object Services Specification, Revised Edition,

July 1997. OMG Document formal/97-07-04, or successor.

CORBAfacilities Architecture, Revision 4.0, November 1995.

Business Committee RFP Attachment, OMG Document omg/97-10-01.

Policies and Procedures of the OMG Technical Process, OMG Document

pp/97-06-01 or successor.

These documents can be obtained by contacting OMG at

[email protected]. Many OMG documents, including this document,
are available electronically from OMG’s document server. Send a
message containing the single line ‘‘help’’ to [email protected] for more
information, or visit the OMG Web page (URL http://www.omg.org/),
which also has more information about OMG in general. If you have
general questions about this RFP send email to [email protected].

RFP March 07, 2001 3

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

2.0 Architectural Context

2.1 Object Management Architecture

The Object Management Architecture Guide (OMAG) describes OMG’s
technical objectives and terminology and provides the conceptual
infrastructure upon which supporting specifications are based. The
guide includes the OMG Object Model, which defines common semantics
for specifying the externally visible characteristics of objects in a
standard implementation-independent way, and the OMA Reference
Model.

The Reference Model identifies and characterizes the components,

interfaces, and protocols that compose the OMA. This includes the
Object Request Broker (ORB) component that enables clients and objects
to communicate in a distributed environment, and four categories of
object interfaces:

• Object Services are interfaces for general services that are likely to be
used in any program based on distributed objects.

• Common Facilities are interfaces for horizontal end-user-oriented

facilities applicable to most application domains.

• Domain Interfaces are application domain-specific interfaces.

• Application Interfaces are non-standardized application-specific

interfaces.

A second part of the Reference Model introduces the notion of domain-

specific Object Frameworks. An Object Framework component is a
collection of cooperating objects that provide an integrated solution
within an application or technology domain and which is intended for
customisation by the developer or user.

Through a series of RFPs, OMG is populating the OMA with detailed

specifications for each component and interface category in the
Reference Model. Adopted specifications include the Common Object
Request Broker Architecture (CORBA), CORBAservices, and
CORBAfacilities.

The wide-scale industry adoption of OMG's OMA provides application

developers and users with the means to build interoperable software

RFP March 07, 2001 4

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

systems distributed across all major hardware, operating system, and

programming language environments.

2.2 CORBA
The Common Object Request Broker Architecture defines the programming
interfaces to the OMA ORB component. An ORB is the basic mechanism
by which objects transparently make requests to - and receive responses
from - each other on the same machine or across a network. A client need
not be aware of the mechanisms used to communicate with or activate an
object, how the object is implemented, nor where the object is located.
The ORB thus forms the foundation for building applications
constructed from distributed objects and for interoperability between
applications in both homogeneous and heterogeneous environments.

The OMG Interface Definition Language (IDL) provides a standardized way

to define the interfaces to CORBA objects. The IDL definition is the
contract between the implementor of an object and the client. IDL is a
strongly typed declarative language that is programming language-
independent. Language mappings enable objects to be implemented and
sent requests in the developer's programming language of choice in a
style that is natural to that language.

CORBA 2.0 is an extension and restructuring of the earlier CORBA 1.2

specification. CORBA 2.0 is a family of specifications consisting of the
following components:

• Core (including IDL syntax and semantics)

• Interoperability

• An expanding set of language mappings, including:

C
C++
SmallTalk
Ada95
COBOL

Each component is a separate compliance point. The minimum required

for a CORBA-compliant implementation is adherence to the core and one
language mapping.

RFP March 07, 2001 5

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

2.3 CORBA/Interoperability
Interoperability between CORBA-compliant ORBs is provided by OMG's
Internet Inter-ORB Protocol (IIOP). Adopted in December 1994 as the
mandatory CORBA 2.0 protocol for ‘‘out of the box’’ interoperability,
IIOP is the TCP/IP transport mapping of a General Inter-ORB Protocol
(GIOP). IIOP enables requests to be sent to networked objects managed
by other ORBs in other domains.

The OMG interoperability architecture also accommodates

communication using optional Environment-Specific IOPs (ESIOPs), the
first of which is the DCE-CIOP.

2.4 CORBAservices
Object Services are general purpose services that are either fundamental
for developing useful CORBA-based applications composed of
distributed objects, or that provide a universal - application domain-
independent - basis for application interoperability.

Object Services are the basic building blocks for distributed object
applications. Compliant objects can be combined in many different ways
and put to many different uses in applications. They can be used to
construct higher level facilities and object frameworks that can
interoperate across multiple platform environments.

Adopted OMG Object Services are collectively called CORBAservices

and include Naming, Events, LifeCycle, Persistent Object, Relationships,
Externalization, Transactions, Concurrency Control, Licensing, Query,
Properties, Security, Time, Collections, and Trading Services.

2.5 CORBAfacilities
Common Facilities are interfaces for horizontal end-user-oriented
facilities applicable to most domains. Adopted OMG Common Facilities
are collectively called CORBAfacilities and include an OpenDoc-based
Distributed Document Component Facility.

A specification of a Common Facility or Object Service typically includes

the set of interface definitions - expressed in OMG IDL - that objects in
various roles must support in order to provide, use, or participate in the
facility or service. As with all specifications adopted by OMG, facilities
and services are defined in terms of interfaces and their semantics, and
not a particular implementation.

RFP March 07, 2001 6

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

2.6 Object Frameworks and Domain Interfaces

Unlike the interfaces to individual parts of the OMA ‘‘plumbing’’
infrastructure, Object Frameworks are complete higher level components
that provide functionality of direct interest to end-users in particular
application or technology domains. They are vertical slices down the
OMG ‘‘interface stack’’.

Object Frameworks are collections of cooperating objects categorized

into Application, Domain, Facility, and Service Objects. Each object in a
framework supports (through interface inheritance) or makes use of (via
client requests) some combination of Application, Domain,
CORBAfacilities, and CORBAservices interfaces.

A specification of an Object Framework defines such things as the

structure, interfaces, types, operation sequencing, and qualities of service
of the objects that make up the framework. This includes requirements
on implementations in order to guarantee application portability and
interoperability across different platforms.

Domain Task Force RFPs are likely to focus on Object Framework

specifications that include new Domain Interfaces for application
domains such as Finance, Healthcare, Manufacturing, Telecom,
Electronic Commerce, and Transportation.

RFP March 07, 2001 7

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

3.0 Adoption Process

3.1 Introduction
OMG adopts specifications for interfaces and protocols by explicit vote
on a technology-by-technology basis. The specifications selected each fill
in a portion of the OMA Reference Model. OMG bases its decisions on
both business and technical considerations. Once a specification is
adopted by OMG, it is made available for use by both OMG members
and non-members.

For more detailed information on the adoption process see the Policies
and Procedures of the OMG Technical Process.

3.2 Rôle of Board of Directors

The OMG Board of Directors votes to formally adopt specifications on
behalf of OMG. The OMG Technology Committees (Domain and
Platform TCs) and Architecture Board (AB) provide technical guidance
to the Board of Directors. In addition, the Business Committee of the
Board provides guidance to ensure that implementations of adopted
specifications are made commercially available.

3.3 Rôle of Technology Committees and Architecture Board

Submissions to RFPs are evaluated by the TC Task Force (TF) that
initiated the RFP. Selected specifications are recommended to the parent
TC after being reviewed by the Architecture Board for consistency with
the OMA. The full TC then votes to recommend adoption to the OMG
Board.

3.4 Rôle of Task Forces

The role of the initiating TF is to technically evaluate submissions and
select one or more specifications that satisfy the requirements of the RFP.
The process typically takes the following form:

• Voter Registration

Interested TF members may register to participate in specification

selection votes for an RFP. Registration ends on a specified date 6 or
more weeks after the announcement of the registration period. The
registration closure date is typically around the time of initial

RFP March 07, 2001 8

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

submissions. Companies who have submitted an LOI are

automatically registered to vote.

• Initial Submissions

Initial submissions are due by a specified deadline. Submitters

normally present their proposals at the next following meeting of the
TF. Initial submissions are expected to be full and complete proposals
and working implementations of the proposed specifications are
expected to exist at the time of submission.

• Evaluation Phase

A period of approximately 120 days follows during which the TF

evaluates the submissions. During this time submitting companies
have the opportunity to revise and/or merge their initial submissions,
if they so choose.

• Revised Submissions

Final revised submissions are due by a specified deadline. Submitters

again normally present their proposals at the next following meeting
of the TF. Finalists may be requested to demonstrate implementations
of their proposal.

• Selection Vote

When the registered voters of the TF believe that they sufficiently

understand the relative merits of the revised submissions, a
specification selection vote is taken.

3.5 Goals of the evaluation

The primary goals of the TF evaluation process are to:

• Provide a fair and open process

• Force a critical review of the submissions and discussion by all

members of the TF

• Give feedback to allow submitters to address concerns in their revised

submissions

• Build consensus on acceptable solutions

• Enable voting members to make an informed selection decision

Submitters are expected actively to contribute to the evaluation process.

RFP March 07, 2001 9

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

4.0 Instructions for Submitters

4.1 OMG Membership

Submissions to this RFP may only be made by Platform, Domain or
Contributing members of the OMG. To submit to an RFP issued by the
Platform Technology Committee an organisation must be a Platform or
Contributing member at the date of the submission deadline, while for
Domain Technology RFPs the submitter or submitters must be either
Contributing or Domain members. Submitters sometimes choose to
name other organisations that support a submission in some way;
however, this has no formal status within the OMG process, and for
OMG’s purposes confers neither duties nor privileges on the
organisations concerned.

4.2 Submission Effort

Unlike a submission to an OMG Request For Information (RFI), an RFP
submission may require significant effort in terms of document
preparation, presentations to the initiating TF, and participation in the
TF evaluation process. Several staff months of effort might be necessary.
OMG is unable to reimburse submitters for any costs in conjunction with
their submissions to this RFP.

4.3 Letter of Intent

A Letter of Intent (LOI) must be submitted to the OMG Business
Committee signed by an officer of your organization signifying your
intent to respond to the RFP and confirming your organization’s
willingness to comply with OMG’s terms and conditions, and
commercial availability requirements. These terms, conditions, and
requirements are defined in the Business Committee RFP Attachment and
are reproduced verbatim in section 4.4 below.

The LOI should designate a single contact point within your

organization for receipt of all subsequent information regarding this RFP
and your submission. The name of this contact will be made available to
all OMG members. The LOI is typically due 60 days before the deadline
for initial submissions. LOIs must be sent by fax or paper mail to the
‘‘RFP Submissions Desk’’ at the main OMG address shown on the first
page of this RFP.

Here is a suggested template for the Letter of Intent:

RFP March 07, 2001 10

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

This letter confirms the intent of <___organisation required___> (the

organisation) to submit a response to the OMG <___RFP name required___>
RFP. We will grant OMG and its members the right to copy our response for
review purposes as specified in section 4.7 of the RFP. Should our response be
adopted by OMG we will comply with the OMG Business Committee terms set
out in section 4.4 of the RFP and in document omg/98-03-01.

<____contact name and details required____> will be responsible for liaison

with OMG regarding this RFP response.

The signatory below is an officer of the organisation and has the approval and
authority to make this commitment on behalf of the organisation.

<___signature required____>

4.4 Business Committee RFP Attachment

This section contains the text of the Business Committee RFP attachment
concerning commercial availability requirements placed on submissions.
This attachment, available separately as document omg/98-03-01, was
approved by the OMG Board in February 1998.

__________________________________________

Commercial considerations in OMG technology adoption

A1 Introduction
OMG wishes to encourage rapid commercial adoption of the specifications it
publishes. To this end, there must be neither technical, legal nor commercial
obstacles to their implementation. Freedom from the first is largely judged
through technical review by the relevant OMG Technology Committee; the
second two are the responsibility of the OMG Business Committee. The BC also
looks for evidence of a commitment by a submitter to the commercial success of
products based on the submission.

A2 Business Committee evaluation criteria

A2.1 Viable to implement across platforms

While it is understood that final candidate OMG submissions often combine
technologies before they have all been implemented in one system, the Business
Committee nevertheless wishes to see evidence that each major feature has been
implemented, preferably more than once, and by separate organisations. Pre-
product implementations are acceptable. Since use of OMG specifications should

RFP March 07, 2001 11

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

not be dependant on any one platform, cross-platform availability and

interoperability of implementations should be also be demonstrated.

A2.2 Commercial availability

In addition to demonstrating the existence of implementations of the
specification, the submitter must also show that products based on the
specification are commercially available, or will be within 12 months of the date
when the specification was recommended for adoption by the appropriate Task
Force. Proof of intent to ship product within 12 months might include:

• A public product announcement with a shipping date within the time limit.

• Demonstration of a prototype implementation and accompanying draft user

documentation.

Alternatively, and at the Business Committee's discretion, submissions may be

adopted where the submitter is not a commercial software provider, and
therefore will not make implementations commercially available. However, in
this case the BC will require concrete evidence of two or more independent
implementations of the specification being used by end-user organisations as
part of their businesses.

Regardless of which requirement is in use, the submitter must inform the OMG
of completion of the implementations when commercially available.

A2.3 Access to Intellectual Property Rights

OMG will not adopt a specification if OMG is aware of any submitter, member
or third party which holds a patent, copyright or other intellectual property
right (collectively referred to in this policy statement as "IPR") which might be
infringed by implementation of such specification, unless OMG believes that
such IPR owner will grant a license to implementers (whether OMG members
or not) on non-discriminatory and commercially reasonable terms which wish to
implement the specification. Accordingly, the submitter must certify that it is
not aware of any claim that the specification infringes any IPR of a third party
or that it is aware and believes that an appropriate non-discriminatory license is
available from that third party. Except for this certification, the submitter will
not be required to make any other warranty, and specifications will be offered by
OMG for implementation "as is". If the submitter owns IPR to which an
implementation of a specification based upon its submission would necessarily
be subject, it must certify to the Business Committee that it will make a suitable
license available to any implementer on non-discriminatory and commercially
reasonable terms, to permit development and commercialisation of an
implementation that includes such IPR.

RFP March 07, 2001 12

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

It is the goal of the OMG to make all of its specifications available with as few
impediments and disincentives to adoption as possible, and therefore OMG
strongly encourages the submission of technology as to which royalty-free
licenses will be available. However, in all events, the submitter shall also certify
that any necessary license will be made available on commercially reasonable,
non-discriminatory terms. The submitter is responsible for disclosing in detail
all known restrictions, placed either by the submitter or, if known, others, on
technology necessary for implementation of the specification.

A2.4 Publication of the specification

Should the submission be adopted, the submitter must grant OMG (and its
sublicensees) a world-wide, royalty-free licence to edit, store, duplicate and
distribute both the specification and works derived from it (such as revisions and
teaching materials). This requirement applies only to the written specification,
not to any implementation of it.

A2.5 Continuing support

The submitter must show a commitment to continue supporting the technology
underlying the specification after OMG adoption, for instance by showing the
BC development plans for future revisions, enhancement or maintenance.

__________________________________________

4.5 Responding to RFP items

4.5.1 Separate proposals

Unless otherwise indicated in Chapter 6, independent proposals are

solicited for each separate item in the RFP. Each item is considered a
separate architectural entity for which a proposal may be made. A
submitter may respond to any or all items. Each item will be evaluated
independently by the initiating TF. Submissions that do not present
clearly separable proposals for multiple items may therefore be at a
disadvantage.

It should be noted that a given technology (e.g. software product) may

support two or more RFP items. So long as the interfaces for each item
are separable, this is not precluded.

RFP March 07, 2001 13

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

4.5.2 Complete proposals

Proposals for each separate RFP item must be complete. A submission

must propose full specifications for each item and address all the
relevant general and specific requirements detailed in this RFP.

4.5.3 Additional specifications

Submissions may include additional specifications for items not covered

by the RFP which they believe to be necessary and integral to their
proposal. Information on these additional items should be clearly
distinguished.

Submitters must give a detailed rationale as to why these specifications

should also be considered for adoption. However submitters should note
that a TF is unlikely to consider additional items that are already on the
roadmap of an OMG TF, since this would pre-empt the normal adoption
process.

4.5.4 Alternative approaches

Submitters may provide alternative RFP item definitions,

categorizations, and groupings so long as the rationale for doing so is
clearly stated. Equally, submitters may provide alternative models for
how items are provided within the OMA if there are compelling
technological reasons for a different approach.

4.6 Confidential and Proprietary Information

The OMG specification adoption process is an open process. Responses
to this RFP become public documents of the OMG and are available to
members and non-members alike for perusal. No confidentiality or
proprietary information of any kind will be accepted in a submission to
this RFP.

4.7 Copyright Waiver

If a submitted document is copyrighted, a waiver of copyright for
unlimited duplication by the OMG is required to be stated in the
document. In addition, a limited waiver of copyright is required that
allows each OMG member to make up to fifty (50) copies of the
document for review purposes only.

RFP March 07, 2001 14

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

4.8 Proof of Concept

Submissions must include a ‘‘proof of concept’’ statement, explaining
how the submitted specifications have been demonstrated to be
technically viable. The technical viability has to do with the state of
development and maturity of the technology on which a submission is
based. This is not the same as commercial availability. Proof of concept
statements can contain any information deemed relevant by the
submitter, for example:

‘‘This specification has completed the design phase and is the process
of being prototyped.’’

‘‘An implementation of this specification has been in beta-test for 4

months.’’

‘‘A named product (with a specified customer base) is a realization of

this specification.’’

It is incumbent upon submitters to demonstrate to the satisfaction of the

TF the technical viability of their proposal. OMG will favour proposals
based on technology for which sufficient relevant experience has been
gained in CORBA-based or comparable environments.

4.9 Format of RFP Submissions

This section provides guidance on how to structure your RFP
submission.

4.9.1 General

• Submissions that are concise and easy to read will inevitably receive
more consideration.

• Submitted documentation should be confined to that directly relevant

to the items requested in the RFP. If this is not practical, submitters
must make clear what portion of the documentation pertains directly
to the RFP and what portion does not.

• The models and terminology in the Object Management Architecture

Guide and CORBA should be used in your submission. Where you
believe this is not appropriate, describe and provide a rationale for the
models and terminology you believe OMG should use. Submitters are
encouraged to document their object models and designs using OMG
UML where appropriate, and to supply an OMG XMI representation
of the design (including a machine-readable copy) for the

RFP March 07, 2001 15

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

convenience of those wishing to import the UML model into design

tools.

4.9.2 Suggested Outline

A three part structure for submissions is suggested:

PART I

• Copyright Waiver (see 4.5)

• Submission contact point (see 4.2)

• Overview or guide to the material in the submission

• Overall design rationale (if appropriate)

• Statement of proof of concept (see 4.6)

• Resolution of RFP mandatory and optional requirements

Explain how your proposal satisfies the mandatory and (if applicable)
optional requirements stated in Chapter 6. References to supporting material
in Part II should be given.

In addition, if your proposal does not satisfy any of the general requirements
stated in Chapter 5, provide a detailed rationale.

• Responses to RFP issues to be discussed

Discuss each of the ‘‘Issues To Be Discussed’’ identified in Chapter 6.

PART II

• Proposed specification

PART III

• Summary of optional versus mandatory interfaces

Submissions must clearly distinguish interfaces that all implementations

must support from those that may be optionally supported.

• Proposed compliance points

Submissions should propose appropriate compliance points for

implementations.

• Changes or extensions required to adopted OMG specifications

RFP March 07, 2001 16

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

Submissions must include a full specification of any changes or extensions

required to existing OMG specifications. This should be in a form that
enables ‘‘mechanical’’ section-by-section revision of the existing specification.

• Complete IDL definitions

For reference purposes and to facilitate electronic usage, submissions should

reproduce in one place a complete listing in compilable form of the IDL
definitions proposed for standardization.

4.10 How to Submit

Submitters should send an electronic version of their submission to the
RFP Submissions Desk ([email protected]) at OMG by 5:00 PM U.S. Eastern
Standard Time (22:00 GMT) on the day of the submission deadline.
Acceptable formats are Postscript, ASCII, PDF, FrameMaker, Word, and
WordPerfect. However, it should be noted that a successful submission
must be supplied to OMG’s technical editors in Framemaker source
format, using the most recent available OMG submission template
(document ab/97-06-02 at the time of writing). The AB will not endorse
adoption of any submission for which appropriately-formatted
Framemaker sources are not available; it may therefore be convenient to
prepare all stages of a submission using this template.

Submitters should make sure they receive electronic or voice

confirmation of the successful receipt of their submission. Submitters
should also send, within three (3) working days after the submission
deadline, a single hardcopy version of their submission to the attention
of the ‘‘RFP Submissions Desk’’ at the main OMG address shown on the
first page of this RFP.

RFP March 07, 2001 17

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

5.0 General Requirements on Proposals

5.1 Mandatory Requirements

5.1.1 Proposals shall express interfaces in OMG IDL. Proposals should follow
accepted OMG IDL and CORBA programming style. The correctness of
the IDL shall be verified using at least one IDL compiler (and preferably
more then one). In addition to IDL quoted in the text of the submission,
all the IDL associated with the proposal shall be supplied to OMG in
compiler-readable form.

5.1.2 Proposals shall specify operation behaviour, sequencing, and side-effects (if
any).

5.1.3 Proposals shall be precise and functionally complete. There should be no

implied or hidden interfaces, operations, or functions required to enable
an implementation of the proposed specification.

5.1.4 Proposals shall clearly distinguish mandatory interfaces and other

specification elements that all implementations must support from those
that may be optionally supported.

5.1.5 Proposals shall reuse existing OMG specifications including CORBA,

CORBAservices, and CORBAfacilities in preference to defining new
interfaces to perform similar functions.

5.1.6 Proposals shall justify and fully specify any changes or extensions required
to existing OMG specifications. This includes changes and extensions to
CORBA inter-ORB protocols necessary to support interoperability. In
general, OMG favours upwards compatible proposals that minimize
changes and extensions to existing OMG specifications.

5.1.7 Proposals shall factor out functions that could be used in different
contexts and specify their interfaces separately. Such minimality fosters
re-use and avoids functional duplication.

5.1.8 Proposals shall use or depend on other interface specifications only

where it is actually necessary. While re-use of existing interfaces to avoid
duplication will be encouraged, proposals should avoid gratuitous use.

RFP March 07, 2001 18

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

5.1.9 Proposals shall specify interfaces that are compatible and can be used
with existing OMG specifications. Separate functions doing separate jobs
should be capable of being used together where it makes sense for them
to do so.

5.1.10 Proposals shall preserve maximum implementation flexibility.

Implementation descriptions should not be included, however proposals
may specify constraints on object behaviour that implementations need
to take into account over and above those defined by the interface
semantics.

5.1.11 Proposals shall allow independent implementations that are substitutable and
interoperable. An implementation should be replaceable by an alternative
implementation without requiring changes to any client.

5.1.12 Proposals shall be compatible with the architecture for system

distribution defined in ISO/IEC 10746, Reference Model of Open
Distributed Processing (ODP). Where such compatibility is not achieved,
the response to the RFP must include reasons why compatibility is not
appropriate and an outline of any plans to achieve such compatibility in
the future.

5.1.13 In order to demonstrate that the service or facility proposed in response

to this RFP, can be made secure in environments requiring security,
answers to the following questions shall be provided:

• What, if any, are the security sensitive objects that are introduced by
the proposal?

• Which accesses to security-sensitive objects must be subject to security

policy control?

• Does the proposed service or facility need to be security aware?

• What CORBAsecurity level and options are required to protect an

implementation of the proposal? In answer to this question, a
reasonably complete description of how the facilities provided by the
level and options (e.g. authentication, audit, authorization, message
protection etc.) are used to protect access to the sensitive objects
introduced by the proposal shall be provided.

• What default policies should be applied to the security sensitive

objects introduced by the proposal?

RFP March 07, 2001 19

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

• Of what security considerations must the implementers of your

proposal be aware?

5.1.14 Proposals shall specify the degree of internationalization support that

they provide. The degrees of support are as follows:

a) Uncategorized: Internationalization has not been considered.

b) Specific to <region name>: The proposal supports the customs of the

specified region only, and is not guaranteed to support the customs of
any other region. Any fault or error caused by requesting the services
outside of a context in which the customs of the specified region are
being consistently followed is the responsibility of the requester.

c) Specific to <multiple region names>: The proposal supports the

customs of the specified regions only, and is not guaranteed to
support the customs of any other regions. Any fault or error caused
by requesting the services outside of a context in which the customs of
at least one of the specified regions are being consistently followed is
the responsibility of the requester.

5.2 Evaluation criteria

Although the OMG adopts interface specifications, the technical viability
of implementations will be taken into account during the evaluation
process. The following criteria will be used:

5.2.1 Performance

Potential implementation trade-offs for performance will be considered.

5.2.2 Portability

The ease of implementation on a variety of ORB systems and software

platforms will be considered.

5.2.3 Securability

The answer to questions in section 5.1.13 shall be taken into

consideration to ascertain that an implementation of the proposal is
securable in an environment requiring security.

RFP March 07, 2001 20

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

5.2.4 Compliance: Inspectability and Testability

The adequacy of proposed specifications for the purposes of compliance

inspection and testing will be considered. Specifications should provide
sufficient constraints on interfaces and implementation characteristics to
ensure that compliance can be unambiguously assessed through both
manual inspection and automated testing.

5.2.5 Standardised Metadata

Where proposals incorporate metadata specifications, usage of OMG

standard XMI metadata representations will be considered, since this
allows specifications to be easily interchanged between XMI compliant
tools and applications. Since use of XML (including XMI, XML/Value) is
evolving rapidly, the use of industry specific XML vocabularies (which
may not be XMI compliant) is acceptable where justified.

RFP March 07, 2001 21

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

6.0 Specific Requirements on Proposals

6.1 Problem Statement

In UML 1.x, the metamodel definition does not include sufficient details
to include graphical and diagram information necessary to represent and
interchange the diagrammatic aspects UML models in an interoperable
manner. This has resulted in a number of proprietary extensions to UML
and by implication proprietary XML/XMI DTDs causing information
loss when UML models are exchanged between tools. The lack of
diagram information also makes it difficult to use UML designs across a
suite of products, which need to share the semantic, structural, and
presentation information consistently.

A simplistic view of the diagram interchange scenario is that if a

designer views a diagram on a workstation and transmits that design to
a second designer, the second designer can view the same diagram. This
is in addition to exchanging the semantics underlying the diagram,
which is possible to do so in UML 1.3 using XMI 1.1.

6.2 Scope of Proposals Sought

This RFP solicits proposals for a diagram interchange metamodel that

will address issues described in Section 6.1 and will satisfy the
requirements described in Section 6.5. Submitters should keep the
following points in mind:
• Any proposed changes to the UML metamodel should either
maintain or improve the rigor and the integrity of the current
UML specification.
• Since UML has a large installed user base all proposed changes
should consider backward incompatibility issues.

• Any proposed changes to the UML metamodel should consider

the pragmatics of usage and implementation within a reasonable
time frame.

While the terminology ‘diagram’ and ‘diagram interchange’ is used

throughout this RFP, submitters should recognize that models that are
being interchanged include diagram information as well as semantic
information that can be expressed in text (Eg: OCL textual expressions).

RFP March 07, 2001 22

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

6.3 Relationship to Existing OMG Specifications

The UML 2.0 is a major revision to the UML 1.x version series, which
includes OMG UML 1.1 and all of its subsequent minor revisions. In
general, proposals should be consistent with, and use the terminology of
the most current UML 1.x specification at the time of submission. If there
is reason to deviate from UML 1.x terminology in order to make a major
revision that reason should be clearly explained. Submitters are strongly
encouraged to consider backward-compatibility issues when
recommending major revisions; gratuitous changes to the current UML
specification are strongly discouraged.

UML 2.0 must be compliant with the most current Meta-Object Facility
Specification [3] at the time of the submission. Proposals for UML 2.0
may propose revisions to the Meta Object Facility, but they should try to
minimize the impact on existing MOF usage.

UML 2.0 must be complementary to UML-related adopted technologies

such as XMI [4]. Therefore the vocabulary and underlying models of
these adopted technologies must be used whenever possible. Restrictions
and extensions to these technologies must be called out explicitly.

6.4 Related Documents and Standards

[1] Analysis and Design PTF UML 2.0 Roadmap Recommendation

(ad/00-06-01).
[2] UML 2.0 RFI Overview (ad/00-01-07).
[3] Meta Object Facility (MOF) Specification version 1.3 --- ad/99-09-05
[4] XML Metadata Interchange (XMI) Specification version 1.1 --- ad/99-
10-02 and ad/99-10-03
[5] Scalable Vector Graphics : http://www.w3.org/Graphics/SVG

6.5 Mandatory Requirements

6.5.1 DIAGRAM INTERCHANGE METAMODEL FEATURES. The

Metamodel shall cover the representation and interchange of the
following diagramming features :
- Diagram placement (X, Y and optionally Z co-ordinates)
- Grouping of diagram elements
- Alignment of diagram elements
- Fonts
- Support for Character sets
- Color

RFP March 07, 2001 23

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

- Attachment points on relationships

- Visibility on artifacts (e.g.: hide operations in a class, classes in a
model etc.)
- Non UML artifacts on diagrams (i.e. artifacts not covered by the
current UML notation)
- Scaling information, rotation information etc.
- User defined icons and shapes
- Positioning aspects of diagram elements (e.g. position of polygon
vertices, position of diagram element names , line segments etc.).
For example, some tools allow a line segment to be represented as a
collection of ordered points to allow custom routing and
positioning of lines. The metamodel shall support this capability.

Submitters shall justify additions or removals from the diagramming

features listed above in the diagram interchange metamodel.

6.5.2 REUSES UML Metamodel. The proposal shall not gratuitously change
the UML Metamodel. The proposed metamodel shall be extensible. (Eg:
for interchanging data models).
Proposal shall support the interchange of UML models that have NO
diagram information. This maintains upward compatibility with current
designs (eg: UML Models that typically don’t have much diagram
information) and also allows interchange of designs between visual as
well as non-visual tools.

6.5.3 VOCABULARY. The metamodel shall be based on the vocabulary and

concepts of the UML Notation Guide as well as related graphics
standards (e.g: Scalable Vector Graphics…) as appropriate.

6.5.4 CHANGES TO UML METAMODEL. The proposal for the diagram

metamodel can introduce changes to the UML semantics metamodel if
those changes create a cleaner separation of the semantic and notational
aspects of UML. For example, the proposal could remove
PresentationElement and/or Geometry from the semantics metamodel.
Submitters should be aware that these changes could be impacted by the
related UML 2.0 RFPs that are proceeding in parallel: specifically UML
Infrastructure and UML Superstructure RFPs.

6.5.5 NONREDUNDANCY. Properties of model elements (in the UML

semantic metamodel) shall not be repeated in the diagram metamodel.
Rather, presentation elements shall have references to UML metamodel
elements and otherwise have only presentation properties. For example,

RFP March 07, 2001 24

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

a presentation element for a class shall not store an indication of whether

to use Italics for the class name because the use of Italics is based on
whether the corresponding class is abstract. Likewise, a presentation
element for a visibility adornment on an association end shall not store
visibility. It shall only store the presentation properties of the
adornment. The visibility comes from the corresponding association
end. It is the intention of this RFP to discourage submitters from adding
diagramming concepts to the UML semantic metamodel itself.

6.5.6 PARTITIONING . The metamodel shall ensure that a UML model

element can be presented in multiple diagrams. The metamodel shall
also allow different diagrams of a model to be in different XML
documents.

6.5.7 MOF and XMI COMPLIANCE. The diagram metamodel shall be MOF
compliant and shall be provided as an XML document that conforms to
the MOF Model DTD. Based on the MOF Specification the metamodel
shall define programmatic interfaces (in IDL) to diagram information.
Based on the XMI Specification the metamodel shall define XML
diagram interchange using a UML Diagram Interchange XML DTD.

6.5.8 DIAGRAM MANIPULATION WITHOUT CHANGING SEMANTICS

When dealing with complex designs, many tools provide the ability to
perform various activities such as ‘scale up/down’, ‘move’, ‘rotate etc.
on diagrams. It must be possible to interchange designs that have been
manipulated in this manner. The diagram manipulation should not
change the semantics of the design.
Technologies such as Scalable Vector Graphics (SVG) provide some of
this capability. The submitters are encouraged to review the XML
grammar for SVG at http://www.w3.org/Graphics/SVG and use
the concepts and terminology as appropriate in this
proposal.

6.6 Optional Requirements

6.6.1 3D Representation

The proposal may address visualization and representation of 3D

models. (For example to represent and interchange very complex
designs)

RFP March 07, 2001 25

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

6.6.2 Layering of Diagrams

The proposal may address the presentation of graphical
elements on different layers of the same diagram. This is
distinct from 3D representation, in that it would be possible to
show, or emphasize, sub-diagrams by displaying one or more
layers of the total number of layers.

In graphics parlance this is the concept of viewplane (or cells in

the context of animation). It might be allowed that a 3D
presentation could display connections between entities
between two or more layers. In general, it would be expected
that the layers represent logical collections within one diagram
(or model). Layers are primarily a way to filter the display and
simplify complexity.

6.7 Issues to be discussed

Submitters should discuss any referential integrity issues which arise
from addressing mandatory requirement 6.5.6.

6.8 Other information unique to this RFP

None

6.9 RFP Timetable

The timetable for this RFP is given below. Note that the TF may, in
certain circumstances, extend deadlines while the RFP is running, or may
elect to have more than one revised submission step. The latest timetable
can always be found in the Member Services section of the OMG Web
page (URL http://www.omg.org/)

Approx Event or Activity Actual

Day Date
Preparation of RFP by TF Feb 5,2001
Approval of RFP by Architecture Board
Review by TC (‘‘Three week rule’’)
0 TC votes to issue RFP Mar 2, 2001
60 LOI to submit to RFP due August 20, 2001

RFP March 07, 2001 26

 UML 2.0 Diagram Interchange RFP ad/2001-02-39

150 Initial submissions due October 22 , 2001

150 Voter registration closes October 22, 2001
170 Initial submission presentations November 14, 2001
Preliminary evaluation by TF
240 Revised submissions due February 25, 2002
240 Revised submission presentations March 20, 2002
Final evaluation and selection by TF
Recommendation to AB and TC
Approval by Architecture Board
Review by TC (‘‘Three week rule’’)
301 TC votes to recommend specifications May, 2002
331 BOD votes to adopt specifications July, 2002

RFP March 07, 2001 27