A Technical Perspectivexml.coverpages.org/OMG-tech-01-02-04.pdf · Model Driven Architecture A...

Model Driven Architecture

A Technical Perspective

Architecture Board MDA Drafting Team

Draft 21st February 2001

Document Number ab/2001-02-04

Table of Contents1 Preface - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 12 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 23 Basic Terminology - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 33.1 What is a Model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -33.2 Abstractions and Viewpoints - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -43.3 Platform and Implementation Language Environment - - - - - - - - - - - - - - - - - -44 Life Cycle of IT Systems and OMG Standards - - - - - - - - - - - - - - - - - - 55 IDL Models and Formal Syntax - - - - - - - - - - - - - - - - - - - - - - - - - 75.1 Platform and Language Environment Independence of IDL Specified Models- - - - - - -85.2 Extensions to IDL to Capture Additional Information - - - - - - - - - - - - - - - - - -86 CORBA, CORBA Services and GIOP - - - - - - - - - - - - - - - - - - - - - - 96.1 Standard CORBA Platform and Bridging to Other Platforms - - - - - - - - - - - - - - -96.2 The General Problem of Portability and Bridging - - - - - - - - - - - - - - - - - - - -96.3 Use of Services - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 107 UML Models and Formal Semantics - - - - - - - - - - - - - - - - - - - - - - 107.1 An Example - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 127.2 CORBA-Specific UML Models - - - - - - - - - - - - - - - - - - - - - - - - - - - 127.3 Platform-Independent UML Models - - - - - - - - - - - - - - - - - - - - - - - - - 147.4 Relationship Between Platform-Independent and Platform-Specific UML Models- - - - 147.4.1 Transforming a Platform-Independent Model to a Platform-Specific Model - - - - - - - - - -147.5 Traceability - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 177.6 Relevant Standards Activities - - - - - - - - - - - - - - - - - - - - - - - - - - - - 188 Roadmaps- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 198.1 Languages- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 198.1.1 IDL Roadmap - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -198.1.1.1 Support Round-trip - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -198.1.2 UML Roadmap - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -208.1.2.1 Action Semantics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -208.1.2.2 UML 2.0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -208.1.2.3 UML 2.0 Infrastructure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -208.1.2.4 UML 2.0 Superstructure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -208.1.2.5 UML 2.0 Object Constraint Language (OCL) - - - - - - - - - - - - - - - - - - - - - - -208.1.2.6 UML 2.0 Diagram Interchange - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -208.2 Platform- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 218.2.1 CORBA + Interoperability Roadmap- - - - - - - - - - - - - - - - - - - - - - - - - - - - -218.2.1.1 UML Models for Existing Standards - - - - - - - - - - - - - - - - - - - - - - - - - - - -218.2.1.2 The Round Trip Problem - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -218.3 Facilities - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 218.3.1 MOF/XMI Roadmap - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -218.3.1.1 XMI for XML Schema RFP - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -218.3.1.2 MOF 2.0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -218.3.2 Domain Standards Roadmap- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -228.3.2.1 UML Models for Existing Standards - - - - - - - - - - - - - - - - - - - - - - - - - - - -229 What Kind of Specifications does OMG Adopt?- - - - - - - - - - - - - - - - - 229.1 Models of Services, Facilities and Repositories - - - - - - - - - - - - - - - - - - - - 229.1.1 Platform-Independent Model (PIM) - - - - - - - - - - - - - - - - - - - - - - - - - - - - -22

ab/2001-02-01 Model Driven Architecture - A Technical Perspective i

14 February 2001 Draft

9.1.2 Platform-Specific Model (PSM) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -229.2 Languages- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 239.3 Mappings - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 239.4 Interoperability Infrastructure - - - - - - - - - - - - - - - - - - - - - - - - - - - - 239.5 New Submissions Requirements - - - - - - - - - - - - - - - - - - - - - - - - - - - 239.5.1 Relationship between PIM and PSMs - - - - - - - - - - - - - - - - - - - - - - - - - - - -249.5.2 CORBA-Specific Implementation Technologies - - - - - - - - - - - - - - - - - - - - - - -249.5.3 Other Platform-Specific Implementation Technologies - - - - - - - - - - - - - - - - - - - -2410 What Process Changes will be Necessary to Support this Expanded Agenda - - - 25

ii Model Driven Architecture - A Technical Perspective


Model Driven Architecture

A Technical Perspective

Architecture Board MDA Drafting Team


ab/2001-02-04

ese A face,

-

al at puter solete

s who

hot we

A).

-

1 Preface

OMG's mission is to help computer users solve integration problems by supplyingopen, vendor-neutral interoperability specifications. Vendors have implemented thspecifications widely over the past ten years, most notably OMG's flagship CORBspecification. When every system component supports an OMG-standardized interthe task of creating a multi-vendor solution (as most are) is greatly eased. Organizations polled in a recent analyst survey confirmed this by ranking CORBAcompliance as the most important consideration in choosing middleware for application integration1. We believe that other, more recent OMG interoperability specifications like Common Warehouse Metamodel will in the long term have equimpact. However, we must recognize that there are limits to the interoperability thcan be achieved by creating a single set of standard programming interfaces. Comsystems have lives measured in decades, and not all ancient systems written in obprogramming languages can be modified to support standards. Furthermore, the increasing need to incorporate Web-based front ends and link to business partnermay be using proprietary interface sets can force integrators back to the low-productivity activities of writing glue code to hold multiple components together. When these systems in their turn need modifying and integrating with next year'snew technology (and they all will) the result is the kind of maintenance nightmareall fear.

