Stream-based Model Interchange Format Version 1.0 beta Initial CDIF Partners Submission From: ftp://ftp.omg.org/pub/docs/ad/98-07-09.txt Date: 1998-08-22 --------------------------- Stream-based Model Interchange Format Version 1.0 beta Initial CDIF Partners Submission Fujitsu Softeam With collaboration and support from: Ardent Software Aviatis Boeing ICONIX Integrated Systems Verilog OMG PTC Document ad/98-07-09 In Response to OMG RFP - ad/97-12-03 July 6, 1998 Copyright 1998 Ardent Software Copyright 1998 Aviatis Copyright 1998 Boeing Copyright 1998 Fujitsu Copyright 1998 ICONIX Copyright 1998 Integrated Systems Copyright 1998 Softeam Copyright 1998 Verilog This document contains information protected by copyright. All Rights Reserved. Excepts as otherwise provided herein, no part of this work may be reproduced or used in any form or by any means - graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the permission of one of the copyright owners. All copies of this document must include the copyright and other information contained on this page. The companies listed above hereby grant to the Object Management Group, and Object Management Group members, permission to copy this document for the purpose of evaluating the technology contained herein during the Object Analysis and Design Task Force technology selection process for a Stream-based Model Interchange Format. Distribution to anyone not a member of the Object Management Group or for any purpose other than technology evaluation is prohibited. The material in this document is submitted to the OMG for evaluation. Submission of this document does not represent a commitment to implement any portion of this specification in the products of the submitters. WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULARAT PURPOSE. The companies listed above shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material. The information contained in this document is subject to change without notice. This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the document if one is published. The companies listed above may make improvements and /or changes in the product(s) and or the program(s) described in this document at any time. RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c)(1)(ii) of the Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013. OMG is a trademark of the Object Management Group. CDIF is a trademark of the Electronic Industries Association. Table of Contents Part I – Overview 5 1 General Information 5 1.1 Copyright Waiver 5 1.2 Submission contact points 5 1.3 Overview to the Submission 5 1.4 References 6 2 Design Rationale 7 2.1 Proof of Concept 7 2.2 Mandatory Requirements 7 2.3 Optional Requirements 9 2.4 RFP Issues to be Discussed 11 2.5 RFP Evaluation Criteria 12 Part II – Proposed Specification 13 3 General 13 3.1 Compliance Points 13 3.2 Terminology 13 4 SMIF Transfer Format Specifications 13 4.1 General Rules for Syntaxes and Encodings Specification 13 4.2 SYNTAX.1 Specification 14 4.3 ENCODING.1 Specification 14 4.4 EIA CDIF Upward Compatibility Specification 14 5 CDIF Model Interchange Example 14 5.1 Data Models and Data Definitions Subject Area Example 14 6 SMIF Architecture Specification 15 6.1 MOF Static Kernel 15 6.2 Extensibility 16 6.3 Clarification of what is in the MOF Static Kernel: 16 6.4 Isomorphic Transformation of MOF Static Kernel to CDIF 17 6.5 Permanent Meta-identifiers Specification 19 7 UML Model Interchange Format Specification 21 7.1 UML to CDIF Mapping 21 7.2 UML Extensibility Specification 21 7.3 UML Data Types Specification 26 7.4 UML Model Interchange Example 28 8 MOF Metamodel Interchange Format Specification 28 8.1 MOF to CDIF mapping 28 9 Part III – Conformance 29 9.1 Summary of Optional versus Mandatory Interfaces 29 9.2 Compliance Points 29 9.3 Changes or extensions required to adopted OMG specifications 29 9.4 Complete IDL definitions 30 Appendix A: UML Core Package Mapping to SMIF Architecture 31 Appendix B: CDIF Data Models and Data Definitions Interchange Example 35 Data Model: 35 Data Type Definitions: 35 CDIF Transfer: 36 Part I – Overview 1 General Information 1.1 Copyright Waiver The copyright owners grant member companies of the Object Management Group (OMG) permission to make a limited number of copies of this document (up to fifty copies) for their internal use as part of the OMG evaluation process. 1.2 Submission contact points Company Contact E-mail Ardent Software Charles (cq) Rehberg cq.rehberg@ardentsoftware.com Aviatis Johannes Ernst jernst@aviatis.com Boeing Woody Pidcock woody.pidcock@boeing.com Fujitsu Jun Ginbayashi gin@tokyo.se.fujitsu.co.jp ICONIX Doug Rosenberg doug@iconixsw.com Integrated Systems Chandra Prasad cprasad@isi.com Softeam Phillipe DesFray phd@softeam.fr Verilog Rodolphe Arthaud arthaud@tlse.verilog.fr 1.3 Overview to the Submission This submission includes the CDIF Transfer Format technology well-known in the industry for model interchange of structured analysis and design models. This technology has undergone two revisions since it was first published as an interim standard by the Electronic Industries Association (EIA) in 1991. It was updated and republished by EIA in 1994 and has now passed its Final Committee Draft (FCD) ballots as ISO/IEC CDIF International Standards. It is this ISO/IEC CDIF Transfer Format technology that is included in this submission. There is additional technology (beyond what is specified in the ISO/IEC CDIF Transfer Format standards) included in this submission to meet all the requirements of the OMG Stream-based Model Interchange Format (SMIF) RFP. Additional technology included in this submission address the following requirements: ? Assignment of permanent meta-identifiers to metamodel elements that are not in the CDIF Semantic Meta-model ? Support for the UML stereotype, contraint and tagged values extensibility mechanisms ? Rules for isomorphic transformation of the MOF static kernel into the SMIF Architecture Work done as part of the ISO/IEC JTC1 International Study Period on the Mapping of Modelling Languages for Analysis and Design (references 9 and 10) provide information for discussion on how to map STEP Express models into the SMIF Arcitecture. Although the SMIF Specification included in this submission is labeled version 1.0 beta for OMG purposes, it is mature and stable technology that has been evolving in the marketplace for 8 years. 1.4 References 1.4.1 OMG References 1. OMG ad/97-08-14, Meta-Object Facility Specification 2. OMG ad/97-08-04, UML Semantics Specification 3. OMG ad/97-12-03, Stream-based Model Interchange Format RFP 1.4.2 ISO/IEC JTC1 SC7 References 4. FCD 15474-2, Software Engineering - CDIF Framework - Part 2: Modelling and Extensibility. This document is available from the OMG File Server as cdif/98-06-03. 5. FCD 15475-1, Software Engineering - CDIF Transfer Format - Part 1: General Rules for Syntaxes and Encodings. This document is available from the OMG File Server as cdif/98-06-04. 6. FCD 15475-2, Software Engineering - CDIF Transfer Format - Part 2: Syntax SYNTAX.1. This document is available from the OMG File Server as cdif/98-06-05. 7. FCD 15475-3, Software Engineering - CDIF Transfer Format - Part 3: Encoding ENCODING.1. This document is available from the OMG File Server as cdif/98-06-06. 8. FCD 15476-1, Software Engineering - CDIF Semantic Metamodel - Part 1: Foundation. This document is available from the OMG File Server as cdif/98-06-07. 9. ISO/IEC JTC1 SC7 WG11 JOH-051, Interim Study Period Report on Mapping Modeling Languages. 10. ISO/IEC JTC1 SC7/WG11 JOH-052, Bridging UML and STEP/EXPRESS with CDIF – Achieving Interoperability of Object and Product Data Models 1.4.3 EIA CDIF References 11. EIA/IS-734, CDIF Transfer Format – OMG IDL Bindings. This document is available from the OMG File Server as cdif/98-06-11. 1.4.4 ISO TC184 STEP References 12. ISO 10303-11:1994 "Industrial automation systems and integration – Product data representation and exchange - Part 11: Description methods; the EXPRESS language reference manual" 13. ISO/TR 10303-12:1997 "Industrial automation systems and integration – Product data representation and exchange - Part 12: Description method: The EXPRESS-I language reference manual" 14. ISO 10303-21:1994 "Industrial automation systems and integration – Product data representation and exchange - Part 21: Implementation methods: Clear text encoding of the exchange structure" 15. ISO/DIS 10303-22 "Industrial automation systems and integration - Product data representation and exchange - Part 22: Implementation method: Standard data access interface specification" 2 Design Rationale Leveraging an existing industrial strength stream-based model interchange format developed for the structured analysis and design modeling tool market allows the OMG to focus on the delta requirements for object-oriented model interchange rather than reinventing the wheel. 2.1 Proof of Concept The EIA CDIF91 and EIA CDIF94 versions of the CDIF Transfer Format technology have been previously implemented commercially for INTERSOLV Excelerator, Oracle Designer/2000, and Platinum Paradigm Plus, among others. As part of a Japanese Software Computer Assisted Logistics Support (CALS) Experiment, the feasibility of using CDIF Transfer Format technology for model interchange was demonstrated for the following tools: Fujitsu AA/BRMODELLER, Hitachi SEWB3, Nihon Unisys StP/SE, and NTT Software MagicCASE. Lessons learned from this industry experiment provided feedback to the CDIF international standardization activity in ISO/IEC JTC1 SC7 WG11. Commercial implementations of the ISO/IEC CDIF Transfer Format technology will be available within one year of adoption as an OMG standard. 2.2 Mandatory Requirements 2.2.1 Proposals shall use the MOF as its meta-metamodel The static kernel of the MOF meta-metamodel shall be used for specification of the meta- entities, meta-relationships and meta-attributes of all meta-models and meta-model extensions in a SMIF transfer. This core subset of the MOF meta-metamodel shall be mapped to the CDIF meta-metamodel using the technology specified in reference 9. 2.2.2 Proposals shall provide a complete specification of the syntax and encoding needed to export/import models and meta-model extensions included in-line as part of the transfer stream. This syntax and encoding shall have an unambiguous identification to support evolution of this technology The ISO/IEC CDIF Transfer Format technology as specified in references 6 and 7 provide a complete specification of the syntax and encoding for export/import of models and meta- model extensions included in-line as part of a SMIF transfer stream. This ISO/IEC CDIF Transfer Format technology will bes identified with version number 1999.01. Previous versions of the EIA CDIF Transfer Format technology were identified with version numbers 1.00 in 1991 and 2.00 in 1994. 2.2.3 Proposals shall provide a means for unambiguous identification of any concept specified in a MOF-compliant metamodel that is referenced (but the specification is not included) in a transfer stream The meta-model section of a SMIF transfer stream provides a means for unambiguous identification of published MOF compliant metamodel specifications by Subject Area reference and Version number. These MOF-compliant metamodels shall be transformed into the CDIF Framework for Modelling and Extensibility using the technology in reference 9. This transformation provides a permanent (unambiguous) SMIF meta-identifier for each concept in a MOF-compliant metamodel. For UML, UML is the Subject Area Name and 1997.01 is the Version Number for OMG UML Version 1.0. The proposed permanent SMIF meta-identifiers for a subset of the OMG UML 1.0 concepts are listed in Appendix A. These are subject to change and should be determined by the OMG UML Revision Task Force and approved by the OMG Architecture Board to guarantee industry-wide interoperability. 2.2.4 Proposals shall demonstrate support for import/export of UML models and the UML metamodel. This demonstration shall include demonstration of a round-trip model exchange without information loss. Submissions will be evaluated regarding the extent of the UML metamodel subset (including any MOF-compliant extensions) covered by the submitter’s choice of examples This initial response does not contain a UML-specific example. The revised submission, after collaboration with other initial submissions to this RFP, will contain a complete set of UML examples. The syntax and encoding will look exactly like what is shown in the CDIF example in Appendix B. 2.2.5 Proposals shall support use of international standard codesets The ISO/IEC CDIF Transfer Format technology supports use of international standard codesets and any other codesets identified by the exporter. For example, Japanese multibyte codesets are supported. 2.3 Optional Requirements 2.3.1 The interchange of metamodels may require a compact data representation in addition to the text-based representation as an alternative to the interface-based representation defined in the MOF The SMIF specification in this submission is text-based. This submission specifies using ZIP compression of a SMIF transfer stream to provide a compact data representation. 2.3.2 Proposals may be upward-compatible with the EIA/CDIF 1994 Transfer Format standards The ISO/IEC CDIF Transfer Format standards are upward-compatible from the EIA CDIF 1994 Transfer Format standards (CDIF94). 2.3.3 The SMIF specification may contain constructs unsupported by CDIF94 This SMIF specification makes a distinction between meta-objects defined in a Subject Area and meta-objects referenced in a Subject Area, which CDIF94 combined into one concept of being used in a Subject Area. This SMIF specification supports model interchange using multibyte codesets, which is unsupported by CDIF94. This SMIF specification supports interchange of models using subject area references to meta-models that have not been published as CDIF Subject Area standards, which is unsupported by CDIF94. 2.3.4 Proposals may contain an unambiguous, complete mapping of the concepts in the CDIF94 meta-meta-model to the concepts in the MOF This submission contains an unambiguous, complete mapping (correspondence) between the ISO/IEC CDIF meta-meta-model and the MOF meta-meta-model using the mapping rules in reference 9. Since the ISO/IEC CDIF meta-meta-model is an upward compatible superset of CDIF94 concepts, the CDIF94 meta-meta-model does not need a separate mapping. 2.3.5 Proposals may identify the impact of the proposed SMIF specification on transfer files produced using the CDIF94 Transfer Format standards There is no impact on CDIF94 compliant transfer files. Importers that can read ISO/IEC CDIF Transfer Format compliant transfer files will be able to read CDIF94 complaint transfer files. 2.3.6 This requirement may be met by providing a specification for a conversion utility for transfer files created using the CDIF94 Transfer Format standards to make them compliant with the proposed SMIF specification No transfer format conversion utility is necessary. However, If the meta-objects in CDIF subject area standards for CDIF94 compliant transfer files have been assigned separate (redundant) OMG permanent meta-identifiers, then a conversion table for these equivalent permanent meta-identifiers will need to be published. 2.3.7 Proposals may provide transfer stream examples that use concepts from other industry standard metamodels In Appendix B, this submission includes a small example using the ISO CDIF Data Models and Data Definitions Subject Areas, which are part of the ISO/IEC CDIF Semantic Meta- model standards. 2.3.8 Proposals may identify specific modeling language differences between EXPRESS and the MOF/UML and discuss ways to map between these languages A direct mapping may not be possible. Reference 10 uses the ISO/IEC CDIF Framework – Part 2: Modelling and Extensibility to identify modeling language similarities and differences between STEP EXPRESS and OMG MOF/UML. It suggests a direction for future OMG RFPs to take to address these differences. 2.3.9 Proposals may identify the impact of the proposed SMIF specification on existing schema definitions and transfer files produced using STEP EXPRESS This submission does not recommend using CDIF Transfer Format technology for model interchange of STEP EXPRESS schemas until significant technical issues related to the mapping between these modeling languages are resolved. Refer to reference 10 for more information. 2.3.10 This may include identification of any changes to STEP EXPRESS files required to produce valid syntax and encoding per the proposed SMIF specification This submission does not recommend using CDIF Transfer Format technology for model interchange of STEP EXPRESS schemas until significant technical issues related to the mapping between these modeling languages are resolved. Refer to reference 10 for more information. 2.3.11 Submissions may include a specification for converting STEP schemas and/or transfer files created using STEP EXPRESS standards to make them compliant with the proposed SMIF specification See references 9 and 10 for some preliminary guidelines for performing such a conversion. 2.4 RFP Issues to be Discussed 2.4.1 Usage and relevance of related technologies such as Meta-Object Definition Language (MODL), Object Constraint Language (OCL) and Universal Object Language (UOL) The MODL can be mapped to the SMIF Architecture (MOF Static Kernel) using the mapping guidelines in reference 9. If such a mapping is produced, then models represented using MODL can be imported by tools that are SMIF compliant. OCL is one of the specification languages that may be used to encode expressions in a SMIF Transfer stream. UOL is a transfer format for homogeneous interchange of UML models. For heterogeneous interchange of models that use extensions or alternatives to UML, use of the SMIF transfer format specification is necessary. 2.4.2 XML and CDIF Use Cases There are three basic use cases for SMIF transfer streams: ? model interchange within a virtual team separated by space, ? model interchange between projects separated by time and space, and ? model interchange of vendor specific extensions. XML is well suited for the first case. CDIF is well suited for the 2nd and 3rd use cases. To use XML to satisfy these last two use cases, mature and stable architectural specifications need to be provided. Importers need to understand the SMIF transfer stream contents without relying on side agreements with the exporter. The Extended Markup Language (XML) technology is a very desirable option for model interchange in a controlled context. Project agreement on a Document Type Definition (DTD) for a meta-model facilitates high-fidelity model interchange for the project. However, this approach is labor intensive to maintain across projects and is error prone when the DTD is separated from the transfer stream and is updated over time. For a copy of version 3 of the draft EIA CDIF -- XML-based Transfer Format visit the CDIF Website: http://www.cdif.org. 2.4.3 Support for semantic interoperability between tools that share and manipulate STEP schemas and STEP schema instances in addition to tools that support sharing and manipulation of OAD models Semantic overlap exists between OAD meta-models and models and STEP schemas and schema instances. Additional research on a semantic integration framework and development of automated and manual mapping rules between these models and schemas is necessary before semantic interoperability can be achieved. A beginning discussion on these interoperability issues can be found in reference 10. 2.5 RFP Evaluation Criteria 2.5.1 The specification of the syntax and encoding should be in BNF notation This is included in the normative part of the ISO/IEC CDIF Transfer Format standards. 2.5.2 The proposal should be robust and stable The CDIF Transfer Format technology had minor changes between CDIF91 and CDIF94. Almost all of the changes were in the meta-model section to make it consistent with the model section. There was almost no change from CDIF94 to ISO/IEC CDIF other than support for international codesets and metamodels specified independent of the CDIF Semantic Meta-model standards. 2.5.3 The interchange format should be independent of the semantic constructs in a meta-model. This means, for example, that extending the UML meta- model should not require any changes to this model interchange format The CDIF Transfer Format technology has been based on the top layer of the four layers of abstraction in the MOF Architecture ever since CDIF91. This guarantees transfer format independence from specific metamodel semantics. 2.5.4 Proposals should specify a syntax and encoding that is LL(1) parsable This was thoroughly tested and proven for the EIA CDIF94 Transfer Format standards. Part II – Proposed Specification 3 General 3.1 Compliance Points There are two compliance points for this specification: ? A MOF static kernel compliance point for interchange of models based on industry standard metamodels like UML. This is for tool to tool interoperability. ? A full MOF dynamic compliance point for interchange of metamodels based on the full MOF meta-metamodel. This submission transforms the full MOF meta-metamodel into its own Subject Area metamodel, so that complete definition and behavior of metamodels based on this MOF Subject Area can be interchanged in the Model Section of a SMIF transfer stream. This is for repository to repository interoperability. 3.2 Terminology This SMIF specification uses the terms “meta-entity“, “meta-relationship”, and “meta- attribute” to refer to meta-objects in the SMIF Transfer Format that are transformations of MOF (meta)classes, (meta)associations, and (meta)attributes. The SMIF specification uses the prefix (meta) to refer to model elements in the UML metamodel specification and the prefix (metameta) to refer to model elements in the MOF meta-metamodel specification. 4 SMIF Transfer Format Specifications The following sections formally specify the CDIF Transfer Format technology (international standards) included by reference in this SMIF specification. The 1.0 beta release of the SMIF specification is not XML based. Coordination with other submitters to the SMIF RFP will produce an XML based transfer format option for the next release of this SMIF specification. 4.1 General Rules for Syntaxes and Encodings Specification The following international standard specifies the header section for a SMIF transfer stream. The header section of SMIF transfer streams shall conform to IS 15475-1, Software Engineering -- CDIF Transfer Format – Part 1: General rules for Syntaxes and Encodings (Reference 5). 4.2 SYNTAX.1 Specification The following international standard specifies the abstract syntax for a SMIF transfer stream. The abstract syntax of SMIF transfer streams shall conform to IS 15475-2, Software Engineering -- CDIF Transfer Format – Part 2: Syntax SYNTAX.1 (Reference 6). 4.3 ENCODING.1 Specification The following international standard specifies the concrete encoding for a SMIF transfer stream. The concrete encoding of SMIF transfer streams shall conform to IS 15475-3, Software Engineering -- CDIF Transfer Format – Part 3: Encoding ENCODING.1 (Reference 7). 4.4 EIA CDIF Upward Compatibility Specification Importers of SMIF transfer streams shall provide support for CDIF Meta-identifiers as defined in EIA CDIF Integrated Meta-model standards. These CDIF permanent meta- identifiers (unchanged) also are defined in the ISO/IEC FCD CDIF Semantic Meta-model standards. 5 CDIF Model Interchange Example 5.1 Data Models and Data Definitions Subject Area Example This example is provided as Appendix B. It is based on industry trials of the CDIF Transfer Format technology performed for the Japanese Software CALS initiative. 6 SMIF Architecture Specification 6.1 MOF Static Kernel The SMIF Architecture shall be isomorphic to the MOF static kernel, which is a proper subset of the MOF meta-metamodel specified in reference 1. The contents of the MOF static kernel are shown in Figure 1. Figure 1 MOF Static Kernel All model elements that are instances of metamodel elements defined using the MOF static kernel can be interchanged using the SMIF. This includes UML-compliant models and MOF-compliant (meta)models. MOF-compliant (meta)models are interchanged as models using the MOF (metameta)Model as a meta-model in the SMIF Architecture. Specification of the MOF (metameta)model as a meta-model can be done using the MOF static kernel. The full MOF semantics are defined for the MOF and UML in their respective specifications (see references 1 and 2) but the additional semantics that are not part of the MOF static kernel are not used during model interchange. 6.2 Extensibility The SMIF Architecture shall support limited metamodel extensions for adding new (meta)Classes, (meta)Associations, (meta)Attributes, and extending the domain of previously specified enumerated (meta)Attributes. It shall also support the UML extensibility mechanisms as described in section 7.2 of this specification. To specify the full set of MOF semantics for a new metamodel or metamodel extension, the MOF shall be referenced as a SUBJECTAREA REFERENCE in the Metamodel section of a SMIF Transfer and the new or extended metamodel shall be specified in the Model section. After an importer has received the robust specification for the new or extended metamodel, this metamodel shall be a SUBJECTAREA REFERENCE rather than an inline extension in the Metamodel section for another SMIF Transfer. This two step process allows the full MOF semantics to be used for specifying metamodel definitions and extensions. 6.3 Clarification of what is in the MOF Static Kernel: ? The Contains (metameta)Association is shown explicitly between subtypes of ModelElement to clarify which containment associations are in the MOF static kernel and what their more restricted multiplicities are in the MOF static kernel. ? Several of the abstract supertype MOF model elements (Namespace, GeneralizableElement, Feature, StructuralFeature, and TypedElement) are not included to simplify the structure of the MOF static kernel. ? The Generalizes (metameta)Association has been put on Classifier because the limited metamodel extensibility supported inline in a SMIF Transfer does not allow specification of Package instance subtyping. ? The IsDerived (metameta)Attribute is not included for MofAttribute and Association because the limited metamodel extensibility supported inline in a SMIF Transfer does not allow specification of derived MofAttribute and Association instances. The exporter will export model elements that are derived from other model elements and enforce derivation rules specified in the metamodel regardless of the value of the IsDerived (metameta)Attribute. ? The Tag (metameta)model element in the MOF cannot be used as an extensibility mechanism during model interchange. It is supported for metamodel interchange the same way as the UML TaggedValue is supported for model interchange as described in section 7.2 of this specification. However, please note that using Tag to extend the full MOF meta-metamodel for metamodel interchange may not have any practical uses. 6.4 Isomorphic Transformation of MOF Static Kernel to CDIF The SMIF Architecture specifies an isomorphic transformation of the MOF static kernel model elements into CDIF Meta-meta-model elements. 6.4.1 Name Changes The transformations that are simply a name change are listed in Table 1. Table 1 MOF Static Kernel to CDIF Name Equivalence MOF Static Kernel Elements CDIF Meta-meta-model Elements (metameta)Classes Meta-meta-entities Package SubjectArea Class MetaEntity Association MetaRelationship MofAttribute MetaAttribute Classifier AttributableMetaObject (metameta)Associations Meta-meta-relationships Package-Contains-ModelElement CollectibleMetaObject.DefinedIn.SubjectArea Classifier-Generalizes-Classifier AttributableMetaObject.HasSubtype. AttributableMetaObject Classifier-Contains-MofAttribute MetaAtttribute.IsLocalMetaAttributeOf. AttributableMetaObject (metameta)Attributes Meta-meta-attributes Classifier.isAbstract AttributableMetaObject.IsAbstract ModelElement.name MetaObject.Name ModelElement.annotation MetaObject.Description 6.4.2 Transformation of Classes into Associatons Two (metameta)Classes transform into (metameta)Associations: ? AssociationEnd becomes two separate associations ? Import becomes a many-to-many association Transforms into: Figure 2 AssociationEnd Transformation Transforms into: Figure 3 Import Transformation 6.4.3 Transformation of Classes into Attributes Two (metameta)Classes transform into (metameta)Attributes: ? Constraint becomes an optional attribute on ModelElement ? DataType becomes a mandatory attribute on MofAttribute Transforms into: Figure 4 Constraint Transformation Transforms into: Figure 5 DataType Transformation 6.5 Permanent Meta-identifiers Specification 6.5.1 Assignment Process Because a SMIF transfer only includes a reference to the full specification of pre-defined metamodel elements, a permanent (unique, unchangeable, and non-redundant) meta- identifier for these predefined elements needs to be published for semantic interoperability between the exporter and the importer. The OMG needs to publish these permanent meta-identifiers for the meta-model specifications it publishes (e.g. UML). In some cases the qualifiedName (metameta)Attribute on ModelElement in the MOF might be used as the permanent meta- identifier for model elements in a published MOF-compliant meta-model. However, care needs to be taken to ensure that a different permanent meta-identifier is used from one revision of an OMG meta-model specification to the next for concepts that have changed in meaning but retain the same name. Similarly, care needs to be taken when only the name has changed but not the semantic meaning, to ensure that the same permanent meta- identifier is reused (otherwise interoperability is lost). For this initial SMIF specification, permanent meta-identifiers shall be assigned to each metamodel element using the following 3 step process: 1. The first character of the SMIF meta-identifier for a metamodel element shall be ‘C’ if it identifies a Class instance, ‘A’ if it identifies an Association instance, and ‘M’ if it identifies a MofAttribute instance. 2. The next set of characters in the meta-identifier shall be the name for the top level Package (also called SubjectArea in the SMIF Architecture) that contains the metamodel element. Note that the metamodel element name must be unique in the transitive closure of metamodel elements in this package. 3. The last set of characters in the meta-identifier depends on whether the metamodel element is a Class, Association or MofAttribute instance. For a Class instance, it shall be the Class name. For an Association instance, it shall be the Class name that one of the two AssociationEnd instances is a type of concatenated with the role name of the other AssociationEnd instance. The choice of which of the two association ends to use first shall be at the discretion of the exporter. It shall be the same choice as was made during the AssociationEnd transformation into HasSource and HasDestination meta- relationships. For a MofAtribute instance, it shall be the Classifier instance name as specified in this paragraph for Class and Association instances concatenated with the MofAttribute instance name beginning with a capital letter. Examples of SMIF permanent meta-identifiers assigned using this process for UML (meta)model elements is provided in Appendix A. An alternative approach is to maintain an OMG registry of computer-generated permanent meta-identifiers that are completely independent of the Namespaces in individual metamodels. 6.5.2 Controlled Redundancy Because it is not possible to guarantee non-redundant meta-identifiers in a “global” namespace without a single central registry that checks for redundancy before assignment, a controlled redundancy approach shall be implemented. Whenever two permanent meta- identifiers are discovered to be redundant identifiers for the same metamodel concept, they shall be identified as equivalent on a publicly available website set up for this purpose. Obvious examples of this kind of controlled redundancy are the MOF and UML Core concepts for Class, Association, Attribute, Package, etc. 7 UML Model Interchange Format Specification 7.1 UML to CDIF Mapping The UML metamodel is MOF static kernel compliant, which means that it is also SMIF Architecture compliant. The result of applying the transformations specified in section 6.4 and assignment of permanent meta-identifiers as specified in section 6.5 is shown in Appendix A for several of the OMG UML 1.0 packages. This Appendix is an example only. All the information is derivable from the UML specification (reference 2) and the transformation and permanent meta-identifier assignment specifications in the previous sections. The contents of all the UML packages shall be assigned unique CDIF MetaIdentifiers using the specified process. As a result, the CDIF Transfer Format technology can be used without change as a stream-based model interchange format for UML. As an aid to implementation, the following additional information has been provided in Appendix A: ? Page # in OMG UML 1.0 (UML 1.1) Semantics document where the normative specification is described; ? SubtypeOf and IsAbstract values for meta-entities, ? Min and Max source and destination multiplicities for meta-relationships; and ? IsOptional, DataType and Length values for meta-attributes. Please note that this UML to CDIF mapping is only a mechanism for assigning unique MetaIdentifiers to UML metamodel elements. It does not change the definitions of any of the UML concepts. For example, compliance to all the constraints that are specified in OMG ad/97-08-04 shall be the responsibility of the exporter and importer of UML models independent of compliance to the SMIF specification. A SMIF transfer stream does not need to contain pre-defined UML constraints; it only needs to refer the importer to the normative specification for these constraints. Extensions to the UML metamodel specified using the UML extensibility mechanisms: stereotypes, constraints, and tagged values do need to be included in a SMIF transfer stream. These are mapped to the SMIF Architecture according to the rules in the following section. 7.2 UML Extensibility Specification 7.2.1 Stereotypes Stereotypes have two cases: UML standard stereotypes and non-standard stereotypes. All currently defined UML standard stereotypes do not have any specified required tagged values or constraints. The baseClass and icon values for these standard stereotypes are pre-defined and therefore do not need to be specified again in a SMIF transfer stream. For this case, UML metaclass Stereotype can be transformed into a “virtual” CDIF enumeration meta-attribute called stereotype on ModelElement. The domain of values for this enumerated meta-attribute is the list of pre-defined standard stereotypes in UML. ModelElement instances in a SMIF transfer stream that are classified by a UML standard stereotype shall have its stereotype meta-attribute assigned the name of the stereotype to which it belongs as its value. These ModelElement instances must be instances of the base class identified for that stereotype in the UML specification. When a non-standard stereotype is added to the UML metamodel, its specification (baseClass and icon values) needs to be transferred an instance of the metaclass Stereotype. ModelElement instances classified by non-standard stereotypes shall be identified by the same “virtual” CDIF stereotype meta-attribute as was done for standard stereotypes. In the meta-model section of an SMIF transfer stream, the stereotype enumerated meta-attribute on ModelElement shall be extended to include the Stereotype.name for each non-standard stereotype. In the model section, ModelElement instances that are classified by a non-standard stereotype shall have its stereotype meta-attribute assigned the name of the stereotype to which it belongs as its value. These ModelElement instances must be instances of the base class identified for that stereotype in the Stereotype metaclass specification included in the SMIF transfer. Instances of the UML Stereotype.extendedElement.ModelElement metaassociation shall be transformed into instances of the stereotype enumerated meta-attribute on ModelElement in all cases. 7.2.2 Tagged Values The TaggedValue metaclass in UML is used to attach “pseudo” metaattributes to model elements, including non-standard stereotypes. Just as with stereotypes, there are two basic cases: UML standard tagged values and non-standard tagged values. All the currently defined UML standard instances of TaggedValue have no constraints specified for them. TaggedValue is not a subtype of Element, so its only metaattributes are tag and value. All of the standard instances except for persistence only specify standard tag names and not the values. The UML standard tag names without pre-defined values (documentation, location, responsibility, and semantics) shall be transformed into “virtual” CDIF meta-attributes on ModelElement. The tag name shall be the meta-attribute name, Text shall be the CDIF data type (equivalent to the UML uninterpreted data type), and the CDIF IsOptional flag for these meta-attributes shall be set to ‘True’. The persistence standard tag has two pre-defined standard values: transitory and persistent. It shall also be transformed into a “virtual” CDIF meta-attribute on ModelElement. Persistence shall be the meta-attribute name, Enumerated shall be its CDIF data type with {transitory, persistent} as its domain of values, and the CDIF IsOptional flag for this meta-attribute shall be set to ‘True’. The UML specification identifies the subtypes of ModelElement to which these standard tagged values apply. They do not apply to non-standard stereotypes unless the stereotype specifies a base class for which the tagged value does apply. All non-standard tagged values shall be specified as instances of TaggedValue in the model section of a SMIF transfer. A separate instance of TaggedValue shall be specified for every value associated with a tag name. There are two subcases of non-standard tagged values to consider: ModelElement tagged values and Stereotype tagged values. For non-standard ModelElement tagged values, in the meta-model section of the SMIF transfer ModelElement shall be extended to add this tag name as another “virtual” CDIF meta-attribute. For non-standard Stereotype tagged values, the baseClass of the Stereotype shall be extended to add the tag name as a “virtual” CDIF meta-attribute. The specification of this CDIF meta-attribute shall include in its Constraint field a requirement that if the stereotype meta-attribute value of a baseClass instance equals the name of the stereotype requiring the tagged value, then this CDIF meta-attribute shall be instantiated. The CDIF data type for non-standard tagged values shall be Enumerated. All the values that appear in the (tag, value) instances of TaggedValue in the model section shall be in the domain of enumeration for this CDIF meta-attribute. An exception can be made for large blobs that the exporter doesn’t want to repeat in the meta-model and model sections. For these meta-attributes, the CDIF data type shall be Text. 7.2.3 Constraints The UML constraints extensibility mechanism also has two primary cases: UML standard constraints and non-standard constraints. For UML standard constraints, there are two sub-cases: constraints on a single ModelElement instance and constraints on a set of ModelElement instances. OMG UML 1.0 specifies nine standard constraints on single instances of a ModelElement: association on LinkEnd, broadcast on Request, global on LinkEnd, implicit on Association, incomplete on Generalization, local on LinkEnd, parameter on LinkEnd, self on LinkEnd, and vote on Request. These have a predefined body in the UML specifcation. The constraint exists when the body boolean expression is true. In the model section of a SMIF transfer, a standard constraint on a single ModelElement instance shall be transformed into a “virtual” meta-attribute on the identified ModelElement subtype. A value of true shall be transferred for this meta-attribute when the constraint exists for that instance in the model. A value of false shall be transferred when the constraint does not exist for that instance. If the exporter is not sure whether or not the constraint exists for an instance, a meta-attribute value shall not exported. OMG UML 1.0 specifies four standard constraints on sets of ModelElement instances: complete on Generalization, disjoint on Generalization, or on Association, and overlapping on Generalization. These have a predefined body in the UML specifcation. They are specified as natural language boolean expressions. An OCL representation is not required because the constraint body is not being transferred. The importer may provide a computable representation of these standard constraints, since they are pre-defined in the UML specification. In the model section of a SMIF transfer, a standard constraint on a set of ModelElement instances shall be transformed into a “virtual” meta-entity connected by a “virtual” meta- relationship to the appropriate ModelElement subtype as indicated in Figure 6. Figure 6 UML Constraints on Sets of Instances In the model section of a SMIF transfer, separate instances of these virtual meta-entities shall be specified for each standard constraint on a set of ModelElement instances. Instances of these meta-entities shall be distinguished from each other within a SMIF transfer by their CDIFIdentifier meta-attribute values. They are linked to instances of ModelElement subtypes by instances of the meta-relationship: .constrains. For non-standard constraints, there are three subcases: constraints on a single ModelElement instance, constraints on a set of ModelElement subtype instances, and constraints on instances of two or more different ModelElement subtypes. For all three cases, an instance of Constraint shall be specified in the model section of a SMIF transfer. The body text as a boolean expression in the body language of choice shall be specified for the non-standard constraint. If it is not specified in a computable language, the importer will not know the meaning of the constraint. For a non-standard constraint on a single instance, the ModelElement subtype shall have a new meta-attribute specified in the meta-model section of a SMIF transfer. This meta- attribute shall be of a boolean data type and shall be optional. In the model section of a SMIF transfer, a value of true shall be transferred for this meta-attribute when the constraint exists for an instance of the ModelElement subtype in the model. A value of false shall be transferred when the constraint does not exist for that instance. If the exporter is not sure whether or not the constraint exists for an instance, a meta-attribute value shall not exported. For a non-standard constraint on a set of ModelElement subtypye instances, a new meta- entity connected by a new meta-relationship to the appropriate ModelElement subtype shall be specified in the meta-model section of a SMIF transfer. The new meta-entity shall have the name of the constraint meta-attribute on the Constraint instance as its meta-entity name. ConstraintExpression and ConstraintLanguage shall be its only local meta- attributes. The name of the new meta-relationship shall be ‘Constrains’ and have the same multiplicities as the standard constraints in Figure 6. In the model section of a SMIF transfer, instances of this new meta-entity and meta-relationship shall be transferred when the constraint exists for a set of ModelElement subtype instances. Nothing shall be transferred when the constraint does not exist. For a non-standard constraint on instances of two or more different ModelElement subtypes, a new meta-entity connected by new meta-relationships to the appropriate ModelElement subtypes shall be specified in the meta-model section of a SMIF transfer. The new meta-entity shall have the name of the constraint meta-attribute on the Constraint instance as its meta-entity name. ConstraintExpression and ConstraintLanguage shall be its only local meta-attributes. The name of the new meta-relationships shall be ‘Constrains’ and have the same multiplicities as the standard constraints in Figure 6. There will be multiple new ‘Constrains’ meta-relationships attached to the new meta-entity as their source meta-entity. In the model section of a SMIF transfer, instances of this new meta- entity and meta-relationship shall be transferred when the constraint exists for a set of ModelElement subtype instances. Nothing shall be transferred when the constraint does not exist. 7.3 UML Data Types Specification For defining the UML standard meta-model and meta-model extensions, UML provides three categories of data types: Primitive, Enumeration, and Structure. UML has four <> data types plus the boolean <> data type that correspond directly to CDIF primitive data types for defining metamodels and metamodel extensions. The following table shows this correspondence: Table 2 Primitive Data Types UML Data Types CDIF Data Types <> Integer Integer <> String String <> Time Time <> Uninterpreted Text <> Boolean Boolean The UML String data type does not currently have a length meta-attribute. The UML RTF may wish to correct this and provide maximum values for all the UML metaattributes of data type String so that the importer can more efficiently process SMIF transfers. CDIF currently has a Date and a Time primitive data type. The Date data type will be removed from the international standard version to be consistent with UML. UML has eleven <> data types in addition to boolean. The following table shows the CDIF enumeration data type domain of values for each of these UML <> data types. Table 3 UML Enumerated Data Types UML Data Type CDIF Data Type with Enumerated Domain of Values AggregationKind Enumerated (none, shared, composite) CallConcurrencyKind ChangeableKind Enumerated (none, frozen, addOnly) EventOriginKind MessageDirectionKind Enumerated (activation, return) OperationDirectionKind (provide, require) ParameterDirectionKind (in, inout, out, return) PseudostateKind Enumerated (initial, deepHistory, shallowHistory, join, fork, branch, final) ScopeKind Enumerated (classifier, instance) SynchronousKind Enumerated (synchronous, asynchronous) VisibilityKind Enumerated (public, protected, private) OMG UML 1.0 did not specify enumeration values for CallConcurrencyKind and EventOriginKind. This will be fixed by the UML RTF. UML has four Structure data types that have only one named part. They correspond directly to CDIF primitive data types for the named part. The following table shows this correspondence: Table 4 UML Named Data Types UML Data Type CDIF Data Type Geometry Text GraphicMarker Text Mapping Text Name Identifier UML has five Structure data types that have two named parts. UML metaattributes with these data types will be transformed into two metaattributes with unstructured data types corresponding to the two named parts. The following table shows this transformation: Table 5 UML Structured Data Types UML Data Type Transformed Data Type CDIF Data Type Expression Language Body Enumerated Text BooleanExpression Language Body Enumerated Text ObjectSetExpression Language Body Enumerated Text ProcedureExpression Language Body Enumerated Text TimeExpression Language Body Enumerated Text UML has one data type that is a non-empty set of integers. Although it is specified as the union of a set of integer ranges, it can also be represented as a string. That is how it will be represented in a SMIF transfer. The following table shows this: Table 6 UML Multiplicity Data Type UML Data Type CDIF Data Type Multiplicity String 7.4 UML Model Interchange Example This section will be provided after July 6. It requires a prototype that uses the permanent meta-identifiers listed in Appendix A or some other industry agreed on permanent meta- identifiers for UML meta-objects. 8 MOF Metamodel Interchange Format Specification 8.1 MOF to CDIF mapping The MOF meta-metamodel is MOF-compliant, which means that it is also MOF static kernel and SMIF Architecture compliant. All the model elements in the MOF Model package shall be assigned unique CDIF MetaIdentifiers using the specified process. All the information is derivable from the MOF specification (reference 1) and the transformation and permanent meta-identifier assignment specifications in sections 6.4 and 6.5. As a result, the CDIF Transfer Format technology can be used without change as a stream-based model interchange format for MOF-compliant metamodels. Please note that this MOF to CDIF mapping is only a mechanism for assigning unique CDIF MetaIdentifiers to MOF (metameta)model elements. It does not change the definitions of any of the MOF concepts. For example, compliance to all the constraints that are specified in OMG ad/97-08-14 shall be the responsibility of the exporter and importer of MOF-compliant metamodels independent of compliance to the SMIF specification. A SMIF transfer stream does not need to contain pre-defined MOF constraints; it only needs to refer the importer to the normative specification for these constraints. Extensions to the meta-meta-model in the MOF Model package shall not be supported in a SMIF transfer stream. 9 Part III – Conformance 9.1 Summary of Optional versus Mandatory Interfaces It is mandatory to support the Transfer Format specifications in sections 4.1, 4.2, and 4.3 of this document. There are two separate compliance points that can be implemented separately. They are identified in the next section. 9.2 Compliance Points 9.2.1 MOF Static Kernel Compliance Point Tools that implement the SMIF Architecture specification only for model interchange are compliant to this compliance point. 9.2.2 Metamodel Behavior Compliance Point Tools that implement the SMIF Architecture specification for metamodel interchange using the full MOF Meta-metamodel including dynamic behavior of metamodels will be compliant to this compliance point. 9.3 Changes or extensions required to adopted OMG specifications 9.3.1 Inconsistencies in the UML Specification Several pre-defined stereotypes are defined inconsistently in OMG UML 1.0. These are known issues and will be corrected by the UML RTF. On page 54, the stereotype association designates at most one stereotype. This means the target multiplicity for this association must be 0..1 and not * as indicated in the diagram on page 53. 9.3.2 Extension to the MOF Specifiction In addition to qualifiedName as a (metameta)Attribute on ModelElement, a separate unique, unchangeable, and non-redundant (metameta)Attribute called permanentIdentifier needs to be added to ModelElement. 9.4 Complete IDL definitions This is not a requirement for this RFP. However, there is a complete CDIF IDL Binding specification that is published as an EIA CDIF standard (reference 11). Appendix A: UML Core Package Mapping to SMIF Architecture Subject Area: UML (in OMG ad/97-08-04, UML Semantics) Normative Reference Meta-Entity Local Meta-Relationship Local Meta-Attribute MetaId Page Name SubtypeOf Is Abstract Source Name Destination Min Source Card Max Source Card Min Dest Card Max Dest Card UML Name Is Optional CDIF Data Type Max String Length CUmlAssociation 17 Association GeneralizableElement AUmlAssociationConnection 17 Association connection AssociationEnd 1 1 2 N CUmlAssociationClass 18 AssociationClass Association/Class CUmlAssociationEnd 18 AssociationEnd ModelElement MUmlAssociationEndAggregation 18 aggregation TRUE Enumerated MUmlAssociationEndChangeable 18 changeable TRUE Enumerated MUmlAssociationEndIsNavigable 19 isNavigable TRUE Boolean MUmlAssociationEndIsOrdered 18 isOrdered TRUE Boolean MUmlAssociationEndMultiplicity 61-62 multiplicity TRUE String 256 MUmlAssociationEndTargetScope 19 targetScope TRUE Enumerated AUmlAssociationEndQualifier 19 Association End qualifier Attribute 0 1 0 N AUmlAssociationEndType 19 Association End type Classifier 0 N 1 1 CUmlAttribute 19 Attribute StructuralFeature MUmlAttributeInitialValue 20 initialValue TRUE String 256 CUmlBehavioralFeature 20 BehavioralFeature Feature TRUE MUmlBehavioralFeatureIsQuery 20 isQuery FALSE Boolean AUmlBehavioralFeatureParameters 20 Behavioral Feature parameters Parameter 0 1 0 N CUmlClass 20 Class Classifier MUmlClassIsActive 21 isActive TRUE Boolean CUmlClassifier 21 Classifier GeneralizableElement TRUE AUmlClassifierParticipant 21 Classifier participant AssociationEnd 0 N 0 N AUmlClassifierRealization 21 Classifier realization Classifier 0 N 0 N CUmlConstraint 21, 39, 53 Constraint ModelElement MUmlConstraintBodyLanguage 21, 53 body.language FALSE Enumerated MUmlConstraintBodyBody 21, 53 body.body FALSE Text AUmlConstraintConstrainedElement 22 Constraint constrainedEl ement ModelElement 0 N 1 N CUmlDataType 22 DataType Classifier CUmlDependency 22 Dependency ModelElement MUmlDependencyDescription 22 description FALSE Text AUmlDependencyClient 22 Dependency client ModelElement 0 N 1 N AUmlDependencySupplier 22 Dependency supplier ModelElement 0 N 1 N CUmlElement 22 Element TRUE CUmlFeature 23 Feature ModelElement TRUE MUmlFeatureOwnerScope 23 ownerScope FALSE Enumerated MUmlFeatureVisibility 23 visibility TRUE Enumerated AUmlFeatureOwner 23 Feature owner Classifier 0 N 1 1 CUmlGeneralizableElement 23 GeneralizableEle ment Namespace TRUE MUmlGeneralizableElemenIsAbstract 23 isAbstract FALSE Boolean MUmlGeneralizableElemenIsLeaf 23 isLeaf FALSE Boolean MUmlGeneralizableElemenIsRoot 24 isRoot FALSE Boolean CUmlGeneralization 24 Generalization ModelElement MUmlGeneralizationDiscriminator 24 discriminator TRUE String 256 AUmlGeneralizationSubtype 24 Generalization subtype Generalizable Element 0 N 1 1 AUmlGeneralizationSupertype 24 Generalization supertype Generalizable Element 0 N 1 1 CUmlInterface 24 Interface Classifier CUmlMethod 25 Method BehavioralFeature MUmlMethodBodyLanguage 25 body.language FALSE Enumerated MUmlMethodBodyBody 25 body.body FALSE Text AUmlMethodSpecification 25 Method specification Operation 0 N 1 1 CUmlModelElement 25 ModelElement Element TRUE MUmlModelElementName 25 name FALSE String 256 MUmlModelElementStereotype 40, 53, 54, 139-144 stereotype TRUE Enumerated AUmlModelElementElementOwnership 22 ModelElement Element Ownership Namespace 0 N 0 1 MUmlModelElementElementOwnership Visibility 63 visibility TRUE Enumerated CUmlNamespace 25-26 Namespace ModelElement TRUE CUmlOperation 26 Operation BehavioralFeature MUmlOperationConcurrency 26 concurrency FALSE Enumerated MUmlOperationIsPolymorphic 26 isPolymorphic FALSE Boolean MUmlOperationSpecification 26 specification FALSE Text CUmlParameter 26 Parameter ModelElement MUmlParameterDefaultValue 27 defaultValue TRUE Text MUmlParameterKind 27 kind FALSE Enumerated AUmlParameterType 27 Parameter type Clasifier 0 N 1 1 CUmlStructuralFeature 27 StructuralFeature Feature TRUE MUmlStructuralFeatureChangeable 19 changeable TRUE Enumerated MUmlStructuralFeatureMultiplicity 20 multiplicity TRUE String 256 MUmlStructuralFeatureTargetScope 19 targetScope TRUE Enumerated AUmlStructuralFeatureType 20 Structural Feature type Classifier 0 N 1 1 Appendix B: CDIF Data Models and Data Definitions Interchange Example Data Model: Data Type Definitions: OrderNum: FixedDecimalType Precision: 6 Scale: 0 SignedFlag: FALSE ProductCode: FixedLengthStringType Length: 5 LengthMultiplier: Char Number: FixedDecimalType Precision: 4 Scale: 0 SignedFlag: FALSE Date: AggregateDataType Operator: AND Components: Year: FixedDecimalType Precision: 4 Scale: 0 SignedFlag: FALSE Month: FixedDecimalType Precision: 2 Scale: 0 SignedFlag: FALSE Constraint: @<=12 Day: FixedDecimalType Precision: 2 Scale: 0 SignedFlag: FALSE Constraint: @<=31 Money: FixedDecimalType Precision: 13 Scale: 2 SignedFlag: TRUE CustomerCode: FixedLengthStringType Length: 6 LengthMultiplier: Char CDIF Transfer: CDIF,SYNTAX "SYNTAX.1" "02.00.00",ENCODING "ENCODING.1" "02.00.00", CODESET "ShiftJIS" #| H e a d e r S e c t i o n |# (:HEADER (:SUMMARY (ExporterName "AA/BRMODELLER") (ExporterVersion "05.10.00") (ExportDate "1998/06/26") (ExportTime "19:27:20") (VendorCompanyName "FUJITSU") ) ) #| M e t a - m o d e l S e c t i o n |# (:META-MODEL (:SUBJECTAREAREFERENCE DataModeling (:VERSIONNUMBER "01.00") ) (:SUBJECTAREAREFERENCE DataDefinition (:VERSIONNUMBER "01.00") ) ) #| M o d e l S e c t i o n |# (:MODEL (DataModel DM1 (Name "CDIF Example: Order, OrderDetail, Customer, Product") ) #| E n t i t y |# (Entity ENT1 (Name "OrderDetail") (Operator ) ) (Entity ENT2 (Name "Order") (Operator ) ) (Entity ENT3 (Name "Customer") (Operator ) ) (Entity ENT4 (Name "Product") (Operator ) ) (DataModel.Collects.DataModelObject DCD1 DM1 ENT1) (DataModel.Collects.DataModelObject DCD2 DM1 ENT2) (DataModel.Collects.DataModelObject DCD3 DM1 ENT3) (DataModel.Collects.DataModelObject DCD4 DM1 ENT4) #| A t t r i b u t e |# (Attribute ATR11 (Name "OrderNum") ) (Attribute ATR12 (Name "ProductCode") ) (Attribute ATR13 (Name "NumberOfItems") ) (Attribute ATR21 (Name "OrderNum") ) (Attribute ATR22 (Name "OrderDate") ) (Attribute ATR23 ) (Attribute ATR24 ) (Attribute ATR25 ) (Attribute ATR26 (Name "AmountOfMoney") ) (Attribute ATR31 (Name "CustomerCode") ) (Attribute ATR32 (Name "CreditLimit") ) (Attribute ATR41 (Name "ProductCode") ) (Attribute ATR42 (Name "Price") ) #| D a t a T y p e |# (FixedDecimalType FDTYP11 (Name "OrderNum") (Precision #d6) (Scale #d0) (SignedFlag -FALSE-) ) (FixedLengthStringType FLSTYP12 (Name "ProductCode") (Length #d5) (LengthMultiplier ) ) (FixedDecimalType FDTYP13 (Name "Number") (Precision #d4) (Scale #d0) (SignedFlag -FALSE-) ) (AggregateDataType AGGRDTYP22 (Name "Date") (Operator ) ) (FixedDecimalType FDTYP23 (Name "Year") (Precision #d4) (Scale #d0) (SignedFlag -FALSE-) ) (FixedDecimalType FDTYP24 (Name "Month") (Precision #d2) (Scale #d0) (SignedFlag -FALSE-) ) (FixedDecimalType FDTYP25 (Name "Day") (Precision #d2) (Scale #d0) (SignedFlag -FALSE-) ) (FixedDecimalType FDTYP26 (Name "Money") (Precision #d13) (Scale #d2) (SignedFlag -TRUE-) ) (FixedLengthStringType FLSTYP31 (Name "CustomerCode") (Length #d6) (LengthMultiplier ) ) #| .References. M e t a - R e l a t i o n s h i p s |# (ComponentObject.References.DefinitionObject CRD11 ATR11 FDTYP11) (ComponentObject.References.DefinitionObject CRD12 ATR12 FLSTYP12) (ComponentObject.References.DefinitionObject CRD13 ATR13 FDTYP13) (ComponentObject.References.DefinitionObject CRD21 ATR21 FDTYP11) (ComponentObject.References.DefinitionObject CRD22 ATR22 AGGRDTYP22) (ComponentObject.References.DefinitionObject CRD23 ATR23 FDTYP23) (ComponentObject.References.DefinitionObject CRD24 ATR24 FDTYP24) (ComponentObject.References.DefinitionObject CRD25 ATR25 FDTYP25) (ComponentObject.References.DefinitionObject CRD26 ATR26 FDTYP26) (ComponentObject.References.DefinitionObject CRD31 ATR31 FLSTYP31) (ComponentObject.References.DefinitionObject CRD32 ATR32 FDTYP26) (ComponentObject.References.DefinitionObject CRD41 ATR41 FLSTYP12) (ComponentObject.References.DefinitionObject CRD42 ATR42 FDTYP26) #| .Contains. M e t a - R e l a t i o n s h i p s |# (DefinitionObject.Contains.ComponentObject DCC11 ENT1 ATR11 (SequenceNumber #d1) ) (DefinitionObject.Contains.ComponentObject DCC12 ENT1 ATR12 (SequenceNumber #d2) ) (DefinitionObject.Contains.ComponentObject DCC13 ENT1 ATR13 (SequenceNumber #d3) ) (DefinitionObject.Contains.ComponentObject DCC21 ENT2 ATR21 (SequenceNumber #d1) ) (DefinitionObject.Contains.ComponentObject DCC22 ENT2 ATR22 (SequenceNumber #d2) ) (DefinitionObject.Contains.ComponentObject DCC23 AGGRDTYP22 ATR23 (SequenceNumber #d1) ) (DefinitionObject.Contains.ComponentObject DCC24 AGGRDTYP22 ATR24 (SequenceNumber #d2) ) (DefinitionObject.Contains.ComponentObject DCC25 AGGRDTYP22 ATR25 (SequenceNumber #d3) ) (DefinitionObject.Contains.ComponentObject DCC26 ENT2 ATR26 (SequenceNumber #d3) ) (DefinitionObject.Contains.ComponentObject DCC31 ENT3 ATR31 (SequenceNumber #d1) ) (DefinitionObject.Contains.ComponentObject DCC32 ENT3 ATR32 (SequenceNumber #d2) ) (DefinitionObject.Contains.ComponentObject DCC41 ENT4 ATR41 (SequenceNumber #d1) ) (DefinitionObject.Contains.ComponentObject DCC42 ENT4 ATR42 (SequenceNumber #d2) ) #| KEY Definitions |# (CandidateKey CKY11 (IsPrimary -TRUE-) ) (CandidateKey CKY21 (IsPrimary -TRUE-) ) (CandidateKey CKY31 (IsPrimary -TRUE-) ) (CandidateKey CKY41 (IsPrimary -TRUE-) ) (ForeignKey FKY11) (ForeignKey FKY12) (Entity.IsIdentifiedBy.Key EIK111 ENT2 FKY11) (Entity.IsIdentifiedBy.Key EIK112 ENT4 FKY12) (Entity.IsIdentifiedBy.Key EIK011 ENT1 CKY11) (Entity.IsIdentifiedBy.Key EIK021 ENT2 CKY21) (Entity.IsIdentifiedBy.Key EIK031 ENT3 CKY31) (Entity.IsIdentifiedBy.Key EIK041 ENT4 CKY41) (Key.Incorporates.Attribute KIA11 FKY11 ATR11 (SequenceNumber #d1) ) (Key.Incorporates.Attribute KIA12 FKY12 ATR12 (SequenceNumber #d1) ) (Key.Incorporates.Attribute KIA21 CKY21 ATR21 (SequenceNumber #d1) ) (Key.Incorporates.Attribute KIA31 CKY31 ATR31 (SequenceNumber #d1) ) (Key.Incorporates.Attribute KIA41 CKY41 ATR41 (SequenceNumber #d1) ) (ForeignKey.References.CandidateKey FRC11 FKY11 CKY21) (ForeignKey.References.CandidateKey FRC12 FKY12 CKY41) (CandidateKey.Incorporates.ForeignKey CIF11 CKY11 FKY11 (SequenceNumber #d1) ) (CandidateKey.Incorporates.ForeignKey CIF12 CKY11 FKY12 (SequenceNumber #d2) ) #| R e l a t i o n s h i p s |# (Relationship REL1 ) (Relationship REL2 (Name "MakeOrder") ) (Relationship REL3 ) (DataModel.Collects.DataModelObject DCD5 DM1 REL1) (DataModel.Collects.DataModelObject DCD6 DM1 REL2) (DataModel.Collects.DataModelObject DCD7 DM1 REL3) (Role ROL11) (Role ROL12) (Role ROL21) (Role ROL22) (Role ROL31) (Role ROL32) (Role.BelongsTo.Relationship RBR11 ROL11 REL1) (Role.BelongsTo.Relationship RBR12 ROL12 REL1) (Role.BelongsTo.Relationship RBR21 ROL21 REL2) (Role.BelongsTo.Relationship RBR22 ROL22 REL2) (Role.BelongsTo.Relationship RBR31 ROL31 REL3) (Role.BelongsTo.Relationship RBR32 ROL32 REL3) (RolePlayer RP11 (MinInnerCardinality "1") (MaxInnerCardinality "1") ) (RolePlayer RP12 (MinNumberOfOccurrences #d1) (MaxNumberOfOccurrences #d20) (MaxOuterCardinality "20") (MinInnerCardinality "1") (MaxInnerCardinality "1") ) (RolePlayer RP21 (MinInnerCardinality "1") ) (RolePlayer RP22 (MinInnerCardinality "1") (MaxInnerCardinality "1") ) (RolePlayer RP31 ) (RolePlayer RP32 (MinInnerCardinality "1") (MaxInnerCardinality "1") ) (RolePlayer.Plays.Role RPR11 RP11 ROL11) (RolePlayer.Plays.Role RPR12 RP12 ROL12) (RolePlayer.Plays.Role RPR21 RP21 ROL21) (RolePlayer.Plays.Role RPR22 RP22 ROL22) (RolePlayer.Plays.Role RPR31 RP31 ROL31) (RolePlayer.Plays.Role RPR32 RP32 ROL32) (DataModelObject.ActsAs.RolePlayer DAR11 ENT2 RP11) (DataModelObject.ActsAs.RolePlayer DAR12 ENT1 RP12) (DataModelObject.ActsAs.RolePlayer DAR21 ENT3 RP21) (DataModelObject.ActsAs.RolePlayer DAR22 ENT2 RP22) (DataModelObject.ActsAs.RolePlayer DAR31 ENT4 RP31) (DataModelObject.ActsAs.RolePlayer DAR32 ENT1 RP32) (TextualConstraint TXC7 (ConstraintExpression #[@<=12]#) (ConstraintLanguage ) ) (TextualConstraint.IsConstraintOn.SemanticInformationObject TIS7 TXC7 FDTYP24) (TextualConstraint TXC8 (ConstraintExpression #[@<=31]#) (ConstraintLanguage ) ) (TextualConstraint.IsConstraintOn.SemanticInformationObject TIS8 TXC8 FDTYP25) ) ad/98-07-09 July 6, 1998 OMG Stream-based Model Interchange Format Page 26 of 42