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
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.
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.
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.)
MetaObject
SubjectArea
CollectableMetaObject
AttributableMetaObject
MetaRelationship
MetaAttribute
|
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.
AttributableMetaObject.HasSubtype.AttributableMetaObject CollectableMetaObject.IsUsedIn.SubjectArea MetaAttribute.IsLocalMetaAttributeOf.AttributableMetaObject MetaRelationship.HasDestination.MetaEntity MetaRelationship.HasSource.MetaEntity |
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.
|
|
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).
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.
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.
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.
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.
This meta-meta-entity, a direct subclass of AttributableMetaObject, defines one attribute Type (CDIF-type Enumerated, allowing for the values Kernel, Characteristic and Associate).
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.
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.
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).
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.
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:
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.
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.
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.
Copyright (©) 1996 by Rony G. Flatscher