An Overview of the Architecture of EIA's CASE Data Interchange Format (CDIF)

Univ.Ass. Dr. Rony G. Flatscher
Abteilung für Wirtschaftsinformatik
(Department of Management Information Systems)
Wirtschaftsuniversität Wien
(Vienna University of Economics and Business Administration)

Augasse 2-6
A-1010 Wien


In software engineering, especially with CASE-tools and CASE-systems, conceptual models defined in one tool usually are not transferrable to another vendor's tool. This was seen as a substantial problem by EIA. In 1987 EIA started work on a CASE data interchange format (abbrev.: CDIF) which attempts to tackle the problem by defining so called meta-models for specific subject areas by means of an object oriented entity relationship modelling technique. [EIA's CDIF meetings have been open for visitors and new members, cf. [W3CDIF].] ISO/IEC JTC1/SC7/WG11 is in the process of adopting the EIA CDIF Interim Standards for ISO. SC7/WG11 registered the EIA CDIF Interim Standards as ISO Committee Drafts which have been getting processed by means of international public reviews and comments.

1 Introduction

The Electronic Industries Association (abbreviated: EIA) started work on defining a CASE data interchange format (abbreviated: CDIF) standard in October 1987. The principal idea is to define so called "meta-models" according to an entity relationship modeling paradigm. Different modeling techniques, such as data modeling, data flow modeling, state event modeling, object oriented analysis and design etc. should be transferrable among CASE tools of different vendors, if the transfers adhere to the appropriate CDIF standards. The semantics of the transferred models have to follow those of the meta-models, also called "Subject Areas" in CDIF's terms.

The 1991 set of "EIA CDIF Interim Standards" introduced the ability for entity types to be interpreted as classes which may be subclassed in refined meta-models. The 1994 standards extended the OO notion by adding the ability to subclass relationship types too.

CDIF has in/formal liasons with ANSI (X3L8, X3H4), ECMA (TC33:PCTE), IEEE (P1175), ISO (ISO IRDS, ISO/IEC JTC1/SC7/WG11) and OMG. E.g. ISO/IEC JTC1/SC7/WG11 has started work on adopting the EIA CDIF Interim Standards.

2 Architecture

2.1 The Meta-Meta-Model

CDIF first defined a "meta-meta-model" in [CDIF94a] which describes in terms of itself the basic object-oriented classification tree and the expressiveness of its own ERM-technique, depicted in figure 1, which gets used for defining the meta-models themselves. (The model even allows for taking advantage of multiple inheritance.)

Figure 1: Classification Tree (Meta-Meta-Entities), cf. [CDIF94a], p.31.


Meta-relationships are defined to be binary and express the cardinality in a minimum/maximum fashion. Although the meta-meta-model, and therefore the meta-models which have to obey the rules defined in the meta-meta-model, may only express binary relationships, the planned subject area named "Data Modeling" defines much more comprehensive entity-relationship modeling abilities, including roles, role constraints, and complex and N-ary relationships, among other things.

Figure 2 depicts the meta-meta-relationships defined for the meta-meta-model. Figure 3 shows the classification tree, the meta-meta-entities and the meta-meta-relationships, i.e. the meta-meta-model itself. Comparing the names of meta-meta-relationships in figure 2 with figure 3, it becomes clear that the arrow on the line connecting both meta-meta-entities determines in which direction the name of a meta-meta-relationship has to be read.

Figure 2: Meta-Meta-Relationships, cf. [CDIF94a], p.31.


If a meta-meta-entity is subclassed, like MetaObject is subclassed with SubjectArea and CollectableMetaObject, this hierarchy is depicted by a line going down from the meta-meta-entity MetaObject and leading into the appropriate subclass meta-meta-entities (without an arrow on either end, nor with minimum/maximum cardinality values).

Because of the basic object oriented inheritance features all meta-meta-entities descending from MetaObject inherit all of its meta-meta-attributes, the most important being CDIFMetaIdentifier which describes every single meta-object (meta-entity, meta-relationship, meta-attribute) uniquely.

Figure 3: Meta-Meta-Model, cf. [CDIF94a], p.33.
a picture of the Meta-Meta-Model

2.1.1 MetaObject

This meta-meta-entity forms the root of the CDIF-meta-meta-entity tree and defines all attributes common to all subclasses, allows for defining a unique value (attribute CDIFMetaIdentifier, CDIF-type Identifier), aliases for meta-meta-entities (attribute Aliases, CDIF-type String), constraints for meta-meta-entities (attribute Constraints, CDIF-type Text), a description (attribute Description, CDIF-type Text), a name (attribute Name, CDIF-type Identifier) and a usage explaining how entities are to be handled for an importer/exporter (attribute Usage, CDIF-type Text).

