Both users and vendors have a major problem with Computer Aided Software and Systems Engineering (CASE) tools. The information held by one tool is never quite the same as that required by another tool.
Users need to be able to move information from one CASE tool to another in order to develop systems efficiently. They need to move information from a tool to a repository and back. They need to exchange data between repositories. And if users want to use more than one tool at a time, for example because no single tool on the market meets all their requirements, this data exchange even needs to be dynamic, and interactive. An example for this is "round-trip" engineering.
Vendors have to meet that need by providing interfaces between all the tools and repositories demanded by their user base. Without appropriate technology, this is almost an impossible thing to do, simply because of the development cost involved. So what technology is available that can resolve this in an elegant and cost-effective manner?
CDIF provides the solution to this problem for both users and vendors. CDIF is a Family of Standards that lays out a single architecture for exchanging information between modelling tools, and between repositories, and defines the interfaces of the components to implement this architecture.
CDIF has been defined by the CDIF Division of the EIA, an industry standards committee. CDIF is also being standardized at an international level through ISO/IEC JTC1/SC7/WG11. Many of the major CASE and repository vendors, and some large user organizations have pooled their expertise and resources to develop this Family of Standards. Currently, the CDIF Family of Standards has 10 standards as members and more will be added in the immediate future. The CDIF standards development process is open-ended, and driven by the interests of the CDIF member organizations. Any organization can become a CDIF member and thus influence current and future CDIF work (see below).
One of the major problems that users of CASE tools suffer is that of "locked-in" data although they want to reuse the data outside the tool in which it was originally created. Why do users want to do that?
Before CDIF, if no specific software interface was implemented to move information between the particular combination of tools required for a project, little could be done other than re-enter the models and hope for the best. This is a costly solution: re-entering can and will introduce errors in the models, and it will require expensive and scarce resources because the person re-entering the model must be an expert in both tools. It is likely that this person will also need to convert the models into a slightly different modeling technique. This obstacle effectively disallows concurrent engineering and team work.
With the CDIF Family of Standards, each tool needs only one import and one export interface to be able to communicate with any other CDIF-conformant tool. This gives the user much greater flexibility in tool selection, and configurations for tool environments. CDIF improves the transfer of information between teams, projects, departments and whole organizations, and is one of the core enabling technologies for creating integrated systems and software engineering environments.
For the vendors, the CDIF Family of Standards releases them from the problem of developing multiple interfaces for different tools to satisfy their customer base. They need only develop a single interface, and can therefore afford to provide as much functionality as required in a single interface, rather than having to spread expensive resources across multiple interface developments competing for the same resources.
The CDIF Family of Standards provides a published set of vendor-independent, method-independent definitions for meta-data concepts in general, and for modelling data and related concepts in particular. In particular, CDIF defines the CDIF Integrated Meta-model, a multi-facetted, integrated, multi-disciplinary information model for modeling concepts.
The CDIF Family of Standards also defines standard ways of moving this information between tools, without the need for customized interfaces. In particular, CDIF defines the CDIF Transfer Format, a file format to represent models.
CDIF is not a specification of a CASE tool or a repository; it specifies what an export/import utility needs to present at the export/import interface as an external representation of a CASE tool's internal data. This limit in CDIF's scope enables a rather wide consensus to be reached on CDIF, since there is no requirement to define a single "correct" way of representing data, but a well-defined superset which must be capable of covering everyone's needs, although representing common concepts in the same way.
CDIF re-uses as much open technology and standards as possible, avoiding the re-invention of the wheel. For example, CDIF supports IDEF0 and IDEF1x, and will likely support the upcoming Unified Modeling Language (UML).
The CDIF Technical Committee (which together with the CDIF Management Committee forms EIA/CDIF) has developed CDIF as a Family of Standards. This Family of Standards is partitioned into three distinct groups of standards documents:
The CDIF Technical Committee is well aware of the fact that they will not be able to cover all possible information found in CASE tools today, and define a standard for the interchange of all this information. Therefore, the CDIF Integrated Meta-model is divided into parts, called Subject Areas. Each Subject Area covers one specific technique found in CASE tools, such as Data Flow Modeling, or Object-oriented Analysis and Design.
Each of these Subject Areas is released independently of the others in a separate standards document. This allows the CDIF Family of Standards to grow over time, by adding additional standards for as yet uncovered Subject Areas. Because of that, the CDIF standardization is an ongoing effort with no planned end time, rather than a one-shot activity.
It is worth noting, that although the concepts supported by CDIF are potentially found in different Subject Areas, any of those Subject Areas forms a view, rather than a partition, on the the CDIF Integrated Meta-model. This means that if the same concept is used in several Subject Areas, it is actually defined only once within the CDIF Integrated Meta-model, and only used in multiple Subject Areas.
For example, the concept of an Attribute is relevant to many different Subject Areas, such as Entity-Relationship-Attribute Modeling, Object-oriented Analysis and Design, Data Flow Modeling, and some State Transition Diagram techniques. Making a Subject Area a view rather than a partition allows CDIF to be used as the underlying understanding how the different pieces of (meta-)data from different techniques and methods, and in different tools and lifecycle phases, actually fit together. With CDIF, for example, a tool supporting Object-oriented Analysis and Design, can cooperate with a tool supporting database design.
In case a concept required by a tool is not available in the CDIF Integrated Meta-model, tool vendors can extend the CDIF Integrated Meta-model using CDIF's Extensibility mechanisms. This means that tool vendors can define their own additional information they want to interchange in a vendor-defined Subject Area, and export and import this information in their implementation. The CDIF architecture treats a model that uses extensibility in no way different than a model which uses only the Integrated Meta-model, or a hybrid, except that an extended model needs to describe within the transfer how the CDIF Integrated Meta-model has been extended, while a reference to a published standard is sufficient for a model that uses only the standardized CDIF Integrated Meta-model.
This architecture that uses extensibility as one of its built-in core concepts rather than an afterthought, is extremely powerful and flexible. A repository, for example, that might have no hard-coded schema, can store all the information from a CASE tool that uses extensibility, without the need to change a single line of code in the repository implementation or it's CDIF interface. It can even extend its schema on the fly (provided that the repository supports that) because the schema information is provided in the CDIF transfer.
Among other things, Extensibility allows tool vendors to use CDIF as a general exchange format, regardless of whether all the information found in their tools has been standardized by the CDIF Technical Committee at that time. Today we know of at least two major CASE tool providers who have implemented CDIF as the data exchange format between the tools of their own tool family, using Extensibility only but conforming to the CDIF Transfer Format, rather than implementing their own proprietary data exchange format.
As of September 1997, this is the list of the members of the CDIF Family of Standards with their current status (the standards marked with "released" can be purchased from the EIA, most of the ones marked "in review" can be obtained from the CDIF Website at http://www.cdif.org as a draft, or from the appropriate Working Group's editor, preferably by attending a CDIF meeting):
As opposed to other transfer formats for various purposes, CDIF has a formal architecture. This architecture is used to define the relationship between the information represented in a CDIF transfer, the semantics of that information, (expressed by the CDIF Integrated Meta-model, and any extensions to it) the rules for extending the CDIF Integrated Meta-model, and how CDIF Transfer formats need to be architected. This four-layer model is the same like that used by many repository implementations and the respective repository standards.
The following table lists these four levels and examples for what concepts are represented on what level:
Meta-meta-model e.g. "MetaEntity" and "MetaRelationship"
Meta-model e.g. "Process" and "Attribute"
Model e.g. "Process Order" and "Balance"
Data e.g. "$500" and "John Doe"
With the adoption of this formal Framework, the definition of the Transfer Format (how a file or an API looks like) and the content definition can be separated. This means that any CDIF syntax, for example, does in no way depend on the information for whose transmission it is used, and any CDIF model can be interchanged with any of the available transfer formats.
Thus, for example, a CDIF parser can be constructed that is completely independent of the kind of information it will finally parse. It also means that the information is being defined without regard to representing it in a certain syntax: The CDIF Framework ensures that model data using every Meta-model expressable in CDIF can also be represented using any CDIF Syntax and any CDIF Encoding, and how.
This orthogonality is also expressed in CDIF's definition of CDIF Conformance.
The CDIF architecture, defined in the CDIF Framework, supports multiple Syntaxes and Encodings. The CDIF Technical Committee has initially defined a single syntax for file or stream-based data exchange, but other syntaxes may be defined, either by the CDIF Technical Committee, or other bodies. The CDIF Family of Standards provides a set of rules to which any syntax and encoding must conform to be used as a CDIF-conformant transfer format (this is defined in the standard "CDIF Transfer Format - General Rules for Syntaxes and Encodings.")
With any syntax, it is possible to provide multiple encodings. The syntax is a set of rules dictating the production of a set of terminal symbols from any instance of the CDIF Meta-Meta-model (the working Meta-model consisting of parts from the CDIF Integrated Meta-model and vendor extensions), and from any instance of a Meta-model (the actual model data). The encoding is the definition of how the terminal tokens are expressed as actual characters or bytes.
The CDIF Technical Committee has currently defined asyntax SYNTAX.1, with a Clear-Text Encoding, called ENCODING.1. A fragment of a file using CDIF SYNTAX.1 and ENCODING.1 is shown below:
Š
(Attribute ATT01
(Name "Current Balance")
(CreationDate "951102")
(CreationTime "08:00:01.1234")
)
(MoneyDataType MDT01
(Name "Bank Balance in U.S. Dollars")
(CurrencySymbol "USD")
)
(ComponentObject.References.DefinitionObject REF01 ATT01 MDT01)
Š
All CDIF Syntaxes and Encodings must provide a standard "envelope" which identifies the contents as a CDIF transfer, and defines the Syntax and Encoding used in the body of the transfer.
The body of the transfer consists of three sections: The Header, the Meta-model definitions, and the Model definitions. The header defines such things as the identity of the exporting tool, the default character sets, text formats used in the transfer and details of the date and time of the export.
The Meta-model section defines the complete Meta-model used in the transfer (i.e. the type of information being transferred, e.g. whether an Object-oriented Analysis and Design model is contained or Project Management Data, or both). Reference to the Subject Areas of the CDIF Integrated Meta-model is made by a single statement each, giving the version number of the Subject Area. Any Meta-model extensions are given in full. If only the CDIF Integrated Meta-model us used, no extensions are required.
The Model Section contains the actual instances of the model data to be transferred.
Recently, the CDIF Technical Committee defined another member of the CDIF Family of Standards that enables modeling information to be exchanged dynamically using the Common Object Request Broker Architecture (CORBA).
Conforming tools expose the modeling information they hold as CORBA objects that can be accessed by any client on the internet (depending on corporate security implementations). In particular, meta-objects can be found by name, models can be queried and traversed, and unknown meta-model can be discovered.
The CDIF Integrated Meta-model defines what data can be interchanged using CDIF, and what the semantics of the data are. Several aspects of the CDIF Integrated Meta-model are examined in more detail in the following sections.
CASE tools present information to the user in a variety of ways. Diagrammatic notations vary from tool to tool. For example, many different notations have been developed for Entity-Relationship-Attribute models. This poses the problem how to interchange information between tools that represent the same information using different diagrams, or different information using the same diagrams.
Like the separation between the information and its representation using a transfer format that has been discussed in a previous section, CDIF provides a clear and complete separation of the semantics of the information being transferred and the presentation information employed by the tool to present the semantics to the tool user.
This has several advantages. The understanding of the underlying semantics is greatly simplified by the removal of all presentation information. The presentation information can be represented in a standard manner regardless of the semantics being expressed. There can be multiple sets of presentation information for a single set of underlying semantics. For example, some CASE tools allow the user to view a State Transition model as a Node-Edge graph, and also as a State Event matrix. With CDIF, the semantics are represented once, and two different kinds of presentations can be linked to that single semantic model.
To use another example, a Class-Association model is represented using the semantic concepts of Classes, and Associations (and others). In CDIF, these concepts do not assume a specific graphical representation, like boxes or solid arrows, because other tools might represent the same information using clouds and arrows, or even a completely different format.
When CDIF (meta-)data is exported, the semantic information is separated from the presentation information. The semantic information represents semantics only, without regard to how these semantics could be presented to the user.
Additionally, the exporting tool exports the information on how it represents those semantics concepts to the user, i.e. as circles and arrows at certain coordinates in a drawing area. A sophisticated CASE tool that imports that data may be able to present both semantics and presentation the same way to the user as the exporting tool had described. A less sophisticated tool, that is not able to represent Classes as boxes, for example, can disregard certain presentation information and present the model using clouds instead. The separate semantics ensure that the importing CASE tool can focus on a correct translation of semantics, and adjust the presentation information accordingly.
The largest part of the CDIF Family of Standards describe the semantic part of the CDIF Integrated Meta-model. This section gives a short overview about the concepts found in a number of them.
The Foundation Subject Area provides the root of the inheritance hierarchy for the CDIF Integrated Meta-model. Its use is required for every transfer.
The Common Subject Area concentrates on aspects common for many objects transferred in a CDIF transfer. Examples of the concepts defined here include Alternate Names, details on the user who created or updated an object, Constraints on objects and similar general information. It also provides the concepts SemanticInformationObject and PresentationInformationObject from which all objects in the semantic and presentation parts of the Meta-model inherit.
The Data Modeling Subject Area covers the main forms of conceptual and logical Entity-Relationship-Attribute modeling encountered in information systems and database development. It is not intended to cover the object-oriented approach; additional information is provided by the Object-oriented Analysis and Design Subject Area. It does cover forms of Entity-Relationship modeling from those supporting only binary unattributed relationships to those allowing n-ary attributed relationships, attributed roles, orthogonal subtypes and role-constraints.
The Data Definition Subject Area covers the definition of attributes which are used by other Subject Areas such as Data Modeling or State Event Modeling, and the most commonly found data types such as fixed and floating point numbers, money, strings etc. It also allows to represent structured data types and variants, with associated domains.
In the Data Flow Model Subject Area concepts are provided to support existing Data Flow Modeling techniques such as IDEF0 or Yourdon/DeMarco. It supports the decomposition of processes, stores, and flows, and the reuse of the definitions for those processes, stores, or flows for a number of occurrences. Complete support for real-time oriented techniques is outside the scope of this Subject Area. Some of them are provided by the Computer Aided Control Systems Design Subject Area.
The State Event Modeling Subject Area covers techniques that use the concepts of states, transitions between those states, events, conditions and actions. These techniques include state transition diagrams, state-event matrices, Entity Life History Models, Harel's Statecharts, and virtually all techniques to specify object behavior. States may be decomposed into sequentially or parallel executing submodels, or into mutually exclusive alternatives. Events and conditions guard transitions and may fire actions which also may be hierarchic. This Subject Area also allows the reuse of submodels in several contexts.
The Object-oriented Analysis and Design Subject Area supports the concepts found in today's Object-oriented Analysis and Design methods, techniques and tools, such as Booch, OMT, Shlaer-Mellor, UML, Firesmith, Henderson-Sellers, Graham, Coad etc. The Working Group defining this Subject Area works closely with leading methodologists and the Object Management Group because the CDIF Technical Committee is very much interested in having only one rather than many competing standards.
The Computer Aided Control Systems Design Subject Area defines the concepts found in real-time oriented Control Design tools, such as Transfer Functions or Interpolation Tables. It adds the concepts not found in the Data Flow Model Subject Area that are required for real-time models (such as Sampling Times or precise execution times) to support the data exchange between CACSD tools.
The Presentation Information Model defines the way information is presented by tools for the user, such as boxes, arrows, labels, or colors. The separation between semantics and presentation is a fundamental part of the approach adopted by CDIF. It enables the underlying semantics to be modeled in their purest form without a need to "bend" the objects, relationships and cardinalities to reflect the different ways that methods and tools choose to present the (same) information to their users.
The Presentation Location and Connectivity Subject Area supports node-arrow graphs, and labels attached to them. The Subject Areas "Shape" and "Global Parameters for Repeating Objects" (planned) add information about the shape of nodes, and allow the definition of style sheets which can be used for diagrams.
Defining an enabling technology rather than an end product, CDIF recognizes the need for cooperation with other interest and standards groups. Standards coordination is performed on two levels:
Further, CDIF meetings have often been collocated with other groups' meetings, in order to present each others' work and jointly progress on specific issues.
Currently, CDIF cooperates formally and informally with the following bodies:
The CDIF Technical Committee is actively developing new Subject Areas for the CDIF Integrated Meta-model, and several new Subject Areas are planned. Its sibling, the CDIF Management Committee, is responsible for general management and organization issues related to the CDIF Family of Standards, and for coordination with other standards groups, and with tool vendors and users.
Both Committees together form the CDIF Division of the Electronics Industries Organization (EIA) which is an ANSI-accredited standards body. CDIF membership is by organization (one organization, one vote) and is open to any organization with an interest in the work of CDIF and related areas. International membership has been actively encouraged by the CDIF Division, and its parent, the EIA.
CDIF work is conducted through two forums: bimonthly meetings of one week duration and the circulation of Working Papers. Working Papers are used to advance the coverage and quality of the standards under definition by exploring new technical content, reviewing and refining existing portions of the Family of Standards, or commenting on other Working Papers. Working Papers also provide a way of participation for those unable to attend the bimonthly meetings. Technical working papers are generally the product of a single individual, or a small group of people working together on that subject.
Working Group sessions are conducted during the bimonthly meetings. The purpose of those meetings is to review the Working Papers circulated prior to the meetings and to advance the CDIF standard by developing additional Subject Areas. It is not necessary to be a member of CDIF to attend one meeting, or to submit Working Paper or comment on one; all contributions are welcome. It is recommended, though, to be available for discussion and comment. In recent times, many technical discussions have also occurred using e-mail only rather than to meet physically.
Three times a year, a CDIF Plenary takes place. At Plenary sessions, issues are discussed and voted on which require a vote of the general membership such as the publication of a standards document, or a change to the CDIF structure. Attendence of two plenaries out of three is required for every organization in order to gain or maintain voting rights within CDIF.
The CDIF Division actively encourages CDIF attendance and membership from users, vendors, government institutions, and academia. The structure of the CDIF Committees and their work is designed to allow these groups to contribute to the standard as it is developed.
As of September 1997, the CDIF membership fees are as follows (for current rates please contact Patti Rusher at the EIA):
Organization Annual Sales Annual Dues Rate
For-profit under $10 million: $750
$10 - 99 million: $1000
$100 - 250 million: $1500
over $250 million: $2000
Non-profit academic, government: $750
Associate: $500
It is expected that regular CDIF attendees become CDIF members. Visitors are welcome, though. There is no fee for a visitor. It is recommended that a visitor contact a CDIF officer prior to attending a CDIF meeting, for organizational purposes.
The development of the CDIF Family of Standards has been, and is, conducted solely on a voluntary basis by the member organizations. All individual costs, such as time, travel and accommodation, are covered by the representative's organization.
CDIF maintains a presence on the internet. The CDIF Website with up-to-date information about the current work of CDIF, contact information, meeting venues and current standards drafts can be found at http://www.cdif.org. There is an anonymous ftp server at ftp://ftp.cdif.org/cdif, and a mailing list for CDIF mailing of general interest which can be accessed from the website.
If you are interested in the work of CDIF, and consider getting involved, the best starting point is the CDIF Website with information how. This "Intro to CDIF" is continuously updated. The most recent version can be found at http://www.cdif.org/intro.html.
Note: CDIF is a Registered Trademark of the Electronic Industries Association.
