CDIF Frequently Asked Questions

I have a question about CDIF -- who should I ask?

Depending on the kind of your question, you might find an answer in this FAQ document, or by browsing the CDIF Website, by talking to a CDIF member or officer, attending a CDIF meeting, posting to the CDIF mailing list, or by asking your favourite modelling tool vendor. There are also some organizations and individuals who offer CDIF consulting services (see CDIF Vendors).

 

Why would any user want a vendor to provide a CDIF interface to their tool?

The larger you are as a user oganization, and the larger and more complex your projects are, the more likely you won't be able to standardize on one tool. Whether you are using "competing" tools for the same thing in different parts of your company, or tools with different focus in different phases of your lifecycle, does not matter. Then you want to get your data from one tool into another. In order to be able to do that in a standard way that works, that's what CDIF is for.

 

Why would any vendor want to implement CDIF?

Mainly because customers call up and demand 1) CDIF, or 2) an interface to tool X and the vendor decides to get out of the one-interface-development-per-tool mode into one-interface-for-all tools mode. A simple cost-based decision.
There are also some vendors who understand CDIF as strategic technology.

 

What's the hardest thing when writing a CDIF interface?

The hard thing is the importer. The importer needs to determine which of the concepts in the input data it understands and to which concepts in the tool they correspond to. Depending on how well-defined the semantics in the tool are, it might be difficult (note that the better you have defined your concepts in your tool, the easier, NOT the harder).

 

What does that mean that you don't believe that there is or will be any tool that can be conformant to all of CDIF? Is it a worthless standard?

Well, there is no need to conform to all of CDIF because it is hardly imaginable that a tool exports Data Flow Models, object-oriented analysis and design models, project management data and Control Systems Design models at the same time. The exporter specifies in the export what parts of CDIF it is using, and usually those will be few.
CDIF is not an all-or-nothing standard, a tool can be conformant to various degrees.
Note that a repository might likely be conformant to a much larger part of the CDIF Family of Standards than, let's say, a CASE tool.

 

Doesn't that mean that you better should have broken CDIF into many individual standards?

In fact, we have. There are many different CDIF subject areas, each addressing one "domain" one might find in a tool. These subject areas are individual standards in the official sense. Together with the standards defining the formal CDIF architecture and the Transfer Format they comprise the CDIF Family of Standards. A large family, actually.

 

What do I do if the CDIF Integrated Meta-model contains not all concepts that I need for my CASE tool? For example, CDIF has standardized Data Flow Modelling concepts, but I have a DFM dialect that additionally requires the support of timing information. Can I use the CDIF Transfer Format, and how?

One of the features of the CDIF Transfer Format is that it does not depend on the meta-model that is used during a transfer. The CDIF Transfer Format can exchange any model that is an instance of any meta-model (not just the standardized meta-model), as long as this meta-model has been defined within the CDIF architecture (i.e. is an instance of the CDIF meta-meta-model).

What you do in the example situation is that you pick the concepts from the standardized CDIF Subject Areas that you need for your tool, and create a new Subject Area ("my special subject area") in which you put all the concepts you need beyond the standardized concepts. During a CDIF Transfer using SYNTAX.1 and ENCODING.1, you will reference the standardized Data Flow Modelling Subject Area in the meta-model section using the Subject Area reference clause, plus list your extensions using meta-model extension clauses. In the model section of the transfer, you can then instantiate any concept, regardless of whether it has been standardized or whether it is part of your extension.

The CDIF Transfer Format works with a completely standardized meta-model, or a 100% proprietary meta-model, or any hybrid.

For a full example, see the appendix of the ENCODING.1 standard.

 

CDIF is only a transfer format and that won't help me.

That CDIF is only a transfer format is a myth that seems to be hard to eradicate.
CDIF is

1. an architecture for meta-modelling\
2. a vast, integrated meta-model, and
3. a transfer format.
4. In the future, we will likely also have standardized bindings to distributed object architectures such as CORBA and DCOM.

In terms of size, the CDIF Integrated Meta-model is far larger than any of the other components. And the meta-model is entirely independent of the transfer format. Thus the metamodel could be used and is used as a conceptual schema for repositories, for example, an application that is unrelated to a transfer format.

 

Why isn't CDIF producing all these standards much faster?

It is certainly true that CDIF has always preferred quality of the technical content over time-to-market. You can argue this point, of course, but as a user you can be assured that if you announce CDIF conformance as a strategic direction to your tool suppliers that you get something which will be up to the job.

 

Why are there so many "meta"s when you are talking about CDIF? Can't you talk like normal people?

Apparently not. Sorry about that: that's the drawback of being quite precise in what we are doing. For example, we usually are not mixing meta-levels without realizing it, or sort of document what some warm and fuzzy thing could potentially mean under some circumstances. This, unfortuantely, means that we sometimes state things like:
The meta-meta-attribute IsOptional on meta-attribute IsOptional, which is a local meta-attribute of meta-entity Attribute states that the optionality of the Attribute in a model does not have to be specified in a transfer (for example, in order to support incomplete models).
What it means is that we have a concept that could be found in a CASE tool, here an Attribute (as in Attribute of a Class, or an Entity etc.). Because it is a concept, it is modeled in the CDIF Integrated Meta-model as a meta-entity.
Meta-entities can have meta-attributes. Meta-attributes describe additional information about concepts. For example, there is another meta-attribute, Name, on Attribute, which states the name of the Attribute (such as "CustomerNumber"). Now meta-attributes can be optional, in fact, most are. This means that in a CDIF transfer there might or might not be a value specified for a meta-attribute. For example, we support unnamed Attributes by making meta-attribute Name optional.
Meta-meta-attributes specify information about meta-objects such as meta-attributes. The meta-meta-attribute IsOptional specifies whether a meta-attribute is optional, in the example the optionality of a meta-attribute called IsOptional.
Confusing, isn't it. But I guess you understand now that you are better sure you know whether you are talking about meta-attribute IsOptional, or meta-meta-attribute IsOptional, or even Attribute IsOptional: sometimes is only about the meta-model, some other time it is about what a CDIF importer may expect in a transfer (IsOptional=False would mean that it can trust there will always be a value), or finally it might be within the customer's model.

 

Well, but I have seen meta-models from other people who used fewer "meta"s.

Oh yes, we too. As long as you don't use a meta-model for something which really has to work (such as a transfer of information between CASE tools) you will get away without. When you try to actually create software from it (CDIF is essentially a spec for software, rather than a theoretic discurse about the properties of models), there is no other way than precision. Remember, CDIF allows semantic interoperability between tools that do not know about each other, only that both agree to conform to CDIF.

Did not find an answer to your question? Ask! We'll include the questions on this page if it is of interest to the general public.

Last modified: 97-05-09 by CDIF Webmaster.Copyright (C) 1997 EIA/CDIF. All rights reserved.
CDIF is a registered trademark of the Electronic Industries Association. All other trademarks are trademarks of their respective owners.