2.1.2 SubjectArea

This meta-meta-entity, a direct subclass of MetaObject, allows for defining which CollectableMetaObjects are being used in which subject area (meta-model), allowing thereby to track the usage of defined meta-entities in the CDIF integrated meta-model which is nothing else but the collection of all meta-model-definitions. The meta-meta-entity SubjectArea gets one additional attribute, named VersionNumber with a CDIF-type of String.

2.1.3 CollectableMetaObject

This meta-meta-entity, a direct subclass of MetaObject, serves as an abstract class and adds no attributes of its own. The meta-meta-relationship IsUsedIn relates SubjectArea with CollectableMetaObject and gets inherited by all subclassed meta-meta-entities.

2.1.4 MetaAttribute

MetaAttribute, a direct subclass of CollectableMetaObject, defines four attributes, DataType (CDIF-type Enumerated), Domain (CDIF-type Text), IsOptional (CDIF-type Boolean) and Length (CDIF-type Integer). DataType determines the available CDIF-data types allowed for devising meta-models: Identifier, Integer, String, Text, Boolean, Date, Time, BitMap, Float, Enumerated, Point, PointList, IntegerList.

Please note that a planned subject area ("Data Definition") being defined by CDIF allows for defining arbitrary datatypes which may be used in CDIF-transfers. So the datatypes defined with meta-meta-entity Attribute merely determine the types available for defining meta-models (subject areas) or extending meta-models built for CDIF-transfers.

2.1.5 AttributableMetaObject

This meta-meta-entity, a direct subclass of CollectableMetaObject, serves as an abstract class and adds no attributes of its own. The recursive meta-meta-relationship HasSubtype allows for subtyping of meta-entities and meta-relationships.

2.1.6 MetaEntity

This meta-meta-entity, a direct subclass of AttributableMetaObject, defines one attribute Type (CDIF-type Enumerated, allowing for the values Kernel, Characteristic and Associate).

2.1.7 MetaRelationship

This meta-meta-entity, a direct subclass of AttributableMetaObject, defines four attributes for expressing the minimum/maximum cardinality (CDIF-type String): MinSourceCard, MaxSourceCard, MinDestCard and MaxDestCard.

2.2 Meta-Models

Meta-Models are predefined definitions for transferring models for a specific "subject area" like data models, state event models, data flow models, and the like. All the CDIF Interim Subject Area Standards together define a "CDIF Integrated Meta-Model" of which each subject area utilizes a subset.

The CDIF Integrated Meta-Model itself is defined by means of the object oriented entity-relationship-modeling technique, defined with CDIF's meta-meta-model !

It is possible that different subject areas overlap in their usage of defined meta-entities and meta-relationship, allowing one to take advantage of predefined meta-entities and meta-relationships, when defining a new subject area.

By the same means it becomes possible for CASE-tools vendors to extend the meta-model being used as the transportation model for their models. In this case, the standard mandates that importers may safely ignore proprietary (non-CDIF) extensions to the CDIF Integrated Meta-Model, on the other hand allowing one CASE-tool-vendor to exchange its models with the means of CDIF among all of its own tools, without the need to lose additional, proprietary semantics in the transfer.

An EIA CDIF Interim Standard for a meta-model attempts to allow for capturing the most widely used concepts (semantics) in a particular problem domain. As a CDIF transfer is meant for carrying a specific model from one tool to another, the model in question must be described by the appropriate meta-model (also called subject areas). As meta-models are merely views upon the CDIF Integrated Meta-Model by collecting them according to a specific subject area, it becomes possible to use more than one subject area in the transfer.

It is also possible to transfer meta-entities and meta-relationships for a CDIF-transfer, which have not been defined yet for CDIF. This way semantics may be captured and transferred for which no CDIF-meta-models exist as of yet, or which are not even intended to be produced at the time of the transfer.

The two most important meta-models are the "Foundation Subject Area" and the "Common Subject Area" which are outlined below. They are necessary for every CDIF-transfer.

2.2.1 Foundation Subject Area

This subject (cf. [CDIF94e]) area serves as the root of all other subject areas within CDIF. All CDIF meta-models must at least subclass directly or indirectly the meta-entities RootObject (abstract class of type AttributableMetaObject) for RootEntity and the meta-relationship IsRelatedTo (with the full name of RootEntity.IsRelatedTo.RootEntity).

2.2.2 Common Subject Area

