Augasse 2-6
Abteilung für Wirtschaftsinformatik
(Department of Management Information Systems)
Wirtschaftsuniversität Wien
(Vienna University of Economics and Business Administration)
A-1010 Wien
This paper introduces the reader to EIA's CDIF "MIDDLEWARE.1" draft, which will allow for distributing model data, meta-model data and the CDIF Meta-meta-model definitions by employing the appropriate OMG's CORBA 2.0 standards.
With this infrastructure it becomes possible to gather information on distributed model data objects, including those objects representing the appropriate meta-model and meta-meta-model definitions. Meta-meta-model and meta-model definitions are read only, but attributes of model data can be changed at runtime. The reader should be able to assess the core technology being developed by EIA's CDIF technical committee in the form of OMG IDL definitions and is directed to additional sources of information related to this interesting and important issue.
In 1996 the Object Management Group (OMG) issued a request for information (RFI) and a request for proposal (RFP) for preparing an OMG standard on "Object Analysis and Design" (OAD). In January of 1997 the following six submissions were proposed, using OMG's (cf. [W3OMG]) ordering:
As OMG has been always interested in merging and joining proposals, if technically feasible, it usually encourages submitters to co-operate and define common standards. In the case of the OAD-RFP the first results became visible in March 1997 where almost all submitters announced that their proposed technology would be combined as complementary with that of other companies.
Some of the submission companies like Platinum or Rational are at the same time members of EIA's (abbreviation for: Electronic Industries Association) CDIF (abbreviation for: CASE Data Interchange Format) committee, which was founded in 1987. The CDIF technical committee has been developing standards for interchanging model data between tools of different vendors, by defining extendable meta-models as the basis of the transfers, which themselves are founded on the "EIA/CDIF Integrated Meta-meta-model" (cf. [CDIF94a], [Flat96]).
EIA/CDIF itself has been pro-actively working with OMG technology and has developed a draft for a standard which would allow for an additional form of distributing meta-model and model data besides CDIF's [CDIF94c] and [CDIF94d]: "MIDDLEWARE.1" (cf. [CDIF97]). MIDDLEWARE.1 defines the CDIF Meta-meta-model and meta-models in terms of OMG's interface description language (IDL) which defines interfaces for CORBA 2.0. By doing so, the OMG developed know-how and infrastructure for distributing objects among disparate systems from different vendors can be directly used for federating meta-model and model data.
The acceptance of the EIA/CDIF set of interim standards in the industry has been impressively shown by some of the submissions to OAD's RFP by OMG, e.g.:
All the submissions which tackled the problem of exchanging model data among tools of different vendors referred to the EIA/CDIF set of standards for achieving this important ability.
In the course of the RFP for OAD the OMG work may yield an OMG standard on OAD as early as September 1997 and it most likely will base transfer of model data on the CDIF architecture and its transfer interim standards. Because of the fact that an OMG standard is devised, it seems to be very likely that the CDIF MIDDLEWARE.1 proposal, which builds exclusively on the OMG developed CORBA-standard, will become part of the OAD standard for exchanging model data. Due to these ongoing efforts OMG and CDIF officially established a liaison with each other in March 1997.
The CDIF architecture is documented in [CDIF94a], a brief overview is given e.g. in [Flat96].
Figure 1 depicts the CDIF Meta-meta-model in the form of
an extended entity-relationship diagram which defines the
concepts and the extended entity-relationship model which gets
used for defining meta-models. Rectangles in figure 1 represent
entity types (named "meta-meta-entity"), lines with arrows
relationship types (named "meta-meta-relationship"), lines
without arrows depict the superclass/subclass hierarchy. All
subclasses inherit all meta-meta-attributes and
meta-meta-relationships of their superclass(es).
|
|
Instances of the Meta-meta-model entity types build the so-called meta-model. Instances of the CDIF Meta-meta-model relationship types are used to relate the instances of the CDIF Meta-meta-model entity types to each other. In meta-models the generic term "meta-object" is used to refer to the so called "meta-entities", "meta-relationships" and "meta-attributes".
The CDIF interim standard meta-model [CDIF94e], named
"Foundation Subject Area", is built according to the rules
imposed by the CDIF Meta-meta-model and defines the root
meta-model for all CDIF based transfers of model data. It
contains the definitions of the fundamental meta-objects, which
must be subclassed in/directly by all CDIF compliant
meta-models.
A CDIF transfer allows for transferring, i.e. exchanging
model data in a standardized, non-proprietary way. A CDIF
transfer contains the meta-model according to which the model
data was composed and is to be found in the exchange. If it is
necessary for a transfer to refer to predefined i.e.
standardized meta-model definitions, it is possible to merely
denominate them.
A CDIF transfer demands from the exporter to supply the
maximum amount of information and to not expect that just a
certain tool will import the exported data. On the other hand an
importer is expected to read all transfer data and build a
so-called "working model" for it, even containing model data it
would not be able to understand.
In 1994 the interim standards [CDIF94b], [CDIF94c] and [CDIF94d] defined a clear-text encoded, batch oriented CDIF transfer. From the beginning the CDIF technical committee envisioned additional ways of transferring CDIF compliant model data, hence hinting of possible additional syntaxes and encodings by starting the numbering of the interim standard definitions with "1".
In 1996 the CDIF technical committee developed a draft (cf. [CDIF96c]) for adding a radical new way of exchanging CDIF compliant model data based on the OMG middleware standard CORBA (cf. [OrHaEd96], [ÖsRiVo96]). This paper refers to the second draft of the proposed CDIF interim standard "MIDDLEWARE.1" (cf. [CDIF97]), which should be finalized in summer 1997.
"MIDDLEWARE.1" allows for instantiating the CDIF Meta-meta-model and CDIF meta-models as CORBA objects and methods are defined to be able to exploit the relationships between Meta-meta-entities resp. meta-entities.
The overall framework in terms of the OMG/IDL can be pictured like ([CDIF97, p. 7]):
module CDIF { /* define the CDIF module */
/* module/interface definitions in MIDDLEWARE.1 */
<definition of CDIF-datatypes>
<definition of exceptions>
<module definition for CDIF "MetaMetaModel">
<module definition for CDIF "Foundation Subject Area">
<module definition for a CDIF standardized Subject Area>...
}; /* module CDIF end */
All parameters for methods are of type "IN". If a method returns more than one object reference then a CORBA sequence will be used. In such cases the appropriate typedef-statements will use a name with the trailing term Set (e.g. "typedef sequence<MetaObject> MetaObject_Set") in "MIDDLEWARE.1". Extensions to standardized meta-models or the definition of non-standardized subject areas have to be defined as separate modules and are not part of the standardized CDIF namespace.
The definitions for meta-meta-objects occur with meta-meta-attributes and for meta-objects with meta-attributes. MIDDLEWARE.1 first defines the thirteen CDIF datatypes available for assigning them to (meta-)meta-attributes with typedef statements (e.g. "typedef string TextDT"). Then all datatype definitions are used in the union defined for AnyDT which gets used for defining the type of the parameters for accessing (meta-)meta-attributes (cf. [CDIF97, p.11ff):
union AnyDT switch( short) {
case 1 : BitMapDT theBitMapValue;
case 2 : BooleanDT theBooleanValue;
case 3 : DateDT theDateValue;
case 4 : EnumeratedDT theEnumeratedValue;
case 5 : FloatDT theFloatValue;
case 6 : IdentifierDT theIdentifierValue;
case 7 : IntegerDT theIntegerValue;
case 8 : IntegerListDT theIntegerListValue;
case 9 : PointDT thePointValue;
case 10 : PointListDT thePointListValue;
case 11 : StringDT theStringValue;
case 12 : TextDT theTextValue;
case 13 : TimeDT theTimeDT;
default : short ignore;
};
In the case that a (meta-)meta-attribute does not contain a value (dubbed: "no value") then the discriminator needs to be set to a value which corresponds to the default section.
There are four exceptions defined: IllegalDataType (value is not drawn from the datatype's domain), ValueMustBePresent (value for a mandatory meta-/meta-attribute is missing), IllegalTraversal (meta-/meta-object does not participate in given meta-/meta-relationship) and IllegalAccess (meta-object does not contain given meta-attribute).
The IDL definitions for the CDIF Meta-meta-model build the module MetaMetaModel_02_00 which defines interfaces for all meta-meta-entities according to the CDIF Meta-meta-model. The meta-meta-attributes of meta-meta-objects are read only, i.e. their values can be retrieved but not set. Therefore there are get-methods defined only. It is also notable, that for this particular mapping there are no exceptions defined.
What follows are the IDL definitions as proposed in [CDIF97, 12ff], demonstrating that the mapping of the CDIF Meta-meta-model into OMG's IDL is clear and straight forward.
module MetaMetaModel_02_00 {
interface MetaObject;
interface MetaEntity;
interface MetaRelationship;
typedef sequence<MetaObject> MetaObject_Set;
interface MetaObject {
AnyDT getAliases();
AnyDT getCDIFMetaIdentifier();
AnyDT getConstraints();
AnyDT getDescription();
AnyDT getName();
AnyDT getUsage();
typedef MetaEntity MetaMetaEntity;
typedef MetaRelationship MetaMetaRelationship;
MetaMetaEntity get_metaMetaEntity();
MetaObject_Set traverseSrcToDest( in MetaMetaRelationship which );
MetaObject_Set traverseDestToSrc( in MetaMetaRelationship which );
boolean is_identical( in MetaObject other_object );
};
interface SubjectArea : MetaObject { AnyDT getVersionNumber(); };
interface CollectableMetaObject : MetaObject { };
interface MetaAttribute : CollectableMetaObject {
AnyDT getDataType();
AnyDT getDomain();
AnyDT getIsOptional();
AnyDT getLength();
};
interface AttributableMetaObject : CollectableMetaObject { };
interface MetaRelationship : AttributableMetaObject {
AnyDT getMaxDestCard();
AnyDT getMaxSourceCard();
AnyDT getMinDestCard();
AnyDT getMinSourceCard();
};
interface MetaEntity : AttributableMetaObject { AnyDT getType(); };
};
The CDIF Meta-meta-model is regarded to be at the same time the meta-model for itself therefore the statements "typedef MetaEntity MetaMetaEntity" and "typedef MetaRelationship MetaMetaRelationship" allow for interchanging both modeling levels within the methods defined with MetaObject and inherited via subclassing.
The methods defined for MetaObject allow e.g. for finding all source or destination (meta-)meta-entities a particular (meta-)meta-entity is related to via a given (meta-)meta-relationship. Method get_metaMetaEntity() returns the object reference of the class of which the (meta-)meta-entity is an instance of. There is no method defined to determine the instances of any given (meta-)meta-object, hence there is no navigation possible from the Meta-meta-model to a meta-model and from a meta-model to its appropriate model data.
The CDIF draft predefines one OMG/IDL module for the standardized meta-model "Foundation Subject Area" (cf. [CDIF94e]), whose RootEntity resp. IsRelatedTo serve as the superclasses for all other subject area meta-entity and meta-relationship definitions. The root meta-object RootObject defines the only meta-attributes for this subject area (cf. [CDIF97, 15ff]):
module Foundation_01_00 {
interface RootEntity;
interface RootEntity_IsRelatedTo_RootEntity;
typedef sequence<RootEntity> RootEntity_Set;
typedef sequence<RootEntity_IsRelatedTo_RootEntity>
RootEntity_IsRelatedTo_RootEntity_Set;
interface RootObject {
AnyDT getCDIFIdentifier();
void setCDIFIdentifier( in AnyDT value )
raises( IllegalDataType, ValueMustBePresent );
AnyDT getDateCreated();
void setDateCreated( in AnyDT value ) raises( IllegalDataType );
AnyDT getDateUpdated();
void setDateUpdated( in AnyDT value ) raises( IllegalDataType );
AnyDT getTimeCreated();
void setTimeCreated( in AnyDT value ) raises( IllegalDataType );
AnyDT getTimeUpdated();
void setTimeUpdated( in AnyDT value ) raises( IllegalDataType );
MetaMetaModel_02_00::AttributableMetaObject
get_attributableMetaObject();
boolean is_identical( in RootObject other_object );
AnyDT get_metaAttribute( in MetaMetaModel_02_00::MetaAttribute which )
raises( IllegalAccess );
void set_metaAttribute( in MetaMetaModel_02_00::MetaAttribute which,
in AnyDT value )
raises( IllegalAccess, IllegalDataType, ValueMustBePresent );
};
interface RootEntity : RootObject {
MetaMetaModel_02_00::MetaEntity get_metaEntity();
RootEntity_Set traverseSrcToDest(
in MetaMetaModel_02_00::MetaRelationship which )
raises( IllegalTraversal );
RootEntity_Set traverseDestToSrc(
in MetaMetaModel_02_00::MetaRelationship which )
raises( IllegalTraversal );
RootEntity_IsRelatedTo_RootEntity_Set traverseSrcToRelationship(
in MetaMetaModel_02_00::MetaRelationship which )
raises( IllegalTraversal );
RootEntity_IsRelatedTo_RootEntity_Set traverseDestToRelationship(
in MetaMetaModel_02_00::MetaRelationship which )
raises( IllegalTraversal );
};
interface RootEntity_IsRelatedTo_RootEntity : RootObject {
MetaMetaModel_02_00::MetaRelationship get_metaRelationship();
RootEntity traverseToDest();
RootEntity traverseToSrc();
};
};
As with the CDIF Meta-meta-model mapping there are methods defined for traversing meta-relationships in subject areas e.g. for finding all source or destination meta-entities a particular meta-entity is related to, all meta-relationships a meta-entity participates in, as well as returning the object reference for the meta-entity resp. meta-relationship the instance belongs to. Each additional subject area needs to in/directly subclass this foundation interface definition.
The presented draft for an OMG/CORBA compliant standard for interacting and thereby retrieving definitions of CDIF meta-models and their appropriate model data has some interesting implications:
For object-oriented system designers the OMG/IDL interface definitions may serve as a starting point to discuss the implemention of CDIF management and exchange software with object-oriented development environments. For final implementations it is advisable to wait until the "MIDDLEWARE.1" draft is finalized. and agreed upon with OMG in order to rely e.g. on firm definitions on the intended inheritance model on the one hand, and the rules to be applied for resolving multiple inheritance on the other hand.
Copyright (©) 1997 by Rony G. Flatscher