Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
CAN/CSA-ISO/IEC 15476-2:04 (IEC 15476-2-04) — The CDIF Framework for Modeling and Extensibility
A Technical Guide to the Meta-Metamodel Architecture for CASE Tool Data Interchange
The CAN/CSA-ISO/IEC 15476-2:04 standard, technically identical to ISO/IEC 15476-2:2005 (often referenced as IEC 15476-2-04), defines the foundational modeling and extensibility framework for the CDIF (CASE Data Interchange Format) family of standards. This standard is critical for ensuring robust interoperability between software engineering tools by establishing a strict, four-layer metamodeling hierarchy. Published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), and adopted by the Canadian Standards Association (CSA) for national procurement, it provides the semantic blueprint for all CDIF-based data exchanges.
Scope and Purpose of the Standard
The scope of CAN/CSA-ISO/IEC 15476-2:04 is to define the CDIF Framework for Modeling and Extensibility. It specifies the overall architectural rules for data interchange between CASE (Computer-Aided Software Engineering) tools. Rather than defining specific models, this part establishes the meta-metamodel (the language for defining modeling languages) and the extensibility mechanisms that allow the CDIF family to evolve and accommodate new domains, notations, and vendor-specific features without sacrificing interoperability.
This part of the standard is primarily intended for tool vendors and integrators who need to transfer complex structured models—such as entity-relationship diagrams, data flow diagrams, or state transition diagrams—between tools designed by different manufacturers. By conforming to the rules in Part 2, implementers ensure that the semantics, not just the syntax, of the model are preserved during transmission.
Technical Requirements and Architectural Layers
The core technical requirement of ISO/IEC 15476-2 is the strict adherence to a four-layered metamodeling architecture. This framework ensures that any data interchange is semantically unambiguous. The standard mandates that all CDIF data must map cleanly across these layers.
The Four Modeling Layers
| Layer | Designation | Definition and Role |
|---|---|---|
| M3 | Meta-Metamodel | The core language used to define the CDIF Metamodel. Includes constructs like MetaEntity, MetaRelationship, and MetaAttribute. This layer is fixed by the standard. |
| M2 | CDIF Metamodel | Defines the specific modeling notations (subject areas) such as ER, DFD, State/Event, and Data Modeling. It is an instance of the M3 layer. |
| M1 | User Model | The actual project-specific model created by a user or CASE tool (e.g., a specific library catalog system model). It is an instance of the M2 CDIF Metamodel. |
| M0 | Data / Instances | The real-world objects or executing software components described by the M1 model. This layer is outside the scope of the CDIF interchange but is the ultimate target of the modeling activity. |
Architectural Benefit: The strict M3-to-M0 separation of concerns prevents conceptual confusion. A tool exporting a model does not need to know the receiving tool’s internal data structures. It only needs to map its internal representation to the correct M2 Subject Area defined in the CDIF family.
Extensibility and Compliance Rules
Part 2 specifies two main types of extensibility:
- Subject Area Extensions: Adding new meta-entities and meta-relationships to an existing Subject Area.
- Attribute Extensions: Adding new attributes to existing meta-entities.
All extensions must be derived from the M3 meta-metamodel constructs. They must be explicitly declared in the transmission header (defined in Part 3) so that a receiving tool can distinguish between standard and proprietary content.
Implementation Highlights
Implementing a CDIF-compliant tool based on Part 2 requires careful attention to the mapping between the tool’s internal metamodel and the CDIF Integrated Metamodel (IMM).
Mapping to Transmission Formats
The architectural rules in Part 2 are tightly coupled with the CDIF Transmission Format defined in ISO/IEC 15476-3. Each construct at the M2 layer is serialized into specific tokens and records in the CDIF flat file. The MetaEntity becomes an entity record, and its MetaAttributes become attribute records. Part 2 provides the detailed semantics governing how these records must be structured.
Implementation Tip: Ensure your CDIF export engine correctly maps M2 MetaEntity names to their corresponding transmission tokens defined in Part 3. A mismatch in the header identification of Subject Areas is a frequent source of interchange failure.
Critical Constraint: The “Strict Layer Rule” must be observed. An instance of a layer can only be defined strictly using constructs from the layer immediately above it. Violating this rule (e.g., defining an M1 model directly in terms of M3 constructs) invalidates conformance and can lead to unrecoverable parsing errors in the receiving tool.
Legacy Relevance and Modern Application
Modern Model-Driven Architecture (MDA) standards like MOF (Meta Object Facility) and XMI (XML Metadata Interchange) draw heavily from the concepts formalized in ISO/IEC 15476-2. Understanding the CDIF framework is essential for professionals engaged in:
- Migrating legacy CASE tool repositories to modern UML or domain-specific platforms.
- Developing custom model transformation and bridge engines.
- Architecting Domain-Specific Languages (DSLs) with strict semantic foundations.
Compliance and Certification Notes
Conformance to CAN/CSA-ISO/IEC 15476-2:04 is a mandatory prerequisite for claiming overall CDIF compliance. The standard defines two primary levels of compliance:
- Strict Conformance: The tool supports the entire M3 Meta-Metamodel and all referenced M2 Subject Areas without proprietary modifications. The export must be a complete and valid instance of the CDIF IMM.
- Basic Conformance (with Extensions): The tool supports the M3 core constructs required for its specific Subject Areas and may include proprietary extensions. These extensions must be clearly flagged in the transmission format header per the rules in Part 2.
Compliance Pitfall: Semantic Drift. Common failures occur when tools map similar concepts (e.g., a database “Table”) to the wrong M2 meta-entity (e.g., an Entity versus a Data Process). Strict adherence to the semantic mapping rules in the standard is required for certification.
Under the Canadian adoption (CAN/CSA), this standard forms the basis for compliance in public sector software procurement in Canada. Vendors seeking contracts with the Government of Canada must demonstrate that their interchange mechanisms conform to this edition of the standard.
Typical Compliance Validation Workflow
1. Validate the M3 hierarchy in the CDIF transmission header.
2. Check proprietary extensions against the M3 meta-metamodel rules.
3. Verify that M1 model instances strictly conform to the constraints of the chosen M2 Subject Areas.
4. Ensure that no syntactic or semantic ambiguities exist in the exported CDIF transmission file.
5. Validate that the receiving tool correctly preserves any uninterpreted extensions during re-export.
Frequently Asked Questions
Q: What is the primary function of CAN/CSA-ISO/IEC 15476-2:04?
A: It defines the CDIF framework for modeling and extensibility. It establishes the four-layer metamodel architecture (M3, M2, M1, M0) that ensures semantic consistency when exchanging models between different CASE tools.
A: It defines the CDIF framework for modeling and extensibility. It establishes the four-layer metamodel architecture (M3, M2, M1, M0) that ensures semantic consistency when exchanging models between different CASE tools.
Q: Is the CDIF standard in ISO/IEC 15476 still relevant for modern software engineering?
A: While largely superseded by OMG standards like XMI and MOF for general use, the concepts of strict metamodeling layers and extensibility defined in Part 2 are foundational to MDA and DSL design. The standard remains highly relevant for organizations migrating legacy tool data.
A: While largely superseded by OMG standards like XMI and MOF for general use, the concepts of strict metamodeling layers and extensibility defined in Part 2 are foundational to MDA and DSL design. The standard remains highly relevant for organizations migrating legacy tool data.
Q: How are proprietary tool extensions handled under this standard?
A: Extensions are permitted if they conform to the M3 Meta-Metamodel. They must be clearly declared in the transmission format header. A receiving tool is not required to interpret the extension but must preserve it to ensure data integrity during re-export.
A: Extensions are permitted if they conform to the M3 Meta-Metamodel. They must be clearly declared in the transmission format header. A receiving tool is not required to interpret the extension but must preserve it to ensure data integrity during re-export.
Q: How does the Canadian adoption (CAN/CSA) differ from the international ISO/IEC version?
A: The CAN/CSA-ISO/IEC 15476-2:04 is an identical adoption of ISO/IEC 15476-2:2005. There are no technical changes or deviations. The adoption ensures the standard is officially recognized in the Canadian regulatory framework for information technology procurement.
A: The CAN/CSA-ISO/IEC 15476-2:04 is an identical adoption of ISO/IEC 15476-2:2005. There are no technical changes or deviations. The adoption ensures the standard is officially recognized in the Canadian regulatory framework for information technology procurement.
—
Technical Documentation prepared for the International Standards Reference Library. © 2026. All standard designations remain the property of their respective issuing bodies (ISO, IEC, CSA Group).