The Common Subject Area ([CDIF96a]) refines the primitive Foundation Subject Area by defining the meta-entities ToolUser, AbstractionLevel, SemanticInformationObject (parent of the subclass meta-entities Derivation, DataObject and ProcessObject), TextualConstraint, PresentationInformationObject and AlternateName. It describes aspects which may be relevant for identifying the tools involved in a CDIF-transfer, as well as the SemanticInformationObject which is used as the base for all semantically related information in further subject areas, defining e.g. the semantics of a transferrable dataflow model. All of these meta-entities have RootObject as their root.

The root of the following meta-relationships is IsRelatedTo. The meta-relationships allow for further structuring the meta-entities by relating them with each other, e.g. with meta-relationships such as SemanticInformationObject.IsCategorizedIn.AbstractionLevel, or by defining the alternate names for objects which have synonyms in a CDIF-transfer, e.g. RootEntity.Has.AlternateName.

2.2.3 Additional Subject Areas

CDIF is very active in preparing subject areas for specific problem domains. Some are already finalized, others are in the works, and there may be further subject areas which are planned or being explored at this point in time.

The finalized subject areas are:

Subject areas, which are being developed right now ("in working group review"), are: Subject areas which are planned or explored:

3 CDIF Transfer

A CDIF transfer is defined in [CDIF94b] giving an overview, [CDIF94c] describing a syntax and [CDIF94d] defining an encoding. The syntax is entitled "SYNTAX.1" and the encoding is named "ENCODING.1" hinting at the possibility, that additional CDIF-transfer syntaxes or encodings (or both) may be defined. As a matter of fact CDIF is in contact with OMG and experimenting with a CORBA compliant IDL for defining CDIF transfers.

[CDIF94d] is a plain ISO 8859-1 encoding, which will be changed for allowing supporting double-byte characters, a requirement which surfaced while CDIF started to work with ISO.

Both, [CDIF94c] and [CDIF94d] explain the rules a CDIF transfer has to adhere to, supplemented with BNF definitions.

3.1 Exporter Responsibilities

An exporter tool should minimize extensibility definitions to the CDIF Integrated Meta-Model, by using all meta-entities and meta-relationships defined in any CDIF subject area. Also, all information pertaining to the model to be transferred should in fact be transferred ("maximum output"). Even if a tool cannot export the required meta-attributes for meta-entities, the exporter has to supply values in the case that such meta-attributes need mandatory values.

3.2 Importer Responsibilities

An importer tool must be able to read all transfer data, even if it does not use all of the read information ("information retention"). While working on importing a CDIF-transfer, an importer first must set up a "working meta-model" by defining the meta-object (the object representing a meta-entity) for RootObject from [EIA/IS-122], which gets populated while the import proceeds. In the course of importing the information contained in a CDIF-transfer no forward references in the defined meta-model are allowed. If no values are given for optional meta-attributes, this should be interpreted by the importer as the fact, that at the time of generating the CDIF-transfer, no information on that value was available to the exporter.

4 Conclusion

EIA's CDIF represents a very interesting attempt to transfer models created with different SE-tools, most notably CASE-tools, among tools created by different vendors. Due to its acceptance by various tool vendors and standardisation organisations, it seems that CDIF will be a set of standards which will be of great relevance for software engineers in the future. The entire set is being modeled with an OO version of the entity-relationship modeling technique, which is described in the early [CDIF94b] CDIF interim standard and which has been sketched above.

5 References

CDIF - Framework for Modeling and Extensibility, Interim Standard, EIA 1994.

CDIF - Transfer Format - General Rules for Syntaxes, Interim Standard, EIA 1994.

CDIF - Transfer Format - Transfer Format Syntax - SYNTAX.1, Interim Standard, EIA 1994.

CDIF - Transfer Format - Transfer Format Encoding - ENCODING.1, Interim Standard, EIA 1994.

CDIF - Integrated Meta-model, Foundation Subject Area, Interim Standard, EIA 1994.

CDIF - Integrated Meta-model, Common Subject Area, Interim Standard, EIA 1996.

CDIF - Integrated Meta-model, Data Flow Subject Area, Interim Standard, EIA 1996.

Internet Homepage of CDIF:

Date of Article:

Published in:
Journal of the WG 5.2, "Informationssystem Architekturen" (architecture of information systems) of the German "Gesellschaft für Informatik" (German society of informatics), SG 5.2.1, "Modellierung betrieblicher Informationssysteme" (modeling of business information systems):
"Informationssystemarchitekturen - Rundbrief des GI-Fachausschusses 5.2: An Overview of the Architecture of EIA's CASE Data Interchange Format (CDIF)." Volume 3, Number 1, Summer 1996, pp. 26-30.

Presented at:
"Fachtagung der Fachgruppe 5.2.1 - Modellierung betrieblicher Informationssysteme (MobIS)", 1996-10-11, BTU Cottbus, Germany.

Copyright (©) 1996 by Rony G. Flatscher