This paper presents a technical perspective of the Model Driven Architecture (MDMDA is an evolution of the OMA that addresses integration and interoperability spanning the life cycle of a system from modeling and design, to component

1. "A surprising 70 percent of respondents cited CORBA compliance as 'important' or 'very important' to integration, outpacing every other factor in the survey, including core func-tions such as integration of legacy applications with distributed systems and corporate intranets.” -- Summary of responses from 547 organizations asked to rate middleware selectioncriteria in the context of application integration in “Middleware: what end users are buying and why”, Gartner Group, February 1999

Model Driven Architecture - A Technical Perspective 1

21st February 2001 Draft

y o

and ibed idly rds, se

d

ent

G

en the veral g

h its the

inated we

. It n of DA

on o

ance

and ows

construction, assembly, integration, deployment, management and evolution. A kegoal of MDA is to enable the use of sound modeling and middleware standards tensure that this integration works for OMG and other popular technologies.

OMG has already specified integration with external specifications (such as XML) proprietary interface sets (such as Microsoft's DCOM). The MDA approach descrin this paper incorporates all this existing work, and promises more support for rapand effectively creating new specifications that integrate multiple interface standafrom both inside and outside the organization. It is an evolutionary step from howOMG works at the moment, but one that we believe will offer great benefits to thoworking within the OMG framework to create interoperability specifications, and therefore indirectly help all system integrators faced with this hardest of real-worlprogramming tasks.

2 Introduction

The work of the OMG has been driven since 1990 by a clear architectural statemthat has not changed much since it was first designed. The Object Management Architecture (OMA) provided the vision and roadmap for the problem that the OMhas always addressed, the problem of integration. Having created the CORBA interoperability standards, OMG has in the past used them almost exclusively whcreating standards for use in particular application domains. However, since 1997scope of the organization has broadened significantly. In 1997 the OMG issued seimportant specifications that are not CORBA based, including the Unified ModelinLanguageTM (UMLTM) and the Meta Object FacilityTM (MOFTM), and later XML Metadata InterchangeTM (XMI TM) and the Common Warehouse MetamodelTM (CWMTM).

When the OMG was issuing only CORBA-oriented standards, the manner in whicvarious standards fit together was quite well understood, and clearly mapped by OMA. The emergence of these new kinds of standards, and their potential use indefining other standards, necessitates that we expand our vision of the OMG’s architecture.

This paper is a statement by the OMG Architecture Board (AB) of how it sees therelationships among these standards and how they can be used today in a coordfashion. It discusses new standards work that would fill in some significant gaps have identified. It does not attempt to address all standardization activities of OMGdescribes how the MDA approach helps in the creation, maintenance and evolutiostandards and dealing with associated problems. It is important to realize that the Mis a proposal to expand and not replace the old OMA, to give us a roadmap and visithat will include and integrate all of the work done to date, and to point the way tfuture integration standards.

An important aspect of some of the latest OMG standards is that they greatly advthe art and science of modeling. We believe that the combined power of these standards can form the basis of a compelling approach to the architecture of distributed, component-based systems that embraces CORBA, J2EE, XML, .NETother technologies. The approach of creating standards based on models also allthe same model to be realized on multiple platforms through additional auxiliary

2 Model Driven Architecture - A Technical Perspective


ning of

each to this

ct

any a sing

ion s

the

ristic be ons is a

could

uch

f

nice

mapping standards, or through point mappings to specific platforms, thus broadethe usability of the standards considerably. This reduces the risk of obsolescenceadopted domain standards as platforms come and platforms go.

However, there are a number of challenges that we will have to face in order to rthis potential. This paper delineates these challenges now so that we can move innew territory with proper grounding in firm principles.

Finally, it is important to note that many of the ideas expressed in this model reflethe cumulative wisdom of many people who are not members of the ArchitectureBoard.

3 Basic Terminology

3.1 What is a Model

Some people define a model as a visual representation of a system. However, mpeople refer to a set of IDL interfaces as a “CORBA object model.” Furthermore,specification expressed in terms of UML can be rendered into an XML document uthe OMG’s XMI DTD for UML, which certainly is not a visual artifact. Thus, we conclude that this definition is too limiting.

We offer the following definition: A model is a formal specification of the function,structure and/or behavior of a system.

A specification is said to be formal when it is based on some well defined languagethat has well defined meaning associated with each of its constructs. A specificatthat is not formal in this sense, is not a model. Thus a diagram with boxes and lineand arrows that does not have behind it a definition of the meaning of a box andmeaning of a line and of an arrow is not a model—it is just an informal diagram.

Note that under this definition, source code is a model that has the salient charactethat it can be executed by a machine. A set of IDL interfaces is a model that canused with any CORBA implementation and that specifies the signature of operatiand attributes of which the interfaces are composed. A UML-based specification model whose properties can be expressed visually or via an XML document.

We could have taken the stance that a model is not necessarily formal, so that wetalk about formal and informal models, which in a way seems to be quite natural discourse. However we then would end up with a very weak definition of model sas “a representation of a system.” We feel that the definition that encompasses formality is more useful.

For a nice discussion about modeling the enterprise in particular see Section 3 o“Model-Driven Architecture - Opportunities and Callenges” by Desmond DSouza, OMG document number ab/2001-02-03. In general this document presents a veryperspective on MDA.

ab/2001-02-04 Model Driven Architecture - A Technical Perspective 3


must

the

are to

e

ing t. a tion

d ust

, or a

AP

A,

red

t

3.2 Abstractions and Viewpoints

ISO’s Open Distributed Processing (ODP) Part II defines abstraction as the suppression of irrelevant detail2. We view this as an appropriate definition. Thus, allmodels are abstractions and term like “abstract model” can be very confusing. We be careful about the terminology we use to categorize different kinds of models.

It is useful to identify models in terms of the abstraction criteria that were used todetermine what is included in the model. A model that is based on a specific abstraction criterion is often referred to as a model from that viewpoint, or in short as a view of the system.

Another common use of the word abstraction is in the phrase higher level of abstraction, which is used to characterize a model in which more of the details of system is elided as compared to a lower level of abstraction.

Furthermore in common usage, the notion of viewpoints and levels of abstractionused together such that a larger amount of detail from a viewpoint may be elidedobtain a model from that viewpoint or a view, at a higher level of abstraction, while little or no detail may be elided to obtain a model or view, at a low level of abstraction.

ISO’s ODP defines five standard viewpoints that are convenient to use to describsystems. Many projects have used other sets of viewpoints to specify systems.

3.3 Platform and Implementation Language Environment

The term platform is used to refer to different things in different contexts. In this document, we propose to use the term to encompass technological and engineerdetails that are irrelevant to the fundamental functionality of a software componenConsider, for example, a formal definition of an operation that transfers funds fromchecking account to a savings account. The fundamental functionality of this operaare that a specified amount is subtracted from a designated checking account anadded to a designated savings account, with a constraint that the two accounts mbelong to the same customer. This functionality remains invariant regardless of whether the operation is performed by a CORBA object, an Enterprise Java BeanSOAP operation.

Thus, a platform-independent model is a formal specification of the structure and function of a system that abstracts away technical details. By this definition a SOspecification of the funds transfer operation would be platform-specific, where the platform is SOAP. A specification that depends on interfaces to artifacts of CORBlike the ORB, Object Services or GIOP/IIOP would be an example of a platform-specific model.

CORBA itself is implemented on an infrastructure, which in proper context is referto as a implementation language platform. However, to avoid confusion, for the purposes of this document, we will use the term implementation language environmen to refer to such infrastructures. Thus, analogous to the dichotomy established for

2. ISO Standard 10746-2



a

ge of ation. and

e nd .

re

as eds ite d for ed

t e t

da

the ple nd

e

to , n the

en


platforms, CORBA specifications are implementation language environment independent, whereas artifacts like stubs, skeletons and the ORB implemented in specific language are implementation language environment specific.

4 Life Cycle of IT Systems and OMG Standards

IT systems have historically been developed, managed and integrated using a ranmethodologies, tools and middleware and there appears to be no end to this innovWhat we have seen in the last few years, especially as a result of efforts at OMGW3C is a gradual move to more complete semantic models as well as data representation interchange standards. OMG contributions include CORBA, UML, XMI, MOF and CWM. W3C contributions include XML, XML Schema, and the ongoing work of XML-PC working group. These technologies can be used to morcompletely integrate the value chain (or life cycle) when it comes to developing adeploying component based applications for various target software architectures

The life cycle of an application can vary dramatically depending on whether we abuilding a new application from scratch or just surgically adding a wrapper to an existing application. The cost of enhancement and maintenance of an applicationwell as the cost of integrating new applications with existing applications far excethe cost of initial development. In addition the application life cycle itself can be qucomplex, involving several vendors in each of the life cycle phases. Hence the neeinformation interchange and interoperability between tools and middleware providby different vendors (a very common situation in enterprises today) is critical.

The MDA supports many of the commonly used steps in model driven componenbased development and deployment. A key aspect of MDA is that it addresses thcomplete life cycle analysis and design, programming aspects (testing, componenbuild or component assembly) as well as deployment and management aspects.

Figure 1 which is excerpted from the companion document (http://doc.omg.org/m) shows a high level representation of how the various pieces fit together in MDA.

One of the things it attempts to do is to provide an overall framework within which role of various OMG and other standards can be uniquely identified. As an examthe various OMG standards affect the interchange of information between tools aapplications that are seen in this figure are described below:

Unified Modeling Language (UML): UML addresses the modeling of architecture, objects, interactions between objects, data modeling aspects of the application lifcycle, as well as the design aspects of component based development including construction and assembly. Note that UML is powerful enough that we can use itrepresent artifacts of legacy systems. Artifacts captured in UML models (ClassesInterfaces, UseCases, Activity Graphs etc.) can be easily exported to other tools ilife cycle chain using XMI

XML Metadata Interchange (XMI): XMI is a standard interchange mechanism used between various tools, repositories and middleware. XMI can also be used to automatically produce XML DTDs (and soon XML Schemas) from UML and MOFmodels, providing an XML serialization mechanism for these artifacts. XMI has beused to render UML artifacts (using the UML XMI DTD), data warehouse and database artifacts (using the CWM XMI DTD), CORBA interface definitions (usingthe IDL DTD), and Java interfaces and Classes (using a Java DTD).


eling

hich

are

.

mple

s cal

Meta Object Facility (MOF): MOF provides the standard modeling and interchangeconstructs that are used in MDA. These constructs are a subset of the UML modconstructs. Other standard OMG models, including UML and CWM, as defined interms of MOF constructs. This common foundation provides the basis for model/metadata interchange and interoperability, and is the mechanism through wmodels are analyzed in XMI. MOF also defines programmatic interfaces for manipulating models and their instances spanning the application lifecycle.Thesedefined in IDL and are being extended to Java.

Common Warehouse Metamodel (CWM): CWM is the OMG data warehouse standardIt covers the full life cycle of designing, building and managing data warehouse applications and supports management of the life cycle. It is probably the best exato date of applying the MDA paradigm to an application area.

UML profiles for CORBA, EJB, EDOC etc. A number of UML profiles are at varioustages of standardization (UML profile for CORBA is adopted) and these are critilinks that bridge the UML community (model based design and analysis) to the

Figure 1 MDA Overview



A, on

to sing le, L) in ed the

ther can be s

ent, el” that m.

e

ess f the ts

xtent f

t has

is

to g

developer community (Java, VB, C++ developers), middleware community (CORBEJB, SOAP developers) etc. Additional profiles focused on systems and applicatimanagement are needed

Historically, the integration between the development tools and the deployment inthe middleware framework, has been weak. This is now beginning to change by ukey elements of the MDA – specific models and XML DTDs that span the life cycand profiles that provide mappings between the models used in various life cyclephases. XMI, which marries the world of modeling (UML), metadata (MOF and XMand middleware (UML profiles for Java, EJB, IDL, EDOC etc.) plays a pivotal rolethe OMG’s use of XML at the core of the MDA. It also provides developers focuson implementation in Java, VB, HTML etc., a natural way of taking advantage of software platform and engineering discipline, when a more formal development process is desired. In essence XMI adds Modeling and Architecture to the world of XML.

5 IDL Models and Formal Syntax

A set of IDL modules containing specifications of IDL interfaces, valuetypes and oassociated datatypes is a declarative syntactic model of a system. Such a model used to reason about the validity or lack thereof of relationships among the entitiespecified using the rules of relationship among IDL declared entities like containminheritance etc. A IDL specification is often referred to as the “CORBA object modrecognizing the fact that such a model can be implemented on a CORBA platformwill implicitly verify the syntactic validity of any attempt to use any part of the syste

However, such a specification does not contain much formal information about thmeaning of the operations of the interfaces or of the elements of the datatypes declared, nor about the constraints that apply to them. In traditional CORBA specifications such information has been included in normative but an informal description in English.

In this approach, an IDL compiler can be used to statically verify syntactic correctnof the model. An ORB can verify syntactic correctness of attempts to use parts osystem dynamically. However, there is no automatic way of verifying the constrainand functionality that appears in the specifications in informal descriptions

IDL was not designed to express a rich set of relationships among entities. The description of relationships between different parts of a system is also to a large einformal, and hence prone to multiple interpretations. Traditionally, descriptions orelationships among CORBA Services, and indeed among different artifacts that constitute a CORBA service, appeared in the form of informal text. In more recenspecifications (e.g. POA), the use of UML to more completely describe the modelbrought additional rigor to the specifications.

5.1 Platform and Language Environment Independence of IDL Specified Models

IDL itself per-se is not tied to any specific language environment or platform. Thiswhat made it possible to have ISO adopt IDL as a standard without any specific reference to CORBA. Indeed there are many systems in this world which use IDLspecify the syntactic model of the system but do not use CORBA as the underlyin



er, it dent, ns,

ge

n

ts tic has

ven tion ate ans

a . A

erms

tions,

t tion The t t to

l in UML

te

platform. While OMG has not standardized any such usage of IDL with alternativeplatforms, there are broadly deployed instances in the industry of such use. Howevshould be noted that in spite of being platform and language environment indepenIDL specified models are restricted to expressing only the syntax of the interactioi.e. operation signatures.

OMG has chosen to use IDL together with the CORBA platform (ORB and languamappings) as a reasonable package of facilities to standardize. This facilitates algorithmic construction of skeletons of portable components of the system for a specific language environment, from language independent specifications, using aIDL compiler. The big win from this is portability of specifications from one language environment to another, as well as portability of implementations among different instances of the same language environment.

Additionally, given specifications of the exact syntax of interaction between objecthat constitute the system, it is also possible to automatically generate the syntacform that is carried on a wire that connects the two communicating objects. OMGstandardized on GIOP/IIOP as the standard means of conveying communication between IDL declared objects deployed on a CORBA platform. Again, IDL, and ethe CORBA platform per-se, does not preclude use of other means of communicabetween objects. Indeed, it is quite possible for two CORBA objects to communicwith each other using DCOM or SOAP on the wire. But the adoption of a single meof interoperation ensures interoperability of implementations.

5.2 Extensions to IDL to Capture Additional Information

Various attempts have been made to extend IDL to capture richer structural and behavioral information and to automatically generate implementation artifacts for given platform that enforces the constraints as specified in the richer specificationrecent example of this is the Components extension of IDL together with the XMLbased deployment descriptors, which facilitates specification of entire systems in tof its constituent components, their interactions and deployment characteristics. However, it should be noted, that all such extensions so far have been point soluwithout paying much attention to a general model for specifying such extensions.

A model defined in the UML profile for CORBA (see 7.2 CORBA-Specific UML section) provides an alternative representation of an IDL model. They are differenrepresentations of the same model. In fact, there is precisely one IDL representathat can be derived from a model represented using the UML profile for CORBA. UML model may, however, provide additional information (such as cardinality) thacannot be represented in an IDL model today. Appropriate extensions to IDL, thaallow representation of these additional relevant concepts, would make it possiblemap a model expressed in the CORBA profile of UML to an equivalent IDL modea reversible fashion. That is, one would be able to reconstruct the corresponding from the equivalent IDL, without loss of information. This ability to “round-trip” thetransformation in this way would allow designers and architects to work in the technology that they are comfortable with (UML or IDL) and algorithmically generathe alternative representation for the specification.



s

der bility

ith ins.

BA

ain as RBA

er if n. It n to aking

ame

tion, d IDL el is

tions

ning

hus

d of ed m

6 CORBA, CORBA Services and GIOP

The OMG standard platform consists of the specifications commonly referred to aCORBA, CORBA services, and GIOP/IIOP.

6.1 Standard CORBA Platform and Bridging to Other Platforms

The general philosophy has been to adopt a single set of standards within a broaframework that allows alternatives if there is such a need. The standard interoperaframework recognizes such possibilities and explicitly defines domains and how bridges can be specified to enable objects in different domains to communicate weach other, thus making it possible to construct systems that span multiple doma

This framework has been successfully used to specify bridges between the CORplatform with GIOP/IIOP based communication and the COM/DCOM platform andcommunication domain in an existing OMG standard. More recently an inter-dombridge between the CORBA Component Model and the EJB Component Model halso been adopted as a standard. This shows the tremendous versatility of the COand associated interoperability framework.

The problem of bridging from one platform to another becomes considerably simplthe two platforms in question share a common model at a higher level of abstractiois fortunate that most broadly deployed distributed computing environments happeshare such a common model, although never formally expressed as such, thus mconstruction of bridges among them feasible.

6.2 The General Problem of Portability and Bridging

As the basic CORBA platform and associated CORBA services specifications becrich enough to support the building of domain specific facilities the need for expressing the underlying model in a formal way, at an appropriate level of abstrachas been felt more acutely. This is somewhat analogous to the need that motivatebased specifications, but at a higher level of abstraction. A formally specified moduseful because:

• It facilitates creation of compatible platform specific models/specifications corresponding to the same platform-independent model and hence implementathat are easier to bridge together.

• It provides a common reference model and vocabulary with unambiguous meathus reducing the chances of miscommunication among system designers andbuilders.

• It facilitates standardization of more precisely specified designs and patterns, tallowing for portability of design, and makes it easier to support interoperability among different realizations of the same design on different platforms.

Thus, given the experience gained working on CORBA systems specifications anbridges to other similar platforms, it is a natural step for OMG to adopt standardizmeans of expressing richer formal models at appropriate levels of abstraction, fromultiple viewpoints.



set are nder Trader ing

ple, be e in the e for

g ns

BA cast ed to

iles,

aces, of

ined s that

uages avior.

,

6.3 Use of Services

Although the CORBA Services and Facilities adopted and available include a richof diverse functionality, most application designs using CORBA assume that theyavailable, but hide their use behind the domain interfaces. For example, factory/fioperations can be seen in designs expressed as IDL interfaces, but usage of the or Naming Service is hidden in the implementation.This is good abstraction allowfor choice of implementations.

However, other services need to be exposed more explicitly in designs. For examtransactional properties of an operation which makes calls on many objects may expressed informally in English description of the operation, but the need for thesobjects to support transactions, and for the right transaction boundaries to be set implementation are left to the software engineer. Analogous observations hold truSecurity services.

The place where the use of services (and optional use of CORBA Core Messaginfunctionality) is least supported by traditional IDL interface specification, is in desigfor event-driven applications. this is equally true for designs involving publish/subscribe, and those involving explicit multicast to a set of recipients. CORMessaging and Notification Service provide a set of reliable, asynchronous, multiand subscription capabilities, but IDL is incapable of expressing how these are usrealize the kind of loosely-coupled extensible, event-driven applications that are increasingly popular across industry domains.

These problems are addressed in models, either expressed in UML or using Profsuch as EDOC and EAI. But the way in which these models are being mapped totechnologies reveals the need for a UML Profile for CORBA Service usage, and analogously for JMS and EJB usage, MTS and .NET usage, etc., which provide astandard way of expressing technology specific models.

7 UML Models and Formal Semantics

UML models are declarative models, as are IDL-based object models, Java interfand Microsoft IDL interfaces. However, UML models differ from these other kindsdeclarative models in some important ways.

One difference is that UML models can be expressed visually, although, as explaabove, they can also be represented non-visually. The more important difference iUML models can be semantically much richer than models expressed in other declarative model languages mentioned above. The other declarative model langmentioned express syntax (i.e. signature) but very little about their usage and behAnother key difference is that UML has been formally defined using core UML modeling concepts and this enhances the power of MDA.

The following is a partial list of constraints on usage and behavior that can be expressed in a UML model that the other declarative languages mentioned abovecannot express:

• Invariant rules

• Pre and post conditions for operations



e. e

the

ML

ot

of L

cts:

xtent n the

e

this

• Whether a single-valued attribute or parameter is allowed to be null

• Whether an operation has side effects

• Whether a set of subtypes of a common supertype is disjoint or overlapping, i.whether it is permissible to define a type that inherits from more than one of thsubtypes.

• Whether a type is abstract, i.e. whether it is permissible to create instances oftype that are not instances of some subtype.

Invariant rules and pre/post conditions are particularly important features of an approach to rigorous software engineering called contract based design. UML did not invent the concept of contract based design, but it has very good support for it. Udefines a formal assertion language called Object Constraint Language (OCL) that facilitates specification of certain constraints. While contract based design does neliminate the need for informal textual explanations of interface usage, it can significantly reduce dependence on them.

The use of UML opens up the possibility that OMG standards will formalize manythe constraints that are currently specified mostly in English. In fact some currentOMG specifications including UML, MOF and CWM specifications already use UMand OCL for specifying constraints.

Specifying constraints formally rather than in free form text reduces ambiguity in specifications and thus makes life easier for implementers in two important respe

1. It provides the programmer with more precise instructions, thus lessening the eto which the programmer has to guess at the designer’s intention or track dowdesigner to find out what to do.

2. It decreases the amount of work required to get different implementations of thsame specification working together.

A model that specifies interfaces to this much precision is profoundly different in character from one that does not. We would like to see OMG specifications rise tolevel of rigor.



this ain

7.1 An Example

Figure 2 and Figure 3 show fragments of a platform independent UML model containing invariant rules and pre and post conditions (in the shaded boxes).

Figure 2 Invariant Rules

Figure 3 Pre and Post Conditions

7.2 CORBA-Specific UML Models

However, since UML is CORBA-independent and, in fact, is independent of all middleware technologies, it is not obvious to the casual observer how to harnesspower. In order to transform this model into a CORBA specific platform model certdecisions need to be made. For example do the UML classes represent CORBA

--English--number must be between 1000--and 9999

--OCLinv:

number >= 1000 andnumber <= 9999

Account

number : integerbalance : float

Customer

SocialSecurityNumber : Stringname : StringAddress : String

Checking Account

Sum in Balance : Float

1..n

+account

1+customer

FundsXfer

XFerFromChecking(in fromAcct : CheckingAccount, in toAcct : SavingsAccount, in amount : Float, out fromAcctBal : Float, out toAcctBal : Float)

- OCL (XFerFromChecking)pre:

fromAcct.balance >= amountfromAccount.customer = toAccount.customer

post:fromAcct.balance = fromAcct.balance@pre - amounttoAcct.balance = toAcct.balance@pre + amountfromAcctBal = fromAcct.balancetoAcctBal = toAcct.balance



t a e

of

r

it

ed to ets.

e

interfaces, valuetypes, structs, and unions? If so how does one make it clear thaparticular UML class is an interface as opposed to a valuetype? If not, what do thclasses represent and how would they be useful?

A UML profile is a set of extensions to UML using the built-in extension facilities UML. The primary UML extension facilities are stereotypes and tagged values. Stereotypes label a model element to denote that the element has some particulasemantics.

The UML Profile for CORBA, adopted in 2000, specifies how to use UML in a standard way to define CORBA IDL interfaces, structs, unions, etc. For example,defines stereotypes named CORBAInterface, CORBAValue, CORBAStruct, CORBAUnion, etc. that are applied to classes to indicate what the class is supposrepresent. In the graphical UML notation, a stereotype is delimited by angle brack

Figure 4 A Stereotype Indicating that the Class Represents a CORBA Interface

Figure 5 is a fragment of the specification of a CORBA interface that uses the semantic power of UML to formalize an invariant rule. The invariant rule cannot bformally specified in IDL, and thus we consider this model to be a semantically enhanced CORBA specification.

Figure 5 A fragment of a Semantically Enhanced CORBA Specification

This model fragment corresponds to the following IDL:

<<CORBAInterface>>AccountManager

create_account(in number : unsigned long) ;find_account(in number : unsigned long) ;


--OCLinv:


<<CORBAInterface>>Account

number : shortbalance : float



e

BA need cise vior

re is l

tting

the pect. hile

n

a

interface Account{ attribute short number; attribute float balance;};

Figure 6 IDL--By Nature Semantically Thin

Thus, with the UML Profile for CORBA, CORBA-based specifications can be madmuch complete than is possible with IDL only. The normative English text that specifies rules such as the allowable range of the Account number today, will be replaced by formal invariant rules expressed in terms of the UML Profile for CORin the near future. The ORBs of today need only understand the IDL; they do not to understand the formal specification of behavior and constraints in the more prespecification any more than they need to understand informal specification of behaand constraints in English text.

The technology is in place to proceed in this direction. The main barrier is that thea gap in knowledge of how to use the technology, and there is a lack of universaavailability of appropriate tools.

7.3 Platform-Independent UML Models

UML can be used to specify structures, behaviors and constraints without commito a specific platform. The models shown by Figure 2 and Figure 3 are platform-independent.

Such platform-independent models are useful for two basic reasons. Firstly, by distilling the fundamental structure and meaning, they make it is easier to validatecorrectness of the model. Platform-specific semantics cloud the picture in this resSecondly, they make it easier to produce implementations on different platforms wholding the essential structure and meaning of the system invariant, by making aunambiguous description of the structure, behavior and constraints available.

7.4 Relationship Between Platform-Independent and Platform-Specific UML Models

7.4.1 Transforming a Platform-Independent Model to a Platform-Specific Model

In real-life projects platform-independent models are useful but insufficient. The people in the trenches also have to design platform-specific implementations.

There are three basic ways to construct a platform-specific UML model from a platform-independent UML model:

1. A human could study the platform-independent model and manually constructsplatform-specific model.

2. An algorithm could be applied to the platform-independent model resulting in askeletal platform-specific model that is manually enhanced by a human.



on of

ly ces,

. The n the

ertain

e.

orms

to a is count

to ces.

3. An algorithm could be applied to the platform-independent model resulting in acomplete platform-specific model.

UML models are declarative. Hence the above list does not address the productiexecutable code from a platform-independent model that entails similar choices.

There also are variations in which the platform-specific model is not a semanticalrich UML model but, rather, is expressed via a language such as IDL, Java interfaXML, etc.

Fully automated transformations are feasible in certain constrained environmentsdegree to which transformations can be automated is considerably enhanced whefollowing conditions are obtained:

• There is no legacy to take into account

• The model that serves as input to the transformation is semantically rich

• The transformation algorithms are of high quality

It is much easier to generate executable code for structural features (attributes, cassociations and similar properties) of a model rather than behavioral features (operations) because the behavior of property getters and setters are quite simpl

Automation of transformations is more tractable when the transformation is parameterized, i.e. a human has a pre-defined set of options to select from, to determine how the transformation is performed. For example, a system that transfa UML model to an XML DTD could allow some control over how a UML class’s attributes are transformed, giving a human a chance to choose to put them in anATTLIST or to put each attribute in a separate ELEMENT.

Some of these points are illustrated by a CORBA-specific model, corresponding fragment of the platform-independent model shown earlier. Note (Figure 7) that thfragment of the model has been enhanced by using a stereotype to denote that Acis an entity as opposed to a process3. The model fragment has also been enhanced indicate that the Account number constitutes a unique identifier for Account instanThese enhancements are platform-independent.

Figure 7 Platform-Independent Model, Enhanced with Stereotypes

3.In the field of distributed business component-based software it is now widely understood that the entity-process distinction is crucial to building scalable systems.


--OCLinv:


<<BusinessEntity>>Account

<<UniqueId>> number : Integerbalance : Float



are e

the

ntity.

ctory

urse

d e a

es it t

ence,

Figure 8 shows a CORBA-specific UML model constructed from this fragment. Wenot taking a stand that this is the proper way to construct a CORBA solution from thplatform-independent UML fragment. It is simply an example of how one might do so either manually or algorithmically. Note that Session:BaseBusinessObject is an element defined in the OMG Task and Session Service. The logic of the construction usesenhancements to the platform-independent model that indicate that Account is a business entity and that the Account number constitutes an Account’s unique ideIt reflects a commonly used pattern of specifying one interface exposed by entity instances and the other exposed by a manager of the entity instances, including fafinder operations that use the unique identifier as a selector. The entity instance interface has an attribute that provides a reference to the instance manager.

Figure 8 A CORBA-Specific UML Model Derived from the Platform-Independent UML Model

Figure 9 contains the IDL that expresses the same CORBA-specific solution. Of cothe IDL is semantically thin. Its formal constructs do not and cannot express the invariant rule about the account number range. Furthermore, the IDL does not ancannot formally indicate whether a well-formed Account instance is allowed to havnull manager reference. On the other hand, the CORBA-specific UML model makclear, via the multiplicity of 1 on the manager end of the association between Accounand AccountInstanceManager, that a well-formed account must have a non-null manager reference. If the solution designer intended to allow a null manager referthen the multiplicity would be 0..1 in the CORBA-specific UML model, but the IDLwould be the same as in Figure 9.


--OCLinv:


<<CORBAInterface>>Account


<<CORBAInterface>>Session::BaseBusinessObject

<<CORBAInterface>>AccountInstanceManager

create_account(in number : unsigned long : Accountfind_account(in number : unsigned long) :) Account

<<CORBAInterface>>CosLifeCycle::GenericFactory

1 *

+manager



cific

tutes cy. ents.

at s do

interface AccountInstanceManager : CosLifeCycle::GenericFactory{

Account create_account (in unsigned short number);Account find_account (in unsigned short number);

};

interface Account : Session::BaseBusinessObject{

attribute AccountInstanceManager manager;attribute short number;attribute float balance;

};

Figure 9 IDL Corresponding to the CORBA-Specific UML Model

7.5 Traceability

The relationships between elements of the platform-independent and CORBA-speUML models can be specified in UML. Figure 9 illustrates that the AccountInstanceManager CORBA interface is a refinement, at a different level ofabstraction, of the number attribute in the platform-independent model that constiAccount’s unique identifier. <<refine>> is a standard UML stereotype of dependenNote that UML namespaces are used to distinguish between the two Account elemThe platform-independent Account class is contained in a namespace called Analysis. The desired namespace separation can be achieved by putting the two models inseparate UML Packages.

It is generally recognized by UML experts that UML’s facilities for relating modelsdifferent levels of abstraction are rudimentary and need expansion. UML’s featurenot adequately support powerful zoom-in and zoom-out capabilities. The UML 2.0RFPs call for facilities that address this gap.

Figure 10 Tracing Between Elements of the Models

<<CORBAInterface>>CORBASpecific::Account


<<CORBAInterface>>AccountInstanceManager

create_account(in number : unsigned long : Accountfind_account(in number : unsigned long) :) Account

1 *

+manager

<<BusinessEntity>>PlatformIndependent::Account

<<UniqueId>> number : Integerbalance :: Float

<<refine>>



ler f the

ation plete

way a

for

-

file s. rts

in

y.

ML

BA

The rstly,

-m-

The above set of examples highlights the value of the MDA – The architect/modefocuses on creating the platform independent architectural and business model oapplication. The middleware/e-services designer uses UML profile for CORBA to model the platform specific aspects of the system so that CORBA interface genercan be automated. The programmer then uses the UML model as well as the IDLinterfaces to augment whatever generated code exists with additional code to comthe value added business logic for the service. All these artifacts are traced and versioned. This allows MDA to be used by systems administrators, architects, designers as well as developers

7.6 Relevant Standards Activities

The OMG’s UML Profile for EDOC RFP process currently underway will define standard stereotypes for platform-independent models that will provide standard to use UML to express the structure, behavior and constraints of components in platform-independent fashion. It will contain proof of concept mappings to the CORBA Component Model and to EJB. A follow-on RFP is expected that will call standardization of these mappings4.

The EDOC profile will not necessarily be entirely applicable to all domains. For example, real time applications are likely to require a different profile for platformindependent modeling with their own mappings to platforms.

The Sun Microsystems Java Community Process is currently defining a UML Profor EJB (JSR #26) to support the declarative specification of EJB-specific solutionThis profile can be considered a peer of the UML Profile for CORBA in that suppoplatform-specific modeling. Several members of the OMG Architecture Board aremembers of the expert group defining the profile as are other UML experts activethe OMG.

The MOF-IDL mapping defines an algorithm for transforming any arbitrary MOF-compliant metamodel to a set of IDL interfaces. The generated IDL defines the interfaces for CORBA objects that can represent models in a distributed repositor

The IDL generated from the CWM defines the interfaces for CORBA objects representing specific data models in a repository. The IDL generated from the Udefines the interfaces for CORBA objects representing specific UML models in a repository.

Similarly, the IDL generated from the IR metamodel defines the interfaces for CORobjects representing specific CORBA object models in a repository.

MOF experts generally agree that the MOF-IDL mapping is in need of upgrading. problem is that the generated interfaces are not efficient in distributed systems. Fithe mapping predates CORBA valuetypes and thus does not make use of them.

4. The EDOC profile also addresses business process component modeling and is likely to beintegrated sooner or later with another standard in progress, the UML Profile for Event Driven Architectures in EAI. When these standards are finalized we may end up with morethan one level of platform-independent model so that a platform-independent business process model could be mapped either to an event-based EAI model or to a more standard coponent model, where the EAI and component models are still platform-independent.



N p

re, -ll be ay.

tible t

lients.

taken G,

d

L

e res ring pecify ize.

Secondly, a class with N attributes is always mapped to a CORBA interface with separate getter/setter operations. In a distributed system one would want to grouattributes based upon use cases, cache attribute values, or implement other optimizations to reduce the number of distributed calls.

Realistically we will probably have to accept the fact that for the foreseeable fututhe automatically generated transformation from platform-independent to platformspecific will have to be enhanced by humans. As we gain more experience we wiable to define various standard patterns and allow them to be selected in some w

There are additional issues regarding evolution of interfaces in a backward compainteroperable fashion. An interface that is evolved in a UML or MOF model withouconsideration for backwards compatibility will most likely not result in a newer version of the interface that is backward compatible with the older version when deployed in a given platform. There may need to be additional enhancements to modeling standards that allow specification of platform specific restrictions to the ways in which interfaces can be evolved, so they continue to be usable by older c

8 Roadmaps

This section enumerates specific actions that are being taken and that need to bein order to make MDA happen. It is not a complete roadmap of all activities of OMso things like roadmaps of individual task forces and such are not included here.

The section is organized into three major subsections – Languages, Platforms anFacilities which basically covers the three major types of things that OMG standardizes.

8.1 Languages

8.1.1 IDL Roadmap

8.1.1.1 Support Round-trip

Develop enhancements to support “round-trip” between IDL specifications and UMfor CORBA profile based specifications.

An obvious concern if IDL is expanded to include these features is the effect on CORBA vendors who provide IDL compilers. One possible approach might be to standardize “annotations” of IDL that would be ignored by the IDL compiler. Thesstandard annotations could be interpreted by UML modeling tools that import andexport IDL, but ignored by an IDL compiler. This is similar to the annotation featuthat JavaDoc added to the Java language. The JavaDoc annotations are used togenerate HTML documentation but are not interpreted by the Java compiler. Ensuthat the annotations are correct and that the software does what the annotations sis the job of an implementation - an area that MDA does not propose to standard



L tive) is

cond

and the

tant g in vels hical

and

ued of

8.1.2 UML Roadmap

8.1.2.1 Action Semantics

There is an RFP in process called “Action Semantics for UML” which will move UMbeyond the realm of first order (declarative) semantics into second-order (imperasemantics5. This will make it more feasible to produce executable UML models thanthe case today.

Once a UML action semantics standard is in place, it will be possible to make seorder UML models normative.

8.1.2.2 UML 2.0

There are four UML 2.0 RFPs. All of the RFPs emphasize that it is necessary to enforce a clear separation of concerns between the underlying meaning of UML the notation. Architecturally it is preferable that the formal semantics be the maindriver, with notations flowing from the semantics. Of course gratuitous changes tonotation are discouraged.

8.1.2.3 UML 2.0 Infrastructure

This RFP calls for addressing the lack of full alignment of UML and MOF and formaking the UML extension mechanisms more powerful

8.1.2.4 UML 2.0 Superstructure

This RFP calls for enhancement of the semantics of UML. One of the most imporrequirements of this RFP addresses the lack of powerful mechanisms for zoominand out mentioned earlier in this paper. The underlying semantics of traversing leof abstraction must be defined independently of notation and an appropriate grapnotation must be defined that conforms to the semantics.

8.1.2.5 UML 2.0 Object Constraint Language (OCL)

This RFP calls for enhancements to the expressive power of OCL and for standardizing the representation (i.e. parse tree) of OCL expressions in the MOFusing XMI.

8.1.2.6 UML 2.0 Diagram Interchange

A fourth RFP focusing on interchanging diagram information is expected to be issin an upcoming OMG meeting. The current OMG specifications allow interchangesemantics and structural information in models but not presentation information.

5. See ad/98-08-03, an excellent paper written by Steve Mellor about the motivation for actionsemantics.



are

nal hese

t

an .

on

the as

lude , be

8.2 Platform

8.2.1 CORBA + Interoperability Roadmap

8.2.1.1 UML Models for Existing Standards

UML models will be constructed and included in the existing standards, where theycurrently missing, in due course through the normal revision process.

UML models of infrastructure services need to be placed in a framework (of additiomodels and patterns) that allow the expression of technology specific solutions. Twould form the basis of mapping from platform neutral designs. For example, a standard way of expressing the relationship between a Notification Channel, its suppliers and consumers, and their subscriptions is needed in order to map to a CORBA Notification or a Java Notification solution from an EDOC Business Evendesign.

8.2.1.2 The Round Trip Problem

Enhancements necessary in the platform, in addition to extending IDL, to supportacceptable solution for the round trip problem will be developed and standardized

8.3 Facilities

8.3.1 MOF/XMI Roadmap

Usage of MOF and XMI have resulted in increased interest in extending these specifications to address new features – some focused on better integration with emerging XML standards like XML Schema, SOAP and UDDI and other focused configuration management, version control and federation.

8.3.1.1 XMI for XML Schema RFP

This RFP allows mapping of MOF based models to XML Schemas. Another key feature of this RFP is reverse engineering of XML DTDs and XML Schemas into MOF. This allows the OMG MDA to accommodate legacy XML DTDs and Schemto take advantage of the rigor and formal modeling supported by the MDA.

8.3.1.2 MOF 2.0

Some of the features anticipated for MOF 2.0 (RFP to be issued in the future) incversion control and configuration management, integration with directory servicesUDDI and repository federation. Additionally, customizable generation of IDL may part of this RFP too.



are

sers, is

”.

crete of be

e.

ay

an lves

L

ned.

L

8.3.2 Domain Standards Roadmap

8.3.2.1 UML Models for Existing Standards

UML models will be constructed and included in the existing standards, where theycurrently missing, in due course through the normal revision process.

9 What Kind of Specifications does OMG Adopt?

The OMG adopts infrastructure and language specifications aimed at tools/systemvendors, by the PTC, and specifications aimed at applications vendors and end-uby the DTC. The line between the two is obviously fuzzy, changes over time, anddependent upon where one sits in the “food chain”—one person’s infrastructure isanother person’s application. To an operating system vendor the OTS is an “application”, but to a gene researcher it is a fundamental piece of “infrastructure

The crux of an OMG specification is the artifacts that it defines. These are the conentities that are IT-realizable and to which conformance can be tested. A variety techniques are used. The following outlines the various kinds of artifacts that canfound in OMG specifications:

9.1 Models of Services, Facilities and Repositories

Examples: PIDS, Interface Repository, MOF, OTS

9.1.1 Platform-Independent Model (PIM)

PIMs may be defined using UML (preferable) or other notations where appropriatBehavior and constraints are defined using a formal notation (UML models) or aninformal notation (natural language) as appropriate

In the future, the UML Profile for EDOC (in progress) will become the a standard wto describe PIMs.

9.1.2 Platform-Specific Model (PSM)

At some point we will have developed guidelines, and notations for addingplatform specific constraints to aid in transforming PIMs into PSMs. This isarea ripe for infrastructure technology adoptions as the state of the art evo.

PSMs are described in one of two ways:

1. UML diagrams (class, sequence, activity, etc.) found in one of the adopted UMplatform specific profiles. Currently only the UML Profile for CORBA has been defined. In the future UML Profiles for EJB, SOAP, etc., are expected to be defi

2. Interface definitions in a concrete implementation technology (e.g. IDL, XML, Java)

In both cases behavior and constraints are specified using a formal notation (UMdiagrams) or an informal notation (natural language) as appropriate



ay

ety

ined ++,

ined

m

wide

,

9.2 Languages

OMG adopted language specifications are IDL, UML, and CORBAScript. There mbe more in the future. In the future UML Profile for CORBA annotations should beadded to IDL to support the equivalence of both representations.

UML Platform Specific Profiles are languages for defining platform specific constructs.

9.3 Mappings

Mapping specifications define how to transform artifacts into other entities. A variof forms of OMG mapping specifications exist:

The IDL/<programming language> mappings define how to realize constructs defin IDL in various concrete programming languages. Examples are IDL/Java, IDL/Cetc.

UML Profile for <specific platform> define the generation of concrete interface definitions that correspond to the target platform along with their platform specificbehavior and constraints.

The XMI specification handles two transformations:

• the generation of XML DTDs from MOF models

• the generation of an XML document instance (which conforms to the above defXML DTD) from a specific UML model

The MOF/IDL specification defines how to generate IDL type definitions from a model found in a MOF repository.

Part of the XML/Value specification defines how to generate IDL type definitions froan XML DTD.

9.4 Interoperability Infrastructure

Examples: GIOP/IIOP, XML/Value, COM/CORBA, CORBA/SS7

Interoperability specifications cover a wide gamut of functionality. In general theirpurpose to allow implementations of the above artifacts to inter-operate across arange of platforms and environments.

9.5 New Submissions Requirements

Today there is broad consensus within the OMG community for the minimum requirements that must be met by submissions which define all but the model artifacts. With the rise of the modeling and specification techniques described in this paperthere are many opinions and a lack of agreement on what should be required forsubmissions that define modeling artifacts.



ither

h,

n be

n

rce

s in the

ce of

se of .

be ntil

of

The key criterion that OMG submissions must meet is that there is a working implementation of the proposed technology and that it is possible to determine (eautomatically or manually) whether a particular product actually implements the technology.

In order to continue to meet the implementation criterion using the MDA approacModel, Service and other specifications shall include at least one PSM and either define a PIM corresponding to the PSM or reference an existing PIM. The PSM castated in terms of a UML Profile for a <specific platform> and/or as an interface definition in a concrete implementation technology.

9.5.1 Relationship between PIM and PSMs

An issue that needs to be addressed is that of the normative relationship betweemodels which are related to one other. There are 2 cases to consider.

1. One of the models can be algorithmically produced from the other via a standardized algorithm (possibly with some auxiliary input). In this case the sou(plus possibly auxiliary required input) and the generation process are normative,with the generated model being mechanically generated.

2. If there is no standardized generation process, then both the models shall be considered to be normative, and changing and/or fixing one may entail changethe other. In this case submissions will have to convincingly demonstrate that PSM is in fact a valid implementation of the PIM, and precisely delineate how elements of the PSM trace to elements of the PIM.

Note that the above principles are set forth for the purpose of deciding conformanproducts. As described below, submissions may be required to include multiple artifacts.

9.5.2 CORBA-Specific Implementation Technologies

Submissions may wish to take advantage of the additional rigor provided by the uthe UML Profile for CORBA for the purpose of specifying a CORBA-specific PSM

Note that a model specified using the UML Profile for CORBA implicitly and unambiguously specifies a set of IDL interfaces. (The profile specifications descrihow to generate the IDL). In effect two PSMs are being standardized. However usuch time as generation tools are commonly available, submissions shall also be required to supply the generated IDL, as well as the UML model. In keeping withprinciple one above if there is a discrepancy between the two, the UML model shall take precedence until such time as the discrepancy is rectified by an F/RTF.

9.5.3 Other Platform-Specific Implementation Technologies

Once other PSMs become available, such as a UML Profile for EJB, then similarprinciples will apply. In the case of EJB, both the UML model (expressed in termsthe EJB Profile) and the generated EJB artifacts shall have to be provided, with the UML model taking precedence in the event of a discrepancy.



P) to ed to sions ch

re of ons l

10 What Process Changes will be Necessary to Support this Expanded Agenda

It should be clear that very few formal changes (in the sense of changes to the P&the OMG process are required. Basically the RFP template will need to be updatcapture the above stated new requirement for PIMs and PSMs. In addition submiswill have to explicitly state which parts of the specification are normative and whiparts are automatically derivable via other mapping specifications.

The bigger changes are expected to take place more in everyday practice. As mothe MDA infrastructure is put in place, the expected level of precision in specificatiwill increase. More normative UML models will appear. There will be less informaEnglish.



Date post:	11-Oct-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

A Technical Perspectivexml.coverpages.org/OMG-tech-01-02-04.pdf · Model Driven Architecture A...

Documents