Meta Object Facility (MOF) Specification

Joint Revised Submission

Cooperative Research Centre for Distributed Systems Technology (DSTC) IBM Corporation International Computers Limited Objectivity Inc. Oracle Corporation System Software Associates Unisys Corporation

Supported By: BEA Systems, Inc. Data Access Digital Equipment Corporation Electronic Data Systems Hewlett-Packard Company MCI Systemhouse Corporation MicroFocus Platinum Technology Inc. Rational Software Corporation

September 1, 1997 OMG Document ad/97-08-14 Copyright © 1997 DSTC (Cooperative Research Centre for Distributed Systems Technology) Copyright © 1997 IBM Corporation Copyright © 1997 International Computers Limited Copyright © 1997 MCI Systemhouse Copyright © 1997 Objectivity Inc. Copyright © 1997 Oracle Corporation Copyright © 1997 Platinum Technology Copyright © 1997 Platinum Technology Copyright © 1997 Rational Software Corporation Copyright © 1997 System Software Associates Copyright © 1997 Unisys Corporation

The companies listed above hereby grant a royalty-free license to the Object Management Group, Inc. (OMG) for worldwide distribution of this document or any derivative works thereof within OMG and to OMG members for evaluation purposes, so long as the OMG reproduces the copyright notices and the below paragraphs on all distributed copies.

The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version.

The copyright holders listed above have agreed that no person shall be deemed to have infringed the copyright, in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.

NOTICE : The information contained in this document is subject to change with notice.

The material in this document details a submission to the Object Management Group for evaluation in accordance with the license and notices set forth on this page. This document does not represent a commitment to implement any portion of this specification by the submitters.

WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE OBJECT MANAGEMENT GROUP AND 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 PARTICULAR PURPOSE. The Object Management Group and 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 copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials.

This document contains information that is patented which is protected by copyright. All Rights Reserved. No part of the work covered by copyright hereon 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 permission of the copyright owner. All copies of this document must include the copyright and other information contained on this page.

The copyright owners grant member companies of the 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.

RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Right in Technical, Data and Computer Software Clause at DFARS 252.227.7013

OMG® is a registered trademark of the Object Management Group, Inc. Primary Contacts for the MOF submission:

Cooperative Research Centre for Kerry Raymond [email protected] Distributed Systems Technology IBM Corporation Larry Clark [email protected] International Computers Limited Richard Herbert Richard.r[email protected] MCI Systemhouse Cris Kobryn [email protected] Objectivity Inc. Andrew Wade [email protected] Oracle Corporation Peter Thomas [email protected] Platinum Technology Inc. Dilhar DeSilva [email protected] Rational Software Corporation Ed Eykholt [email protected] System Software Associates Oliver Sims [email protected] Unisys Corporation Sridhar Iyengar [email protected] Table of Contents The Table of Contents contains entries for both the Specification and the Appendices.

1. Overview 1-1 1.1 Introduction ...... 1-1 1.1.1 Rationale ...... 1-2 1.1.1.1 Goals and Objectives ...... 1-3 1.2 Structure of This Submission ...... 1-4 1.2.1 Meta Object Facility Submission Overview ...... 1-5 1.2.1.1 Overview ...... 1-5 1.2.1.2 Facility Purpose and Use ...... 1-5 1.2.1.3 MOF Model and Interfaces...... 1-5 1.2.1.4 Reflective Package...... 1-6 1.2.1.5 MOF Additional Semantics...... 1-6 1.2.1.6 MOF Model to IDL Mapping ...... 1-6 1.2.2 Meta Object Facility (MOF) Appendices ...... 1-6 1.2.2.1 Appendix A: MOF IDL Summary...... 1-6 1.2.2.2 Appendix B: MODL Description of the MOF ...... 1-6 1.2.2.3 Appendix C: Glossary of Terms ...... 1-7 1.2.2.4 Appendix D: MOF, OA&DF (UML) and CORBA Alignment ...... 1-7 1.2.2.5 Appendix E: Implementation Requirements...... 1-7 1.2.2.6 Appendix F: Future Directions of the MOF...... 1-7 1.3 Technical Requirements Summary ...... 1-7 1.3.1 Summary of Key Requirements ...... 1-7 1.3.2 Resolution of Technical Criteria ...... 1-9 1.3.2.1 Relationship to OMG IDL and CORE’95 ...... 1-9 1.3.2.2 Positioning within the Common Facilities Architecture...... 1-10 1.3.2.3 Federation of Object Schemas...... 1-10 1.4 Business Requirements ...... 1-11 1.4.1 Copyright Waiver...... 1-11 1.4.2 Proof of Concept ...... 1-11 1.5 Acknowledgments...... 1-12 1.5.1 MOF Co-Submitters ...... 1-12 1.5.2 MOF Supporters...... 1-12

9/1/97 Meta Object Facility 1.1 iii Table of Contents

1.5.3 Additional Contributors and Supporters ...... 1-13

2. Facility Purpose and Use 2-1 2.1 Introduction ...... 2-1 2.2 Software Development Scenarios...... 2-2 2.3 Type Management Scenarios ...... 2-4 2.4 Information Management Scenarios...... 2-5 2.5 Data Warehouse Management Scenarios...... 2-6

3. MOF Model and Interfaces 3-1 3.1 Introduction ...... 3-1 3.2 Purpose...... 3-2 3.3 MOF Architecture...... 3-2 3.4 Four Layer Metamodel Architecture...... 3-2 3.5 Organization of the MOF ...... 3-4 3.6 How the MOF Model is Described ...... 3-5 3.6.1 Types ...... 3-6 3.6.2 Associations...... 3-9 3.7 MOF Model Types ...... 3-10 3.7.1 ModelElement ...... 3-13 3.7.2 Namespace ...... 3-21 3.7.3 GeneralizableElement ...... 3-24 3.7.4 TypedElement...... 3-30 3.7.5 Classifier ...... 3-32 3.7.6 Class ...... 3-33 3.7.7 DataType ...... 3-35 3.7.8 Feature ...... 3-39 3.7.9 StructuralFeature ...... 3-41 3.7.10 MofAttribute...... 3-43 3.7.11 Reference ...... 3-44 3.7.12 BehavioralFeature ...... 3-47 3.7.13 Operation ...... 3-48 3.7.14 MofException ...... 3-51 3.7.15 Association...... 3-53 3.7.16 AssociationEnd ...... 3-56

iv Meta Object Facility 1.1 9/1/97 Table of Contents

3.7.17 Package ...... 3-61 3.7.18 Import ...... 3-64 3.7.19 Parameter ...... 3-67 3.7.20 Constraint...... 3-69 3.7.21 Constant...... 3-73 3.7.22 Tag ...... 3-74 3.7.23 TypeAlias...... 3-77 3.8 MOF Model Associations...... 3-78 3.8.1 Namespace-Contains-ModelElement ...... 3-78 3.8.2 GeneralizableElement-Generalizes-GeneralizableElement...... 3-80 3.8.3 Reference-RefersTo-AssociationEnd ...... 3-83 3.8.4 Reference-Exposes-AssociationEnd derived...... 3-84 3.8.5 TypedElement-IsOfType-Classifier ...... 3-86 3.8.6 Operation-CanRaise-MofException ...... 3-88 3.8.7 Import-Aliases-Namespace...... 3-90 3.8.8 Constraint-Constrains-ModelElement ...... 3-91 3.8.9 ModelElement-DependsOn-ModelElement derived...... 3-93 3.8.10 Tag-AttachesTo-ModelElement ...... 3-95 3.9 MOF Model Data Types...... 3-96 3.9.1 Primitive Data Types ...... 3-97 3.9.1.1 CORBA Basic Types ...... 3-97 3.9.1.2 NameType...... 3-97 3.9.1.3 AnnotationType ...... 3-97 3.9.1.4 TypeDescriptor ...... 3-97 3.9.2 Constructed Types ...... 3-97 3.9.2.1 MultiplicityType ...... 3-97 3.9.2.2 VisibilityType...... 3-98 3.9.2.3 TristateType ...... 3-98 3.9.2.4 DepthType...... 3-98 3.9.2.5 DirectionType ...... 3-99 3.9.2.6 ScopeType ...... 3-99 3.9.2.7 AggregationType ...... 3-99 3.9.2.8 EvaluationType...... 3-99 3.9.2.9 DependencyKind ...... 3-99 3.9.2.10 VerificationResultKind ...... 3-99

9/1/97 Meta Object Facility 1.1 v Table of Contents

3.10 MOF Model Exceptions ...... 3-100 3.10.1 NameNotResolved...... 3-100 3.10.2 ObjectNotExternalizable ...... 3-100 3.10.3 FormatNotSupported ...... 3-100 3.11 OCL Representation of the MOF Model Constraints...... 3-100

4. Facility Package 4-1 4.1 Introduction ...... 4-1 4.2 Facility Package Types...... 4-2 4.2.1 ModelRepository ...... 4-2 4.2.2 MofRepository...... 4-4 4.3 Facility Package Exceptions...... 4-7 4.3.1 PragmaNotSupported ...... 4-7 4.3.2 PragmaNotPresent ...... 4-7

5. Reflective Package Types 5-1 5.1 Introduction ...... 5-1 5.2 The Reflective Module...... 5-2 5.2.1 Reflective::RefBaseObject ...... 5-3 5.2.2 Reflective::RefObject ...... 5-4 5.2.3 Reflective::RefAssociation ...... 5-10 5.2.4 Reflective::RefPackage ...... 5-12 5.3 The CORBA IDL for the Reflective Interfaces ...... 5-14 5.3.1 Introduction ...... 5-14 5.3.2 Data Types...... 5-14 5.3.3 Common Exceptions...... 5-15 5.3.4 Reflective Exceptions...... 5-17 5.3.5 Reflective::RefObject Interface ...... 5-19 5.3.6 Reflective::RefObject Interface ...... 5-20 5.3.7 Reflective::RefAssociation Interface ...... 5-22 5.3.8 Reflective::RefPackage Interface ...... 5-23 5.4 Reflective Usage Conventions for the MOF IDL Mapping ...... 5-23 5.4.1 Reflective Interface Inheritance ...... 5-23 5.4.2 Parameter Mapping for Reflective Operations...... 5-25

6. MOF Semantics Details 6-1

vi Meta Object Facility 1.1 9/1/97 Table of Contents

6.1 Introduction ...... 6-1 6.2 Associations, Aggregations, and References ...... 6-1 6.2.1 Associations ...... 6-1 6.2.1.1 Constraints on Associations...... 6-2 6.2.1.2 Dynamic Semantics of AssociationEnd Constraints ...... 6-2 6.2.1.3 Changeability Constraints...... 6-5 6.2.2 References...... 6-6 6.2.2.1 Equivalence of Reference and Association Operations ...... 6-6 6.2.3 Aggregations ...... 6-7 6.3 MOF Data Type Encoding and Translation Conventions...... 6-11 6.3.1 MOF Data Type Encoding...... 6-12 6.3.2 IDL Generation from DataType Objects...... 6-14 6.3.3 DataType Consistency Constraints...... 6-15 6.3.4 External Types ...... 6-15 6.3.5 Rationale ...... 6-16 6.4 Rules of ModelElement Containment...... 6-17 6.5 Rules of Importing and Visibility ...... 6-18 6.5.1 Namespace Extension through Generalization and Importing...... 6-18 6.5.2 Visibility...... 6-20 6.5.3 Explicitly Restricting Visibility...... 6-22 6.5.4 OCL Representation of Visibility Rules ...... 6-22 6.6 MOF and MetaModel Extensibility Mechanisms ...... 6-25 6.6.1 MOF as an Extensibility Mechanism ...... 6-25 6.6.2 Using Tags and Tag Values...... 6-25 6.6.3 Tags in the Definition of Metamodels...... 6-25 6.6.4 Tags added to Published Metamodels...... 6-26 6.7 Inter-Repository Modeling...... 6-27 6.7.1 Element, Model, and Repository Naming...... 6-27 6.7.2 Defining Models across Repositories...... 6-29

7. The MOF Model to IDL Mapping 7-1 7.1 Notation...... 7-1 7.2 Design Rationale ...... 7-2 7.2.1 Identifier Naming ...... 7-2 7.2.1.1 Rules for Splitting MOF Model Names into “Words” ...... 7-3

9/1/97 Meta Object Facility 1.1 vii Table of Contents

7.2.1.2 Identifier Format 1...... 7-3 7.2.1.3 Identifier Format 2...... 7-4 7.2.1.4 Literal String Values...... 7-4 7.2.1.5 Externally Defined Identifiers ...... 7-4 7.2.2 Generation Rules for Collection Kinds...... 7-5 7.2.3 Identifier Name Scoping...... 7-7 7.3 MOF Model to IDL Mapping Rules...... 7-7 7.3.1 Package Template...... 7-7 7.3.2 Package Create Template ...... 7-10 7.3.3 Type Forward Declaration Template...... 7-11 7.3.4 Type Template...... 7-11 7.3.5 Type Create Template ...... 7-13 7.3.6 Association Template ...... 7-14 7.3.7 Attribute Template...... 7-18 7.3.8 Reference Template ...... 7-25 7.3.9 Operation Template ...... 7-28 7.3.10 Exception Template ...... 7-29 7.3.11 Constant Template ...... 7-30 7.3.12 Data Type Template ...... 7-30 7.3.13 Constraint Template ...... 7-31 7.3.14 Import Template...... 7-31 7.3.15 Annotation Template...... 7-32 7.4 Preconditions for Successful IDL mapping ...... 7-33 7.5 Semantics of the Generated Interfaces ...... 7-33

A. Meta Object Facility IDL Summary A-1 A.1 MOF Model IDL ...... A-1 A.2 Facility IDL...... A-24 A.3 Reflection IDL ...... A-26

B. MODL Description of the MOF B-1 B.1 MOF Model...... B-1 B.2 Facility ...... B-15

C. Glossary C-1 C.1 Introduction ...... C-1

viii Meta Object Facility 1.1 9/1/97 Table of Contents

C.2 Scope ...... C-1 C.3 Notation Conventions ...... C-1 C.4 Terms ...... C-2

D. Meta-Metamodel Architecture Alignment of UML, MOF and CORBA D-1 D.1 Introduction...... D-1 D.2 Motivation...... D-2 D.3 Approach ...... D-2 D.4 Metamodel Comparison...... D-3 D.4...... D-3 D.5 Issues Related to UML-MOF Mapping ...... D-4 D.6 Relationship to Other Models...... D-6 D.6.1 Relationship to the EIA CDIF...... D-6 D.6.2 Relationship to the RM-ODP Model...... D-6 D.7 Summary...... D-7

E. Implementation Requirements E-1 E.1 Introduction ...... E-1 E.2 Vendor Boundaries...... E-1 E.3 Requirements to Support Object Identity...... E-1 E.4 Requirements to Support Associations Across Vendor Boundaries ...... E-2

F. Future Directions For the MOF F-1 F.1 Extending the MOF to Support Ternary and Higher Order Associations...... F-1 F.2 Support of Stream based Interchange Format...... F-1 F.3 Support for MOF Evolution and Versioning...... F-1 F.4 Support for Mapping between Models...... F-2 F.5 Interoperability with Microsoft Repository...... F-2

List Of Tables

Table 1-1. Four Layer Metamodeling Architecture...... 3-3

Table 6-1. Copy and Deletion Semantics on Forms of Aggregation...... 6-9

Table 6-2. Rules of Containment ...... 6-18

9/1/97 Meta Object Facility 1.1 ix Table of Contents

Table D-1 Core Metaobjects Comparison...... D-3

Table D-2 Data Types Comparison ...... D-4

List of Figures

Figure 1-1 OMG Architecture and the Repository Common Facility ...... 1-10

Figure 3-1 MOF Top-Level Packages...... 3-5

Figure 3-2. The MOF Model Package ...... 3-12

Figure 3-3. Base Abstractions of the MOF Model Package ...... 3-13

Figure 3-4. MOF Model Classifiers ...... 3-31

Figure 3-5. Feature Types of the MOF Model...... 3-37

Figure 3-6. MOF Model Elements for Association ...... 3-53

Figure 3-7. MOF Model Packaging ...... 3-61

Figure 3-8. MOF Model – Other Elements...... 3-67

Figure 4-1. The MOF Facility Package ...... 4-2

x Meta Object Facility 1.1 9/1/97 1. Overview

1.1 Introduction The following companies are pleased to co-submit to the OMG AD RFP2: Analysis and Design Task Force RFP2 (formerly CF RFP5) Meta Object Facility specification (hereafter referred to as the MOF):

• Cooperative Research Centre for Distributed Systems Technology (DSTC) • IBM Corporation • International Computers Limited • Objectivity Inc. • Oracle Corporation • System Software Associates • Unisys Corporation

The following companies are pleased to support the MOF specification to the OMG.

• BEA Systems, Inc. • Data Access • Digital Equipment Corporation • Electronic Data Systems • Hewlett-Packard Company • MCI Systemhouse • MicroFocus • Platinum Technologies Inc. • Rational Software Corporation

The main purpose of the OMG MOF is to provide a set of CORBA interfaces that can be used to define and manipulate a set of interoperable metamodels. The MOF is a key building block in the construction of CORBA based distributed development environments.

This submission mainly consists of:

• The Meta Object Facility Semantics (MOF meta-meta model, from here on referred to as the MOF model for simplicity and to help the “meta averse”) • The Meta Object Facility (MOF) CORBA Interfaces (described with the model)

9/1/97 Meta Object Facility 1.1 1-1 Section 1. Overview

• The Meta Object Facility IDL Mapping Definition

• Supporting Appendices

This submission defines these standards and provides proof of concept that covers key aspects of the MOF.

1.1.1 Rationale This submission represents the integration of work currently underway by the co- submitters in the areas of object repositories, object modeling tools, and meta data management in distributed object environments. The MOF submission uses the Unified Modeling Language (UML) notation as defined in the UML Partners submission (OMG Document : ad/97-08-12) to the OMG OA&D Facility RFP. The facility interface and semantics incorporate some of the advanced meta data management concepts that have been implemented in the commercial object repositories, development tools, and object framework products developed by the co-submitters. The co-submitters intend to commercialize the MOF technology within the guidelines of the OMG.

Adoption of this submission would enhance meta data management and meta data interoperability in distributed object environments in general and in distributed development environments in particular. While the initial RFPs (MOF and OA&DF) address meta data interoperability in object analysis and design domain, the submitters anticipate the MOF to be rich enough to support additional domains. Examples include metamodels that cover the application development life cycle as well as additional domains such as data warehouse management and business object management. OMG is expected to issue new RFPs to cover these additional domains. The MOF submitters expect this version of the MOF to evolve in the future to address new requirements. Please refer to Appendix F: Future Directions of the MOF for more details.

The software industry has made several fragmented efforts at producing meta data standards in the past. This attempt at OMG to integrate the Meta Object Facility and the Object Analysis and Design Facility (OA&DF) is expected to be a critical step in developing meta data standards that will begin addressing the application development life cycle. This standard is even more important now considering the profound impact that Distributed Objects and the Internet are having on development methodologies that favor object-oriented and component-based development environments. The use of repositories and meta data management in these environments is a well recognized industry trend. Note that the OMG is adopting a building block approach to standardize core services, facilities and information models for specific domains as opposed to defining an all-encompassing model.

The OMG is also involved in harmonizing the OMG MOF and OA&DF efforts with the EIA CDIF standards, which is a candidate specification for tool interchange format in the object analysis and design domain for a subsequent RFP. The MOF provides the foundation for the tool interchange mechanism for the MOF and OA&DF using CORBA IDL interfaces specified in this submission and in the related OA&DF submission and in the related OA&DF submission.

The main purpose of the OMG MOF is to provide a set of CORBA interfaces that can be used to define and manipulate a set of interoperable metamodels. The MOF also defines a simple meta-metamodel with sufficient semantics to describe metamodels in various domains starting with the domain of object analysis and design. Integration of

1-2 Meta Object Facility 1.1 9/1/97 Section 1. Overview

metamodels across domains is required for integrating tools and applications across the life cycle using common semantics.

The MOF designers provide a balanced model that is neither too simplistic (one that defines only classes, attributes, and associations) nor too ambitious (one that has all object modeling constructs as required in a general purpose modeling language like the UML). The designers have specified this model to be rich enough to define a variety of metamodels and precisely enough to be implemented in CORBA environments.

1.1.1.1 Goals and Objectives The objective of this submission is to specify a Meta Object Facility that provides a CORBA-compliant architecture for defining and sharing semantically rich meta data in distributed heterogeneous environments. This submission is intended to be a foundation for sharing meta data across the life cycle in component-based and object-oriented development environments as envisioned when the CF RFI 3 Repositories was issued. The initial test case for the MOF will be its usability in the Object Analysis and Design Domain (OA&DTF RFP 1) and, possibly, in the Business Object Domain (BODTF RFP 1) in which the OMG is trying to standardize specifications in parallel.

A key goal of the MOF is to provide extensibility and self discovery in systems. This goal is achievable because the MOF interfaces can be used to discover new extensions and new components that are being constantly introduced in distributed environments.

Another goal of MOF is to provide the specification of rich semantics to enable two systems or applications to meaningfully share information. This goal is achievable by providing domain-specific metamodels (such as the OA&D metamodel - UML) that conform to the MOF metamodeling architecture. Note that CORBA uses the DII for discovery of CORBA interfaces and the proposed CORBA Component Model RFP (work in progress) also addresses the self discovery (introspection) of CORBA components.

Similar specific mechanisms can be found in Microsoft COM and various proprietary repository and tool implementations. The MOF addresses the discovery of meta data in general, and addresses the broader issues of rich semantic meta data interoperability typical in development, data warehouse and business object environments. The co- submitters expect that discovery interfaces optimized for specific purposes (as in Java Beans) will use standard CORBA services and mechanisms, such as the MOF-to-IDL mapping in this specification, to coexist and interoperate with general MOF interfaces.

Typically, the MOF will be used for manipulating meta objects to provide integration of tools and applications across the life cycle using industry standard metamodels, such as the OA&DF UML, which is proposed as an OMG standard. For more information on anticipated use of the MOF, please refer to Section 2. Facility Purpose and Use.

Proliferation of systems dependent on standard meta data services, such as the MOF together with industry standard metamodels such as UML, accelerates the market for component software in general and model driven component software development, because components meeting specific semantics and requirements can be discovered using the MOF interfaces. Additional work in the areas of standard metamodels for database technologies, component management and tracking, transaction discovery and legacy integration is expected in the future.

9/1/97 Meta Object Facility 1.1 1-3 Section 1. Overview

A technical goal of importance to the MOF is interoperability with OMG CORBA and the integration with the OA&D Facility and the Business Object Facility. All these three facilities have strong meta data heritage. This submission addresses the integration of the MOF and OA&D Facility in detail by aligning the models, the CORBA interfaces and the semantics underlying the model. Refer to Appendix D: MOF, OA&DF (UML) and CORBA Alignment for more details. The IDL submitted in this specification and in the Rational et al UML specification were generated from prototype versions of the MOF.

1.2 Structure of This Submission This section briefly describes the major portions of the MOF submission. The submission is organized into two main documents. The first is the Meta Object Facility (MOF) Specification (OMG Document title : ad/97-08-14). . The MOF Specification section defines the MOF model and the MOF CORBA interfaces that are being proposed for standardization. The submission also includes a MOF to IDL mapping specification which will simplify using the MOF and enable interoperability between or metamodels defined using the MOF by providing a consistent IDL

The second document is the Meta Object Facility (MOF) Appendices (OMG Document title : ad/97-08-15) which describes various supporting documents including the MOF IDL summary, alignment between the MOF and OA&DF and a glossary of terms used. Some of the appendices listed below were jointly produced in conjunction with the UML Partner's OA&DF submission.

It is important to emphasize the point that while both the MOF and OA&DF define modeling concepts, there is a difference in scope as well as purpose of these two complementary specifications that address key aspects of the application development life cycle. The major difference in scope between the UML Partners OA&DF submission and this submission (from a modeling perspective) is that the UML encompasses the entire Object Analysis and Design Domain, where as the MOF addresses a subset focused on a smaller (but not minimal) set of modeling constructs useful to define object oriented metamodels from both a structural and behavioral perspective. The candidate OA&D Facility metamodel which UML represents is one such metamodel that can be supported by MOF. The submitters to both RFPs have focused on aligning the two models and supporting common CORBA interfaces for commonality wherever possible and significant progress has been accomplished in meeting this goal as can be seen from the models and the generated CORBA interfaces.

It is important to note that the MOF Model is the meta-metamodel for the OA&DF UML submission and can be used to represent the UML metamodel and to generate CORBA IDL interfaces for the proposed OA&DF. Likewise the MOF Model is used to describe the MOF itself and to generate the MOF Model interfaces in this submission.

A list of the key components/sections of this submission, along with the OMG document numbers is attached.

Document OMG Document No. Meta Object Facility (MOF) Specification ad/97-08-14 MOF Overviewad/97-08-14 MOF Usagead/97-08-14

1-4 Meta Object Facility 1.1 9/1/97 Section 1. Overview

Document OMG Document No.

MOF Model and Interfaces ad/97-08-14 MOF Facility Packagead/97-08-14 MOF Reflective Packagead/97-08-14 MOF Semantics Detailsad/97-08-14 MOF to IDL Mapping Specificationad/97-08-14 Meta Object Facility (MOF) Appendices ad/97-08-15 Appendix A : MOF IDL Summaryad/97-08-15 Appendix B: MODL Description of the MOFad/97-08-15 Appendix C MOF/OA&DF Glossaryad/97-08-15 Appendix D - MetaModel Architecture alignment of MOF, OA&DF ad/97-08-15 and CORBA Appendix E- MOF Implementation Requirementsad/97-08-15 Appendix F : Future Directions for the MOFad/97-08-15

These documents are available via the OMG server, in http://www.omg.org/docs/ad.

1.2.1 Meta Object Facility Submission Overview The MOF Specification section describes the MOF Model, Interfaces and a mapping from MOF to CORBA IDL. The specification is organized into various sub sections as described below.

1.2.1.1 Overview Provides an introduction to the Meta Object Facility submission as well as discussing its rationale, history, and potential impact on distributed meta data management in the future. The key RFP requirements summary and how this submission addresses the RFP requirements is addressed. The key contributors to the specification are acknowledged.

1.2.1.2 Facility Purpose and Use Provides some scenarios of domains where the submitters expect the MOF to be used. Scenarios discussed include Application Development, Data Warehouse Management and Type Management.

1.2.1.3 MOF Model and Interfaces This is the main portion of the MOF submission. Each of the MOF Classes, Associations and Data Types are fully described along with the IDL interfaces. The semantics of the MOF are defined using a combination of UML notation, textual description and constraints using the Object Constraint Language (OCL). The MOF

9/1/97 Meta Object Facility 1.1 1-5 Section 1. Overview

interfaces are used to manipulate meta models and meta model constructs in a CORBA environment.

1.2.1.4 Reflective Package The MOF reflective package defines general purpose interfaces used by all MOF objects to enable self discovery and general purpose manipulation of MOF objects. These interfaces can be used in addition to or instead of specific interfaces defined in the MOF Model section. These interfaces apply to MOF objects defined in this specification as well as MOF objects defined using the MOF in additional OMG specifications such as the CORBA interfaces in the UML Partners submission to the OA&DF.

1.2.1.5 MOF Additional Semantics This section provides a more comprehensive explanation of the fundamental modeling concepts in the MOF, detailed semantics including structural and behavioral constraints applied to more complex MOF concepts such as Associations and Packages. This section also describes MOF Extensibility Mechanisms and the use of MOF in distributed repository environments.

1.2.1.6 MOF Model to IDL Mapping This section defines the generation of CORBA IDL from the descriptions held in the MOF. IDL generation capability is intended to ensure that various metamodels defined using the MOF have consistent IDL. Given a MOF compliant meta-model (such as UML), this portion of the specification can be used to generate a concrete IDL for UML.

Note that this specification does not require that the MOF can derive the meta-object IDL automatically.

1.2.2 Meta Object Facility (MOF) Appendices This section describes the various appendices that support this specification. This information includes the MOF IDL summary, how the MOF relates to other OMG technologies and industry standards efforts. A glossary of terms used and a comparison of the MOF, UML and the CORBA Object Model and IDL is attached.

1.2.2.1 Appendix A: MOF IDL Summary This section summarizes the complete set of IDL specifications for the MOF and is provided in a format that can be easily processed by IDL compilers.

1.2.2.2 Appendix B: MODL Description of the MOF The section summarizes the Meta Object Definition Language (MODL) textual description of the MOF which was used to generate the CORBA IDL for the MOF.

1-6 Meta Object Facility 1.1 9/1/97 Section 1. Overview

1.2.2.3 Appendix C: Glossary of Terms This section describes the key terms used in the MOF and OA&DF submissions and is also included in the UML Partners OA&DF (UML) submission.

1.2.2.4 Appendix D: MOF, OA&DF (UML) and CORBA Alignment This section describes an architecture for meta modeling and how this architecture is applied to compare the core modeling constructs in the MOF, OA&DF (UML) and the OMA. A comparison/mapping table of the key modeling concepts in each of these domains is provided. This section also describes how the MOF relates to EIA CDIF, RM-ODP, and related industry efforts in repository and meta data standardization.

1.2.2.5 Appendix E: Implementation Requirements This section suggests approaches and principles that can be used to support MOF interoperability between implementations of MOF from multiple vendors. Areas addressed include Model interoperability as well as client tool interoperability when using multiple MOF implementations.

1.2.2.6 Appendix F: Future Directions of the MOF This section summarizes potential areas of future work in the MOF based on feedback of MOF submitters and reviewers. These areas include support for higher order associations, MOF model evolution and versioning, stream based model interchange formats.

1.3 Technical Requirements Summary This section describes how this submission meets the key requirements identified in the RFP. The section numbers in the RFP Requirement column correspond to the ADTF RFP 2 Meta Object Facility document (former CFTF RFP 5).

1.3.1 Summary of Key Requirements

9/1/97 Meta Object Facility 1.1 1-7 Section 1. Overview

RFP RequirementHow submission addresses the requirement

5.5.1 The MOF defines an object oriented meta-meta model ( a model Representational Adequacy for defining metamodels) referred to as the MOF model) its semantics and interfaces. The model is described using a combination of UML notation, CORBA Interfaces, explanatory text and constraints. The Section 3. Interfaces addresses this requirement by detailing all the key concepts the RFP has identified. 5.2.1 and 5.5.2 The proposal includes a series of CORBA interfaces for creating, Meta Object Manipulation deleting and manipulating meta objects. Wherever possible (creation, retrieval...) existing CORBA technologies (such as CORBA data types, typecodes and services) are used. The MOF uses CORBA interfaces to exchange metamodels - specifically OA&D metamodels which are candidates for standardization by the OMG in the OA&D RFP. The MOF IDL Mapping spec has been used to define the OA&D facility interfaces. The Meta Object Facility Interface section of the proposal addresses this requirement in detail. Both general purpose (reflective interfaces) and specific (static interfaces) are described. 5.5.4 The Package construct represents the concept of a schema or a Rigorous definition of the metamodel in the MOF. MetaModels can be nested and concept of ‘Object Schema’ associations and inheritance between metamodel classes is supported, Model components such as types, classes and interfaces can be further extended by using standard object principles.. The MOF model and Interfaces section addresses this requirement. The Object Constraint Language (OCL) also used in the UML partners OA&DF submission is used to define well formed rules in the MOF to increase the rigor of this specification. Please refer to OMG Document ad/97-08-09 for a description of the OCL specification. 5.5.3 The sufficiency of the MOF model to represent the MOF and OMG Object Model proof of OA&DF (proposed UML metamodel) and the generation of the concept OA&DF & MOF CORBA interfaces provides proof of concept that the MOF can represent the OMG Object Model and that it is compatible with the OMG Object Model. Also see Appendix D : MOF, OA&DF (UML) and CORBA Alignment for more details. Earlier versions of this alignment work have been presented to the OMG Architecture Board and to the ORMSC.

1-8 Meta Object Facility 1.1 9/1/97 Section 1. Overview

RFP RequirementHow submission addresses the requirement

5.5.5 Interfaces of the MOF and those generated from MOF Relationship to the Interface implementations, are registered in the Interface Repository (IR) Repository like any other CORBA interface. For run time access to CORBA Interface definitions, the applications invoke the IR as they do now. If applications require access to semantics that are outside the scope of the IR (relationship and constraint semantics or model information) , the MOF interfaces can be used. Note that the CORBA IR serves specific purpose at run time to support the ORB. The MOF and any implementation of MOF based systems serve the purpose of sharing semantically rich meta data in development and run time environments and thus complements the IR without adding complexity to the IR. The MOF uses and builds on the IR concepts (for example typecodes) to provide CORBA data types to MOF users. Fore more information on how the MOF Model compares to the CORBA Object Model and IDL concepts, please refer to Appendix D: MOF, OA&DF (UML) and CORBA Alignment.

1.3.2 Resolution of Technical Criteria

1.3.2.1 Relationship to OMG IDL and CORE’95 OMG IDL is used to specify all the interfaces in the Meta Object Facility. The MOF itself is of course manipulated using standard CORBA interfaces.

The OMG core object model describes how objects interact; thus, it is an interface or interaction model. No specific implementation is implied. The OMG object model is not intended to be a metamodel (as described in the OMA). The CORBA object model is a concrete model with the goal of specifying a mechanism for portability and distributed object interoperability. The MOF does define a meta-metamodel (for simplicity this submission refers to this as the MOF model). The purpose of the MOF model is to enable the definition and manipulation of metamodels in various domains, with the initial focus being on object analysis and design metamodels. The MOF can therefore be used to specify the OMG object model, which it can treat as a meta-model. Likewise, because the MOF defines a set of CORBA compliant interfaces, these interfaces conform to the CORBA object model. The MOF can be used to specify additional semantics (relationships, constraints) that are implied (or expressed in text) in the CORBA object model..

The MOF is intended to provide support for richer meta data definition and manipulation in a CORBA environment. Note that the co-submitters have eliminated the meta prefix in the 1.1 submission to reduce confusion and to help the MOF/UML alignment so that OMG can standardize on a common model, semantics and glossary.

Please refer to Appendix D: MOF, OA&DF (UML) and CORBA Alignment for more details on the relationship between these models.

9/1/97 Meta Object Facility 1.1 1-9 Section 1. Overview

1.3.2.2 Positioning within the Common Facilities Architecture OMG issued the Meta Object Facility RFP (CF RFP-5, now AD RFP2) as a result of the consensus from the three responses to CFTF RFI 3 (Repositories) from Unisys, IBM, and Texas Instruments. The Repository Common Facility is positioned within the Information Management Common Facility and is composed of a number of common facilities and object services, including the MOF and the Change Management Facility.

The standardization of the MOF provides a solid foundation for the OMG architecture in moving toward a unifying architecture for defining and managing meta data in distributed environments. The following figure illustrates the positioning of the MOF as a key component of the CORBA architecture as well within the Common Facilities Architecture. For more details on this positioning, refer to the Unisys response to CFTF RFI - 3 1995/95-11-05 on the OMG server.

The Meta Data/Schema Management facility in the figure corresponds to the MOF described in this submission. Note that the MOF interfaces are initially targeted to support the manipulation of OA&D metamodels; however, the submitters expect broader use in areas such as data warehouse management and business object management.

OMG Architecture and the Repository Common Facility Repository Common Facility

Meta Data/ Data Versions... Application Objects Schema Mgmt Interchange

APIs APIs

Object Request Broker (ORB)

Object Services

Iyengar (c) 1995, Unisys

Figure 1-1 OMG Architecture and the Repository Common Facility

1.3.2.3 Federation of Object Schemas The MOF allows the definition of metamodels that are potentially domain independent and architecture neutral. The metamodels registered in the MOF can correspond to schemas that are in fact federated. The MOF uses the federation capabilities provided by services such as the Trader service and the Object Transaction Service. The schema information itself is accessed using the interfaces specified in the MOF. The services of the MOF can be used to define integrated metamodels that correspond to federated

1-10 Meta Object Facility 1.1 9/1/97 Section 1. Overview

schemas. This area is still emerging, and interfaces specifically designed to address federation beyond the services already provided by CORBA (Object Transaction Service and Object Trader service) are not specified in this submission.

For more details on using MOF across vendor boundaries, please refer to Section 6.7 Inter-Repository Modeling.

1.4 Business Requirements

1.4.1 Copyright Waiver In the event that this specification is adopted by OMG, the submitters grant to the OMG, a non-exclusive, royalty-free, paid-up, worldwide license to copy and distribute this specification document and to modify the document and distribute copies of the modified version. For more detailed information, see the disclaimer on the inside of the cover page of this submission.

1.4.2 Proof of Concept MOF submitters demonstrated MOF 1.0 prototypes in April 1997. MOF 1.1 prototypes will be demonstrated in September 1997. There is sufficient support for this submission, in terms of endorsements, implementations, and proofs of concept:

• The MOF model has been modeled using itself. The MOF IDL has been generated using this MOF Model and the MOF-IDL mapping rules in this specification • The MOF to IDL mapping specification has been prototyped by DSTC and A subset of the specification has been prototyped by Unisys. DSTC has defined the MOF using the MODL language and generated the IDL for the MOF in this specification . Please see Appendix B: MODL Description of the MOF for more details. • The UML metamodel (proposed OA&DF metamodel) has been defined and loaded into a MOF server prototyped by Unisys. The IDL for the OA&DF (UML) metamodel been generated from this MOF server using the MOF-IDL mapping rules Please refer to OMG Document : ad/97-08-10 UML CORBA facility Interface Definition for this specification. A subset of the constraints defined in the MOF specification have been prototyped and applying these constraints have allowed the submitters to detect inconsistencies in the MOF and OA&DF. • Two of the submitting companies Unisys with its Universal Repository (UREP) and IBM with its TeamConnection have delivered extensible object oriented repositories with their own proprietary meta object facilities. Oracle and Platinum are also designing repository systems that use an extensible object oriented meta-metamodel. The MOF specification is an attempt to unify and build on these meta-metamodels and to provide an industry standard meta object facility that is fully CORBA compliant. • The MOF meta-metamodel has been included and referenced in the UML partners response to the OA&D RFP. Unisys, IBM, Platinum, Hewlett-Packard, Oracle and MCI Systemhouse (all MOF submitters or supporters) are also co-submitters of the OA&D RFP, showing consensus on the key aspects of the MOF and its relationship to the OA&DF.

9/1/97 Meta Object Facility 1.1 1-11 Section 1. Overview

1.5 Acknowledgments The following section lists the team members that worked on the MOF submission during the initial and revised submissions. The members of the core team that designed and influenced the MOF model and the MOF interfaces over the last few months are listed below. The primary contact in each company is listed first.

1.5.1 MOF Co-Submitters

Cooperative Research Centre for Kerry Raymond [email protected] Distributed Systems Technology Stephen Crawley [email protected] Simon McBride [email protected] IBM Corporation Larry Clark [email protected] Kevin Cattell [email protected] Jos Warmer [email protected] International Computers Limited Richard Herbert [email protected] MCI Systemhouse Cris Kobryn [email protected] Objectivity Inc. Andrew Wade [email protected] Oracle Corporation Peter Thomas [email protected] Andy Simmons [email protected] System Software Associates Oliver Sims [email protected] Don Kavanagh [email protected] Unisys Corporation Sridhar Iyengar [email protected] GK Khalsa [email protected]

1.5.2 MOF Supporters

BEA Systems Ed Braginsky [email protected] Data Access Cory Casanave [email protected] Electronic Data Systems Fred Cummins [email protected] Hewlett Packard Company (S) Martin Griss [email protected] MCI Systemhouse (S) Cris Kobryn [email protected] MicroFocus David Gambel [email protected] Platinum Technology Inc. (S) Dilhar DeSilva [email protected] Rational Software Corporation (S) Ed Eykholt [email protected]

1-12 Meta Object Facility 1.1 9/1/97 Section 1. Overview

1.5.3 Additional Contributors and Supporters The co-submitters and supporters of the MOF submission appreciate the contributions and support of the following individuals during the MOF submission and evaluation process:

Shamim Ahmed, Eric Aranow, Colin Ashford, Grady Booch, Carol Burt, Mike Bradley, Steve Cook, Gary Daugherty, Phillippe Desfray, Tom Digre, Bob Hodges, Jeff Eastman, Johannes Ernst, Jim Fontana, Michael Guttman, Ivar Jacobson, Peter Johnson, Kurt Kirkey, Nookiah Kolluru, Rainer Kossmann, Mary Loomis, Frank Manola, Jim Odell, Joaquin Miller, Frankie Mosher, Ron Neubauer, Woody Pidcock, Eric Rivas, Jim Rumbaugh, Bran Selic, Steve Skinner and Max Tardiveau..

NOTE: In a small number of cases, the individuals and the corporations they represent have not formally endorsed the MOF submission. However, these people participated in design/prototyping sessions for either the MOF or UML submission, which resulted in a better, more complete definition of the MOF. In some cases, the individuals are methodologists whose writings and lectures influenced and helped the creation of this MOF submission.

9/1/97 Meta Object Facility 1.1 1-13 Section 1. Overview

1-14 Meta Object Facility 1.1 9/1/97 2. Facility Purpose and Use

2.1 Introduction The MOF is intended to support a wide range of usage patterns and applications. Indeed, the range of usage patterns (let alone applications) is wider than the authors of this submission can imagine. These scenarios have been presented to provoke future debate and work in the OMG and elsewhere in MOF related areas. These scenarios need to be sharpened in their focus before useful specifications and related products materialize.

To understand the possible usage patterns for the MOF, the first thing one needs to understand is the two distinct viewpoints for the MOF:

• Modeling viewpoint: The designer’s viewpoint, looking “down” the meta levels. From the modeling viewpoint, the MOF is used to define an information model for a particular domain of interest. This definition is then used to drive subsequent software design and/or implementation steps for software connected with the information model. • Data viewpoint: The programmer’s viewpoint, looking at the current meta-level, and possibly looking up at the higher meta-levels. From the data viewpoint, the MOF (or more accurately, a product of the MOF) is used to apply the OMA-based distributed computing paradigm to manage information corresponding to a given information model. In this mode, it is possible for a CORBA client to obtain the information model descriptions and to use them to support reflection.

The second thing one needs to realize, is that this MOF submission is intended to provide an open-ended information modeling capability. The submission defines a core MOF model that includes a relatively small, though not minimal, set of constructs for object- oriented information modeling. The MOF model can be extended by inheritance and composition to define a richer information model that supports additional constructs. Alternatively, the MOF model can be used as a model for defining information models. This feature allows the designer to define information models that differ from the philosophy or details of the MOF model. In this context the MOF Model is referred to as a meta-metamodel because it is being used to define metamodels such as the UML.

Finally, one needs to understand the purpose and the limitations of the MOF model to the CORBA IDL mapping defined by this submission. The prime purpose of the mapping is to define CORBA interfaces for information models defined in terms of the MOF model1

1 Both extensions to the MOF meta-model that are expressible in the meta-model itself, and unconnected information models expressed using the MOF meta-model.

9/1/97 Meta Object Facility 1.1 2-1 Section 2. Facility Purpose and Use

using standard interfaces and interoperable semantics. These interfaces allow a client to create, access, and update information described by the model, with the expectation that the information will be managed in a way that maintains the structural and logical consistency constraints specified in the information model definition.

While we anticipate that some vendors will supply tools (for example. IDL generators, server generators, and so on) to support the development of software conforming to the mapping, provision of these tools is not a requirement of this specification. The second limitation is that the mapping is only intended to support the MOF model itself; that is, it does not support extensions to the metamodel or to other unconnected information models. Furthermore, since the IDL mapping is not itself modeled in the MOF, there can be no standardized support for extending the mapping or defining new mappings. Finally, the IDL mapping in this submission supports only CORBA IDL. Mappings from the MOF model to other interface definition languages are certainly feasible, as are direct mappings to programming languages or data definition languages. However, these mappings are beyond the scope of the first version of the MOF submission.

2.2 Software Development Scenarios One of the most likely applications of the MOF initially will be to support the development of distributed object-oriented software from high-level models. Such a software development system would typically consist of a repository service for storing the computer representations of models, and a collection of associated tools. The latter would allow the programmers and designers to input the models, and would assist in the process of translating these models into software implementations.

In the simple case, the repository service could be an implementation of the MOF model interfaces. This service would be accompanied by a tools (for example, compilers or graphical editors) that allow the designer to input information models using a human readable notation for the MOF model. Assuming that the target for software development is CORBA based, the system would include an IDL generator that implements the standard MOF model-to-CORBA IDL mapping.

The usage scenario for this repository service would be along the following lines:

1. The programmer uses the input tools provided by the system to define an object- oriented information model using the notation provided. 2. When the design is complete, the programmer runs the IDL generator to translate the model into CORBA IDL. 3. The programmer examines the IDL, repeating steps 1 and 2 to refine the model as required. 4. The programmer then implements the generated IDL to produce a target object server, and implement the applications that use the object server.

The functionality of the development suite described above can be expanded in a variety of ways:

• We can add generator tools to automatically produce the skeleton of an object server corresponding to the generated IDL. Depending on the sophistication of the tool, this

2-2 Meta Object Facility 1.1 9/1/97 Section 2. Facility Purpose and Use

skeleton might include code for the query and update operations prescribed by the IDL mapping and code to check the constraints on the information model. • We can add generator tools to produce automatically stereotypical applications such as scripting tools and GUI-based browsers. • We can extend the repository service to store the specifications and/or implementation code for target server and application functionality that cannot be expressed in the MOF model.

While the MOF model is a powerful modeling language for expressing a range of information models; however, it is not intended to be the ultimate modeling language. Instead, one intended use of the MOF is as a tool for designing and implementing more sophisticated modeling systems. The following example illustrates how the MOF might be used to construct a software development system centered around a hypothetical “Universal Design Language” (UDL).

Many parallels can be drawn between the hypothetical UDL discussed below and the draft OA&DF UML proposal in that UML is designed to be a general purpose modeling language for visualizing, designing and developing component software. The UDL can be thought of as an extension as well as a refinement of many of the concepts in the UML. The extensions are mainly in the area of providing sufficient detail to complete the implementation framework technologies and defining additional meta models that address various technology domains such as database management, transaction processing, etc.

The developer of a software development system based on UDL might start by using a MOF Model notation to define a metamodel for UDL. Conceivably, the UDL metamodel could reuse part or all of the MOF Model, though this is not necessarily a good idea2. The developer could then use a simple MOF-based development system (along the lines described above) to translate the UDL metamodel into CORBA IDL for a UDL repository and to provide hand-written or generated software that implements the UDL repository and suitable UDL model input tools.

The hypothetical UDL development system cannot be considered complete without some level of support for the process of creating working code that implements systems described by the UDL models. Depending on the nature of the UDL, this process might involve a number of steps in which the conceptual design is transformed into more concrete designs and, finally, into program source code. A UDL development system might provide a range of tools to assist the target system designer or programmer. These tools would need to be supported by repository functions to store extra design and implementation information, along with information such as version histories, project schedules, and so on, that form the basis of a mature software development process.

In practice, a software development system implemented along these lines would have difficulty meeting the needs of the marketplace. A typical software engineering “shop” will have requirements on both the technical and the process aspects of software

2 The MOF meta-model has specific requirements (e.g. model simplicity and support for automatic IDL generation) that are not generally applicable. As a consequence, it is unreasonable to expect the MOF meta-model design to be suitable for all kinds of object modeling.

9/1/97 Meta Object Facility 1.1 2-3 Section 2. Facility Purpose and Use

engineering that cannot be met by a “one-size-fits-all” development system. The current trend in software development systems is for Universal Repository systems; that is, for highly flexible systems that can be tailored and extended on the fly.

A MOF-based universal repository system would be based around the core of the MOF Model, and a suite of tools for developing target metamodels (for example, the UDL) and their supporting tools. Many of the tools in the universal repository could be reflective; that is, the tools could make use of information from higher meta-levels to allow them to operate across a range of model types. Functionality, such as persistence, replication, version control and access control, would need to be supported uniformly across the entire repository framework.

The following excerpt from the OA&DF Revised submission (ad/97-08-02) indicates the practicality of a subset of the repository scenario described above:

"The UML CORBA facility interfaces have been generated by mapping the UML into a prototype of the Meta Object Facility, then generating the IDL from the MOF. This is a proof of concept for the UML and the MOF, which share common semantics in their core models."

2.3 Type Management Scenarios A second area in which early use of the MOF is likely, is in the representation and management of the various kinds of type information used by the expanding array of CORBA infrastructure services.

The CORBA Interface Repository (IR) is the most central type-related service in CORBA 2.0. The IR serves as a central repository for interface type definitions in a CORBA-based system. The current IR essentially provides access to interface definitions that conform to the implied information model of CORBA IDL. While the IR interfaces are tuned fairly well to read-only access, there is no standard update interface and no way to augment the interface definitions in the IR with other relevant information, such as behavioral semantics.

Given a simple MOF-based development environment (as described above), it would be easy to describe the implied information model for CORBA IDL using a notation for the MOF Model. The resulting CORBA IDL model could then be translated into the IDL for a MOF-based replacement for the CORBA IR. While this replacement IR would not be upwards compatible with the existing IR, the fact that it was MOF-based would provide a number of advantages. The MOF-based IR would:

• Support update interfaces. • Be extensible in the sense that it would be feasible to extend the CORBA IDL model specification by (MOF Model) composition and inheritance. This ability would help smooth the path for future extensions to the CORBA object model. • Make it easier to federate multiple IR instances and to represent associations between CORBA interface types and other kinds of type information. • Automatically include links to its own meta-information definition expressed using MOF meta-objects.

2-4 Meta Object Facility 1.1 9/1/97 Section 2. Facility Purpose and Use

Other candidates for use of MOF-based technology among existing and forthcoming infrastructure services include:

• Trader: The CORBA trader service maintains a database of “service offers” from services in a CORBA-based distributed environment. These offers have associated service types that are represented using the CosTradingRepos::ServiceTypeRepository interface. (A trader service type is a tuple consisting of a type name, an interface type, and a set of named property types. Service types can be defined as subtypes of other service types.) • Notification: At least one initial submission for the forthcoming Notification service includes the notion of an event type. (An event type is a tuple consisting of a type name, a set of named property types, and a set of supertypes.)

In both cases, a MOF-based type repository would have the advantages listed previously for the MOF-based Implementation Repository.

Looking to the future, there are a number of other possible uses for MOF-based type repositories in infrastructure services. For example:

• Service interface bridges: As CORBA matures and there is large-scale deployment as part of enterprise-wide computing infrastructures, it will become increasingly necessary to cope with legacy CORBA objects; that is, with objects that provide or use out-of-date service interfaces. In situations where statically deployed object wrappers are not a good solution, one alternative is to provide an ORB-level service that can insert an interface bridge between incompatible interfaces at bind time. Such a service would depend on types that describe the available bridges and the mechanisms used to instantiate them. • Complex bindings: RM-ODP supports the idea that bindings between objects in a distributed environment can be far more complex than simple RPC, stream or multicast protocols. RM-ODP defines the notion of a multi-party binding involving an arbitrary number of objects of various types, in which different objects fill different roles in the binding. A CORBA service to manage complex bindings would be based on formally described binding types that specify the numbers and types of objects filling each role and the allowed interaction patterns (behaviors) for a given binding.

2.4 Information Management Scenarios The previous sections focused on the use of the MOF to support the software development life-cycle and the type management requirements of CORBA infrastructure services. This section broadens the scope to the more general domain of information management; that is, the design, implementation, and management of large bodies of more or less structured information.

First, note that some of the ideas outlined above carry straight over to the information management domain. In some cases, it may be appropriate to define the information model (that is, the database schema) for the application of interest directly using the MOF Model. In this case, the technology described previously can be used to automate the production of CORBA-based servers to store the information and applications to use

9/1/97 Meta Object Facility 1.1 2-5 Section 2. Facility Purpose and Use

it. In other situations, the MOF Model can be used to define a metamodel suitable for defining information models for the domain of interest; for example, a metamodel for describing relational database schemas. Then a development environment can be designed and implemented using MOF-based technology that supports the generation of CORBA-based data servers and applications from information models.

In addition, the MOF potentially offers significant benefits for large-scale information systems by allowing such a system to make meta-information available at run-time. Some illustrative examples follow.

Information discovery: The World-Wide Web contains a vast amount of useful (and useless) information on any topic imaginable. However, this information is largely inaccessible. In the absence of other solutions, current generation web indexing systems or search engines must rely on simple word matching. Unless the user is frames queries carefully , the number of “hits” returned by a search engine are overwhelming. Furthermore, it is now apparent that even the largest search engines cannot keep pace with the Web's rate of growth.

In the absence of software that can “understand” English text, the approach most likely to succeed is to build databases of meta-data that describes web pages. If this meta-data is represented using MOF-based technology and an agreed base metamodel for the meta- data, the framework can support local meta-data extensions through judicious use of MOF-supported reflection. In addition, because the meta-data framework is defined in the MOF context, it can be accessible to a larger class of generic tools. This approach can be used for any information system in which meta-data is definition is relatively informally.

2.5 Data Warehouse Management Scenarios Data warehousing is a recent development in enterprise-scale information management. The data warehouse technique recognizes that it is impractical to manage the information of an enterprise as a unified logical database. Instead, this technique extracts information from logically- and physically-distinct databases, integrates the information, and stores it in a large-scale “warehouse” database that allows read-only access to possibly non- current data. The extraction and integration processes depend on a database administrator creating a mapping from the schemas for the individual databases to the schema of the warehouse. If the meta-information for the various databases is represented using MOF-based technology, then it should be possible to create sophisticated tools to assist the database administrator in this process

Meta data is often described as the “heart and soul” of the data warehouse environment. The MOF can be used to automate meta data management of data warehouses. Current meta data repositories that manage data warehouses often use static meta data using batch file-based meta data exchange mechanisms. We expect the use of MOF- and standard CORBA-based event and messaging mechanisms and mobile agent technology (also being standardized by OMG) to drive a new generation of data warehouse management tools and systems that are more dynamic. These tools will enable customers to react in a timelier manner to changing data access patterns and newly discovered patterns, which is the focus of data mining and information discovery systems.

2-6 Meta Object Facility 1.1 9/1/97 Section 2. Facility Purpose and Use

The MOF interfaces and the MOF Model can be used to define specific metamodels for database, data warehouse, model transformation and warehouse management domains. The integration between these models in a run time data warehouse and the development environment (which has data models and UML based object models) which describes the corporate data models and operational databases is a typical use of a MOF. The traceability across these environments is enabled by defining an impact analysis metamodel which builds on the rich model of relationships supported by the MOF.

9/1/97 Meta Object Facility 1.1 2-7 Section 2. Facility Purpose and Use

2-8 Meta Object Facility 1.1 9/1/97 3. MOF Model and Interfaces

3.1 Introduction This section describes the model that defines the MOF. The MOF provides a set of modeling elements, including the rules for their use, with which to construct models. Specifically, the MOF modeling elements support development of metamodels. This focus enables the MOF to provide a more domain-specific modeling environment for defining metamodels instead of a general-purpose modeling environment.

A well-designed modeling tool or facility should be based on a metamodel that represents the modeling elements and the rules provided by the tool or facility.

Every metamodel (and every meta-metamodel, and…) is also a model, As the MOF Model described in this section is the metamodel for the MOF, where is the model for this metamodel? Formally, the MOF is defined in itself; that is, the modeling elements defined in the MOF Model and provided by the MOF are used to define the MOF Model itself. In essence, the MOF Model is its own metamodel. However, this circular definition does not support presentation of the model. Therefore, this submission describes the MOF narratively and through the use of UML notation, tables, and Object Constraint Language (OCL) expressions.

Note that the use of UML notation is a convenience to the designers of the MOF and to the readers of the MOF specification. The semantics of the MOF Model are completely defined in the MOF specification and do not depend on the semantics of any other model. The MOF interfaces used to manipulate metamodels of course are dependent on CORBA in that these interfaces are specified using CORBA IDL.

A significant amount of the MOF Model syntax and semantics definition is constraint- based. This submission describes the constraint expressions as clearly as possible. In addition, the submission provides a reference to the OCL expression that defines each constraint.

The OCL, which is defined in Object Constraint Language Definition (, OMG document ad/97-08-09), provides a small set of language elements used to define expressions. As an expression language, OCL cannot change the state of objects; however, it can express constraints, including invariants, preconditions, and post-conditions. OCL expressions use operations defined in the MOF Model with the attribute isQuery set to TRUE. (Such operations do not change the state of the object.). To ensure complete specification of constraints, this submission provides OCL definitions for MOF-defined operations used in OCL expressions. In addition, to avoid ambiguity or misinterpretation this submission uses OCL to define a few of the most complex concepts of the MOF Model.

9/1/97 Meta Object Facility 1.1 3-1 Section 3. MOF Model and Interfaces

The interfaces through which the MOF is utilized are generated from the MOF Model. However, these interfaces do not provide the semantic information necessary to determine the behavior of their operations. Therefore, it is essential to understand the MOF in terms of its model and related semantics, not just its interfaces.

3.2 Purpose This document is primarily intended as a complete and precise specification of the MOF’s semantic model and related CORBA interfaces for manipulating MOF model elements. The primary audience for this specification consists of the OMG, other standards organizations, tool, object framework and repository vendors, metamodelers and expert modelers. The authors assume familiarity with advanced object modeling concepts, databases, repositories and OMG CORBA.

3.3 MOF Architecture The MOF model defines the semantics for representing metamodels using the MOF. While the authors expect most new metamodels to be object oriented, traditional (Entity- Relationship) metamodels can also be defined using the MOF. The MOF model is really a meta-metamodel in that it is used to define metamodels. The MOF corresponds to the most fundamental layer in a traiditonal foutr layer metamodeling architecture. Note that while an arbitrary number of metamodel layers can exist, most common systems usually deal with the metamodel layer above (instance of assocciation) and a model layer below (instances association). The four layer metamodel architecture popularized by several standards organizations including ISO is briefly described below. This architecture is also useful in comparing models underlying MOF, OA&DF, CORBA and CDIF which are further discussed in Section Appendix D: MOF, OA&DF (UML) and CORBA Alignment.

3.4 Four Layer Metamodel Architecture

The MOF model is defined as one of the layers of a four-layer metamodeling architecture. This architecture is a proven infrastructure for defining the precise semantics required by complex models. There are several other advantages associated with this approach: • It validates core constructs by recursively applying them to successive metalayers.

• It provides an architectural basis for defining future MOF extensions.

• It furnishes an architectural basis for aligning the the MOF with other standards based on a four-layer metamodeling architecture (e.g., the OMG OA&DF and CDIF).

The generally accepted conceptual framework for metamodeling is based on an architecture with four layers: • meta-metamodel

3-2 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

• metamodel

• model

• user objects

The MOF corresponds to the meta-metamodel in that it is used to define the OA&DF (UML) metamodel. To improve readability the rest of the document uses the term ‘MOF Model’ instead of the term ‘MOF meta-metamodel). The MOF specification avoids the ‘meta’ prefix to improve readibility. The MOF and OA&DF submitters have strived for alignment of the core modeling concepts in the MOF and UML and have adopted common terminology. Occasional divergence of names in the MOF are due to name clashes with CORBA reserved words : eg. Attribute.

The functions of these layers are summarized in the following table:

Layer Description Example

meta-metamodel The infrastructure for a metamodeling MetaClass, MetaAttribute, architecture. Defines the language for MetaOperation MOF Layer specifying metamodels. Mof::Class, Mof::Attribute, Mof::Operation

metamodel An instance of a meta-metamodel. Class, Attribute, Operation, Defines the language for specifying a Component OA&DF (UML) model. Layer

model An instance of a metamodel. Defines StockShare, askPrice, sellLimitOrder, a language to describe an information StockQuoteServer (User Object domain. Model)

user objects An instance of a model. Defines a , (user data) specific information domain. 654.56, sell_limit_order,

Table 1: Four Layer Metamodeling Architecture

The meta-metamodeling layer forms the foundation for the metamodeling architecture. The primary responsibility of this layer is to define the language for specifying a metamodel. A meta-metamodel defines a model at a higher level of abstraction than a metamodel, and is typically more compact than the metamodel that it describes. A meta-metamodel can define

9/1/97 Meta Object Facility 1.1 3-3 Section 3. MOF Model and Interfaces

multiple metamodels, and there can be multiple meta-metamodels associated with each metamodel.3 While it is generally desirable that related metamodels and meta-metamodels share common design philosophies and constructs, this is not a strict rule. Each layer needs to maintain its own design integrity. Examples of meta-metaobjects in the meta-metamodeling layer are: MetaClass, MetaAttribute, and MetaOperation. Note that the MOF specification uses the terms Class, MOfAttribute and Operation for these concepts. These are metaclasses by virtue of them being defined as part of the MOF and because instances of these constructs correspond to metamodel constructs.

A metamodel is an instance of a meta-metamodel. The primary responsibility of the metamodel layer is to define a language for specifying models. Metamodels are typically more elaborate than the meta-metamodels that describe them, especially when they define dynamic semantics. Examples of metaobjects in the metamodeling layer are: Class, Attribute, Operation, and Component. These constructs are typical of the OA&DF (UML) metamodel.

A model is an instance of a metamodel. The primary responsibility of the model layer is to define a language that describes an information domain. Examples of objects in the modeling layer are: StockShare, askPrice, sellLimitOrder, and StockQuoteServer.

User objects (a.k.a. user data) are an instance of a model. The primary responsibility of the user objects layer is to describe a specific information domain. Examples of objects in the user objects layer are: , 654.56, sell_limit_order, and

The MOF meta-metamodel has been designed to allow the definition and insstantiation of multiple metamodels including the proposed OA&DF (UML) metamodel. The relationship between the MOF and OA&DF (UML) is described in Section 1 MOF Overview.and in more detail in Appendix D: MOF, OA&DF (UML) and CORBA Alignment. 3.5 Organization of the MOF The MOF Model uses packages to control complexity and support reuse. The model elements are contained in three packages as follows:

• The Model Package contains the majority of the MOF Model. A single package can be used because of the tight coupling of model elements. • The Reflective Package contains the portion of the MOF Model supporting reflection—the ability of objects to discover and utilize information about their structure and features. Factoring these elements into a separate package enables the reflection portion of the model to be used in metamodel definitions and in situations not yet considered. • The Facility Package contains the model elements that support facilities, repositories, tools, etc., that take advantage of the MOF Model. Factoring these elements in a separate package supports the expectation that the facility-like

3 If there is not an explicit meta-metamodel, there is an implicit meta-metamodel associated with every metamodel.

3-4 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

elements will be appropriate for some metamodels and environments, and inappropriate for others.

Reflective

«imports»

Model

«imports»

Facility

Figure 3-1 MOF Top-Level Packages

Figure 3-1 provides a representation of the MOF packages in UML notation. The three packages make up the MOF, but they are not nested in a single MOF Package. (For IDL generation, the three modules corresponding to the three packages are defined with the prefix org.omg.Mof). Data types are an integral part of these packages. With no expectation of swapping out or separately reusing the data types, they are defined in the packages where they are needed. However, the data types are not at the same meta-level (their instances are non-object values, not objects which define types, packages, etc.). Therefore, they are not included in the model diagrams..

3.6 How the MOF Model is Described Section 3 describes the modeling elements that make up the MOF Model and provide the building blocks for metamodels. Because these elements are formally described with the MOF Model itself, the characteristics used to describe the model are the same characteristics provided by the model.

The following topics briefly describes the conventions this submission uses to define the model elements and their characteristics. This section can be considered a form of bootstrapping—defining the modeling elements sufficiently to allow complete

9/1/97 Meta Object Facility 1.1 3-5 Section 3. MOF Model and Interfaces

description of the elements as the MOF Model in the subsequent sections of the document.

3.6.1 Types Types, the fundamental modeling elements provided by the MOF Model, are described in Section 3.7 MOF Model Types. Each type is described in terms of its supertypes, the types of instances it can contain, its attributes, its references, its operations, and its constraints. This submission uses a sparse approach to define types; in most cases, the reference to a characteristic is omitted if the type does not have that characteristic.

The MOF uses the term Types (meaning specification or interface as opposed to implementation) in the sense that the MOF is used to specify metamodels and associated CORBA interfaces. The MOF does not define implementation classes which are associated with methods. This usage of the termType is consistent with the UML definition of Type as a Sterotype of Class. The metamodel construct Class is the most general of the triad: Type, Class and Interface (as discussed in thOA&DF proposal) and is therefore used in both the MOF and OA&DF submission as a key modeling concept. Withinthe MOF specification the terms Type and Class are used interchangeably becuase theMOF only describes types and is used to generate interfaces.

The following text explains the information provided for each characteristic.

Supertypes

All types from which the type directly inherits characteristics are listed under this heading. Because these modeling elements are types, rather than classes, multiple inheritance is used repeatedly.

Contained Elements

If the type can contain other elements, the kinds of elements that the type can contain are listed under this heading.

Attributes

The defined attributes for the type are listed under this heading. Attributes inherited from the supertypes are not included.

The following table describes the information presented for each attribute:

Description of the attribute type: Indicates the type of the value that the attribute holds.

3-6 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

multiplicity: Identifies constraints on the set of values held by the attribute. The MultiplicityType (see Section 3.9.2.1 MultiplicityType) can constrain the upper and lower bounds, whether the collection must maintain an order, and whether the elements of the collection must be unique. If there is no required ordering, nothing is stated; if the values must be unique, nothing is stated; ordering and uniqueness are also omitted for single-valued attributes. Rather than specifying the cardinality constraints through the upper and lower bounds values, most attributes are specified as exactly one, zero or one, one or more, or zero or more. changeable: No – indicates that changeable is false and the usual means for modifying the attribute value will not be present. For example, the IDL translation provides an operation for modifying an attribute that is changeable. If the attribute is not changeable, no such operation is provided. However, an attribute specified as not changeable does not make the attribute value immutable. Specific operations can be defined to change the value. This row is omitted if changeable is true and the usual means for modifying the attribute value will be present. derived from: Indicates that the attribute value is derived from other information in the model, as described. This row is omitted if the attribute value is not derived. scope Type scope iIndicates that the value is shared by all the instances of the type; instance scope attributes are held by each instance. This row is omitted if the attribute is of instance scope. constraints: Identifies any constraints on the attribute. The number next to the constraint refers to the OCL representation for that constraint. This row is omitted if there are no constraints on the attribute.

References

The references for the type are listed under this heading. A reference ‘references’ the objects linked to it through links of an association. A type participating in an association may or may not have a corresponding reference, based on the needs of the type. Along with the description, here are the rows that may appear in the table.

The following table describes the information presented for each reference:

Description of the reference type: Indicates the type of the object or objects with which the reference is linked.

9/1/97 Meta Object Facility 1.1 3-7 Section 3. MOF Model and Interfaces

defined by: Identifies the association end (often called a role) that provides much of the definition for the reference. Each reference corresponds to an association. multiplicity: Identifies constraints on the set of values held by the reference. The MultiplicityType (see Section 3.9.2.1 MultiplicityType) can constrain the upper and lower bounds and whether the collection must maintain an order. If there is no required ordering, nothing is stated; ordering is also omitted for single-valued reference. Rather than specifying the cardinality constraints through the upper and lower bounds values, most references are specified as exactly one, zero or one, one or more, or zero or more. inverse: When the type of this reference has a reference back to this type, and they are both defined by association ends of the same association, that other reference is the inverse of this reference. This row is omitted if the reference does not have an inverse. derived from: Indicates that the reference value is derived from other information in the model, as described. This row is omitted if the reference value is not derived. constraints: Identifies any constraints on the reference. The number next to the constraint refers to the OCL representation for that constraint. This row is omitted if there are no constraints on the reference.

Operations

The operations for the type are listed under this heading. The following table describes the information presented for each operation:

Description of the reference return type: Identifies the type of the value returned by the operation. The default multiplicity is exactly one; only other multiplicities are stated. This row is omitted if the operation does not return a value. isQuery: Indicates that the operation will not change the state (attribute and reference values) of an object. This row is omitted if the operation can change the state of an object. scope: Type scope indicates that the operation is available without requiring an instance of the type; instance scope operations are only accessed through the instances. This row is omitted if the operation is of instance scope.

3-8 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

parameters: Lists the operation parameters and identifies the direction and type for each parameter. If the multiplicity is not exactly one, the multiplicity of the parameter is also given. None – Indicates that the operation has no parameters. exceptions: Lists the exceptions that this operation may raise, in response to error or other abnormal conditions. This row is omitted if the operation cannot raise any exceptions constraints: Identifies any constraints on the operation. The number next to the constraint refers to the OCL representation for that constraint. None – Indicates that there are no constraints on the operation.

Constraints

Constraints on the type as a whole are listed under this heading.

Interface

The IDL interface for the type appears under this heading.

OCL

The OCL representation of any constraints defined on the type or its features appears under this heading.

3.6.2 Associations Associations, which define potential links between objects, are described in Section 6.2.1 Associations. An association is defined between the two types of objects which can be linked. In some cases, the association is defined for a single type to allow objects of that type to be linked together. The document sections are labeled with the names of the associations and the types at both ends.

An association is defined by its ends and constraints as follows.

Ends

The ends for the association are listed under this heading. The following table describes the information presented for each operation:

Description of the reference

9/1/97 Meta Object Facility 1.1 3-9 Section 3. MOF Model and Interfaces

type: Identifies the type of objects that can be linked in links of the association, according to this end multiplicity: Identifies constraints on the set of values held by the end. The MultiplicityType (see Section 3.9.2.1 MultiplicityType) can constrain the upper and lower bounds and whether the collection must maintain an order. If there is no required ordering, nothing is stated; ordering is also omitted for single-valued end. Rather than specifying the cardinality constraints through the upper and lower bounds values, most references are specified as exactly one, zero or one, one or more, or zero or more. aggregation: Indicates that this end defines an aggregation (shared or composite). A composition defines a form or strict containment, or ownership. This row is omitted if the end does not define an aggregation. constraints: Identifies any constraints on this association end. The number appearing next to the constraint is a reference the OCL representation. This row is omitted if there are no constraints on this end.

Constraints

Constraints on the association as a whole are listed under this heading.

Interface

The IDL interface for the type appears under this heading.

OCL

The OCL representation of any constraints defined on the type or its features appears under this heading.

3.7 MOF Model Types Figure 3-2shows the structure of the MOF Model Package, including the types, generalizations, and associations the package contains. To reduce complexity, the figure does not include the type features.

Five additional figures present detailed views of selected elements in the model package. Figure 3-3 shows the base classes that support the MOF Model. Figure 3-4 shows Classifier elements. Figure 3-5 shows feature elements. Figure 3-6 shows elements supporting associations. Figure 3-7 shows packaging elements. Figure 3-8 shows the remaining elements in the model package.

3-10 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Note: The grouping of types in these figures is for presentation purposes only—the groups do not represent the actual packaging. Neither does the order in the elements are presented specifically the order in which elements appear in the containment hierarchy.

9/1/97 Meta Object Facility 1.1 3-11 Section 3. MOF Model and Interfaces exposedEnd 1 AssociationEnd 1 Parameter

/Exposes referencedEnd TypeAlias referrer 0..* RefersTo

TypedElement 0..* 0..* referent Constant Reference

StructuralFeature MofAttribute

Feature 0..* Tag MofException

AttachesTo

IsOfType 0..* {ordered}

CanRaise BehavioralFeature 0..*

Constrains 0..* Constraint Operation 1..* constrainedElement 1..* Class 1 type

Namespace

ModelElement 1 0..* 0..* 0..* {ordered} Classifier DataType 0..1 dependent imported container provider

Aliases containedElement {ordered} GeneralizableElement

Contains 0..*

/DependsOn Association 0..* 0..* importer supertype Package subtype Import

Generalizes

Figure 3-2. The MOF Model Package

3-12 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

dependent 0..* ModelElement /DependsOn provider name : NameType annotation : AnnotationType 0..* / qualifiedName : NameTypeSeq

verify( ) isFrozen( ) setName( ) containedElement findRequiredElements( ) 0..* isVisible( ) isRequiredBecause( ) {ordered} removeElement( ) copyElement( )

Contains

Namespace container lookupElement( ) 0..1 resolveQualifiedName( ) nameIsValid( ) findElementsByType( )

0..* supertype {ordered} GeneralizableElement Generalizes TypedElement visibility : VisibilityKind isAbstract : boolean subtype isRoot : TristateKind isLeaf : TristateKind 0..* 0..* / allSupertypes : GeneralizableElementSeq IsOfType lookupElementsExtended( ) findElementsByTypeExtended( ) resolveQualifiedNameExtended( )

type

Classifier 1

Figure 3-3. Base Abstractions of the MOF Model Package

3.7.1 ModelElement abstract ModelElement classifies the elementary, atomic constructs of models. ModelElement is the root type within the MOF Model. Its supertype is not specific to MOF Model and can be reused to provide reflective capabilities for other models as described in Section 5 Reflective Package Types. The RefObject supertype is not modeled, so the generalization is only realized at model elaboration.

Supertypes

Reflective::RefObject

Contained Elements

None (not a Namespace)

9/1/97 Meta Object Facility 1.1 3-13 Section 3. MOF Model and Interfaces

Attributes

name

Identifies and describes the ModelElement. A name must be defined for each ModelElement. type: NameType multiplicity: exactly one changeable: no (only through the setName operation)

annotation

Provides additional descriptive information for the ModelElement. The annotation value is not interpreted by the MOF. The annotation attribute is required, but its value can be an empty string. type: AnnotationType multiplicity: exactly one

qualifiedName

Provides the unique name for the ModelElement within a repository. The qualifiedName is composed of the ModelElement name, its containing element name, that containing element name for that element, and so on up to a Namespace that is not contained. The sequence of names starts with the top-most, uncontained Package and ends with the name of this ModelElement. type: NameType multiplicity: one or more; ordered; non-unique changeable: no derived from: This attribute is derived from the name of the ModelElement, the reference to its container (applied recursively), and the names of those ModelElements.

References

container

3-14 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Identifies the Namespace that contains the ModelElement. Every ModelElement must be contained in a single Namespace, except for top-level Packages. type: Namespace defined by: The NamespaceContainsModelElement association and its container end multiplicity: zero or one inverse: The Namespace containing the ModelElement knows the ModelElement through its contents reference. constraint: A ModelElement that is not of type Package must have a container (multiplicity of one). A Package that is a nested package has a container. A Package that is a top-level package may not have a container. [1]

requiredElements

Identifies the ModelElements on which the definition of this ModelElement depends. These dependencies are completely described below. type: ModelElement defined by: the ModelElement-DependsOn-ModelElementassociation and its provider end multiplicity: zero or more derived from: The associations identified by the DependsOn association.

constraints

Identifies the set of limitations or conditions, if any, applying to the ModelElement. A constraint holds over the ModelElement and the ModelElement must obey a constraint. type: Constraint multiplicity: zero or more inverse: A constraint which constrains a ModelElement references that ModelElement as one of its constrainedElements.

9/1/97 Meta Object Facility 1.1 3-15 Section 3. MOF Model and Interfaces

Operations

verify

Each ModelElement is capable of checking its own correctness, as defined by the inherent properties of metamodels described in this specification, and constraints that hold over the ModelElement. The client of the operation specifies whether the operation should propagate to any ModelElements that this ModelElement might contain (if it is capable of containing elements), or whether it should return after only checking itself. The verify operation checks inherent constraints on the object and its attributes plus any constraints contained by the object.. The operation returns valid if all verification checks passed; otherwise it returns invalid. A parameter returns representations of any constraint violations detected. If the operation returns invalid, this parameter must not be empty. When the depth argument is deep, and this element (and, by definition, all its dependent elements) are published, the operation returns published. return type: VerificationResultKind (enumeration with values {valid, invalid, published}) parameters: depth: in DepthType (enumeration with values {shallow, deep}) violations: out ConstraintViolation (multiplicity: zero or more; ordered; unique)

isFrozen

Reports the freeze status of a ModelElement. A ModelElement, at any particular time, is either frozen or not frozen. All ModelElements of a published model are permanently frozen. return type: boolean isQuery: yes

setName

Provides the only means of changing the name of an existing ModelElement. parameters: newName : in NameType constraints: constraints are defined on the Namespace-Contains-ModelElement association, which may be violated as a consequence of this operation

3-16 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

findRequiredElements

Supports selecting a subset of the dependents, based on the kind of dependency. In addition, this operation can return the transitive closure of all required elements, when the argument recursive is set to true. Setting the kinds parameter to all, the operation can take advantage of the recursive find, without restricting to specific dependency kinds. This operation is more powerful than the requiredElements reference. return type: ModelElement (multiplicity: zero or more; unordered) isQuery: yes parameters: kinds : in DependencyKind (multiplicity: one or more; unordered; not unique) recursive : in boolean

isVisible

Determines whether the supplied ModelElement is visible to this ModelElement. If necessary, the operation searches through the transitive closure of the ModelElements that are visible to this ModelElement. For a complete description on visibility rules, and their implication on building models, see Section 6.5 Rules of Importing and Visibility. return type: boolean isQuery: yes parameters: otherElement : in ModelElement

isRequiredBecause

Determines whether the supplied ModelElement is required by this ModelElement, according to the DependsOn derived association. If the supplied ModelElement is required by this ModelElement, this operation returns the kind of dependency. If the supplied ModelElement is indirectly required by this ModelElement through transitivity, the dependency is categorized as indirect. If the supplied ModelElement is not required by this ModelElement, the reason output argument is an empty string. return type: boolean isQuery: yes parameters: reason : out DependencyKind

9/1/97 Meta Object Facility 1.1 3-17 Section 3. MOF Model and Interfaces

removeElement

Removes this ModelElement from existence (from the perspective of the modeler). In doing so, this operation removes the Link between the ModelElement and its container. The operation also removes the Link between this ModelElement and its class-level representation (which keeps track of all of its instances in the MofRepository). For each attribute of this element which contains one or more ModelElements, this removeElement operation is invoked. For each reference of this element, the corresponding Link is removed, and the referenced element may have the removeElement operation invoked, depending on the defined aggregation of the reference (See Section 6.2.3 Aggregations). If this ModelElement is linked to an element in another ModelRepository, the removeElement operation could result in a dangling Link. See Section 6.7.2 Defining Models across Repositories for a discussion of such issues return type: none parameters: none needed

copyElement

Supports the copying of a model. This operation is not intended for users of the MOF. return type: ModelElement parameters: container : in Namespace

Constraints

The attribute values of a ModelElement which is frozen cannot be have the values of its attributes changed. This constraint applies to all subtypes of ModelElement, and constrains all their attributes as well. [2]

A Link cannot be changed or removed if both a ModelElement which is frozen is connected and that ModelElement has a Reference corresponding to that Link; also a new Link cannot be created which connects a ModelElement which is frozen if the ModelElement has a Reference corresponding to the candidate new Link. [3]

Interface

interface ModelElementClass : Reflective::RefObject { readonly attribute ModelElementUList all_of_kind_model_element;

const string name_must_be_corba_compliant =

3-18 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

"::Model::ModelElement::name_must_be_corba_compliant"; const string must_be_contained_unless_package = "::Model::ModelElement::must_be_contained_unless_package"; const string update_to_frozen_model_element = "::Model::ModelElement::update_to_frozen_model_element"; const string containment_dep = "containment"; const string signature_dep = "signature"; const string constraint_dep = "constraint"; const string specialization_dep = "specialization"; const string typedefinition_dep = "type definition"; const string indirect_dep = "indirect";

typedef string DependencyKind; typedef sequence <::Model::ModelElementClass::DependencyKind> DependencyKindSet; enum VerifyResultKind { valid, published, invalid }; enum DepthKind { shallow, deep };

}; // end of interface ModelElementClass

interface ModelElement : ModelElementClass { NameType name () raises (Reflective::StructuralError, Reflective::SemanticError); NameTypeList qualified_name () raises (Reflective::SemanticError); void set_name (in NameType new_name) raises (Reflective::SemanticError); AnnotationType annotation () raises (Reflective::StructuralError, Reflective::SemanticError); void set_annotation (in AnnotationType new_value) raises (Reflective::SemanticError); ModelElementSet required_elements () raises (Reflective::SemanticError); void set_required_elements (in ModelElementSet new_values) raises (Reflective::StructuralError, Reflective::SemanticError); void add_required_elements (in ModelElement new_value) raises (Reflective::StructuralError, Reflective::SemanticError); void modify_required_elements (in ModelElement old_value, in ModelElement new_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove_required_elements (in ModelElement old_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); ModelElementSet find_required_elements ( in ModelElementClass::DependencyKindSet kinds, in boolean recursive) raises (Reflective::SemanticError); boolean is_required_because (in ModelElement other, out ModelElementClass::DependencyKind kind) raises (Reflective::SemanticError); Namespace container () raises (Reflective::NotSet, Reflective::SemanticError); void set_container (in Namespace new_value)

9/1/97 Meta Object Facility 1.1 3-19 Section 3. MOF Model and Interfaces

raises (Reflective::SemanticError); void unset_container () raises (Reflective::SemanticError); ConstraintSet constraints () raises (Reflective::SemanticError); void set_constraints (in ConstraintSet new_values) raises (Reflective::StructuralError, Reflective::SemanticError); void add_constraints (in Constraint new_value) raises (Reflective::StructuralError, Reflective::SemanticError); void modify_constraints (in Constraint old_value, in Constraint new_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove_constraints (in Constraint old_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); ModelElementClass::VerifyResultKind verify ( in ModelElementClass::DepthKind depth, out ::Model::ConstraintViolationSet problems) raises (Reflective::SemanticError); boolean is_frozen () raises (Reflective::SemanticError); boolean is_visible (in ModelElement other_element) raises (Reflective::SemanticError); };

OCL

[1] ModelElement not self.oclIsTypeOf(Package) implies self.container->size = 1 and self. isTypeOf(Package) implies self.container->size < 2

[2] ModelElement –- not expressable in OCL: if self.is_frozen, then: every attribute of ModelElement, and of any ModelElement subtypes for which this object is an isntance, are immutable; also this object can only be removed through removal of its container.

[3] ModelElement –- not expressable in OCL: if self.is_frozen, then: for each Reference of self.object_type, the links corresponding to each reference are immutable; the may only be removed when this object is deleted.

3-20 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

3.7.2 Namespace abstract The Namespace type classifies and characterizes ModelElements that can contain other ModelElements. Along with containing the ModelElements, a Namespace defines a namespace—the allowable set of names and the naming constraints—for these elements.

Subtypes of the Namespace type have mechanisms for effectively extending their namespace, without actually containing additional ModelElements. Thus Namespace can be viewed in terms of its two roles, as a container and as a namespace mechanism. Because only subtypes extend the namespace, the namespace and contents are coincident in the definition of the Namespace type. Each Namespace has four collections (the latter three derivable) that are of general interest in defining the constraints of the MOF Model. These collections are

• The contents (sometimes referred to in this submission as the direct contents), which are defined by the contents reference • All contents—the transitive closure on the contents reference • The extended namespace—the contents plus elements included by extension, which Namespace subtypes accomplish through generalization and importation • The extended contents—the transitive closure on the contents reference applied to the extended namespace

For complete definitions of these collections, see Section 6.5.1 Namespace Extension through Generalization and Importing.

For the definition of Namespace itself, in contrast to its subtypes, the extended namespace is equal to the contents, and the extended contents is equal to all contents.

Supertypes

ModelElement

Contained Elements

Not Applicable (abstract type)

Attributes

None

9/1/97 Meta Object Facility 1.1 3-21 Section 3. MOF Model and Interfaces

References

contents

Identifies the set of ModelElements that a Namespace contains. type: ModelElement defined by: The Namespace-Contains-ModelElementassociation and its containedElement end. multiplicity: zero or more; ordered inverse: A ModelElement contained by a Namespace references that Namespace as its container. constraint: Each subtype of Namespace has specific constraints on what subtypes of ModelElement it can contain. These constraints are described by the Contains association.

Operations

lookupElement

Searches for a contained element with the designated name. If the operation finds a ModelElement, referenced by container, which has a name equal to the supplied name, the operation returns that element. Otherwise, no element is returned. return type: ModelElement (multiplicity zero or one) isQuery: yes parameters: name : in NameType

resolveQualifiedName

Searches for a contained element with the designated qualified name. Depth of the target ModelElement within the containment hierarchy, with respect to this Namespace, must match the number of names in the NameType list. return type: ModelElement (exactly one). If no element is found, an exception is raised. isQuery: yes parameters: qualifiedName : in NameType (multiplicity one or more; ordered; not unique) exceptions: NameNotResolved

3-22 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

nameIsValid

Determines whether the specified name can be used within the namespace. The operation verifies that the name is valid according to the constraint on names and that the name is not already used within the namespace. The operation returns true only if both conditions are met. The nameIsValid operation supports renaming ModelElements return type: boolean isQuery: yes parameters: proposedName : in NameType

findElementsByType

Returns all the ModelElements identified by the contents reference defined for this Namespace that are of the type supplied. The returned list of ModelElements is a subset of the ModelElements contained by this Namespace. This operation can either return only those ModelElements that exactly match the specified type or those ModelElements that are instances of the specified type and one or more of its subtypes. Because ModelElement is an abstract type, invoking this operation with the ofType argument specified as ModelElement and the includeSubtypes argument set to false returns an empty list. Because ModelElement is the base type for all instances which can be contained by a Namespace, Invoking the operation with the ofType argument specified as ModelElement and includeSubtypes set to true returns all the contained elements of the Namespace. return type: ModelElement (multiplicity zero or more; ordered; unique) isQuery: yes parameters: ofType : in Class includeSubtypes : in boolean

Constraints

None

Interface

interface NamespaceClass : ModelElementClass { readonly attribute NamespaceUList all_of_kind_namespace;

const string namespace_does_not_contain_itself =

9/1/97 Meta Object Facility 1.1 3-23 Section 3. MOF Model and Interfaces

"::Model::Namespace::namespace_does_not_contain_itself"; const string namespace_contents_have_unique_names = "::Model::Namespace::namespace_contents_have_unique_names";

exception NameNotFound { NameType name; }; exception NameNotResolved { NameType missing_name; NameTypeList resolved_part; }; exception BadKindString {}; }; // end of interface NamespaceClass

interface Namespace : NamespaceClass, ModelElement { ModelElementUList contents () raises (Reflective::SemanticError); void set_contents (in ModelElementUList new_values) raises (Reflective::StructuralError, Reflective::SemanticError); void add_contents (in ModelElement new_value) raises (Reflective::StructuralError, Reflective::SemanticError); void add_contents_before (in ModelElement new_value, in ModelElement before) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_contents (in ModelElement old_value, in ModelElement new_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove_contents (in ModelElement old_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); ModelElement lookup_element (in NameType name) raises (NamespaceClass::NameNotFound, Reflective::SemanticError); ModelElement resolve_qualified_name (in NameTypeList qualified_name) raises (NamespaceClass::NameNotResolved, Reflective::SemanticError); ModelElementUList find_elements_by_type (in Class of_type, in boolean include_subtypes) raises (Reflective::SemanticError); boolean name_is_valid (in NameType proposed_name) raises (Reflective::SemanticError); };

OCL

None

3.7.3 GeneralizableElement abstract The GeneralizableElement type classifies and characterizes ModelElements that can be generalized through supertyping and specialized through subtyping. A GeneralizableElement inherits the features of each of its supertypes, the features of the

3-24 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

supertypes of the immediate supertypes, and so on – all the features of the transitive closure of all the supertypes of the GeneralizableElement.

When a GeneralizableElement inherits a feature, that feature name effectively becomes part of the namespace for the GeneralizableElement and the feature is considered part of the extended namespace of the Namespace. Therefore, a GeneralizableElement cannot have a supertype if it causes an inherited feature to have a namespace collision with its own features. [4]

To the degree that a GeneralizableElement is defined by its features, the supertype/subtype association defines substitutability. Any instance of a GeneralizableElement can be supplied wherever an instance of a supertype of that GeneralizableElement is expected.

Supertypes

Namespace

Contained Elements

Not Applicable (abstract type)

Attributes

visibility

Defines the ability of ModelElements outside of the containing Namespace for the GeneralizableElement to access the GeneralizableElement. The three levels of visibility are as follows: • public, which grants access to the GeneralizableElement • private, which denies access to the GeneralizableElement • protected, which denies access to the GeneralizableElement, but grants access to subtypes (direct and indirect) of the GeneralizableElement directly containing this GeneralizableElement. For the complete rules of visibility, see Section 6.5 Rules of Importing and Visibility. type: VisibilityType (enumeration type with values {public, private, protected}) multiplicity: exactly one

9/1/97 Meta Object Facility 1.1 3-25 Section 3. MOF Model and Interfaces

isAbstract

Indicates whether the GeneralizableElement is expected to have instances. When isAbstract is true, any instance which is represented or classified by this GeneralizableElement is additionally an instance of some specialization of this GeneralizableElement. No operation should be available which supports creation of instances of this GeneralizableElement. type: boolean multiplicity: exactly one

isRoot

Indicates whether the set of supertypes for a GeneralizableElement can or must contain elements. If the isRoot value is set to yes, the set of supertypes for the GeneralizableElement must be empty. If the isRoot value is set to no, the set of supertypes must contain at least one supertype. This attribute is a constraint on the supertype reference for the GeneralizableElement, not a derived attribute based on the reference. type: TristateType (enumeration with values {yes, no, dont_care}) multiplicity: exactly one

isLeaf

Indicates whether a GeneralizableElement can be the supertype end in the Generalizes association. If the isLeaf value is yes, the GeneralizableElement cannot be a participant in the Generalizes association as a supertype end. If the isLeaf value is no, the GeneralizableElement must be in at least one link defined by the Generalizes association through a LinkEnd defined by the supertype end. The isLeaf attribute is a constraint on the GeneralizableElement ; it is not a derived attribute based on the current Links. type: TristateType (enumeration with values {yes, no, dont_care}) multiplicity: exactly one

3-26 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

allSupertypes

Provides both the supertypes references, which are direct supertypes of the GeneralizableElement, and the indirect supertypes of the GeneralizableElement. An indirect supertype is a supertype of another direct or indirect supertype of the GeneralizableElement. The order of the GeneralizableElements is determined by a depth-first traversal of the subtypes (with duplicates removed). [5] type: GeneralizableElement multiplicity: zero or more; ordered; unique changeable: no (not through this attribute). derived from: transitive closure of supertypes

References

supertypes

Identifies the set of supertypes for a GeneralizableElement. Note that a GeneralizableElement does not have a reference to its subtypes. It might be possible to identify the subtypes linked by Links of the Generalizes association. However, Links can cross repository boundaries and any objects linked as subtypes would have the corresponding Link in repository containing that subtype. Therefore, it might not be possible to identify all subtypes of this GeneralizableElement. See Section 6.7.2 Defining Models across Repositories for a discussion on issues of Associations across repositories. type: GeneralizableElement defined by: the GeneralizableElement-Generalizes-GeneralizableElement association and its supertype end. multiplicity: zero or more; ordered constraint: Constraints are defined in the Generalizes association.

9/1/97 Meta Object Facility 1.1 3-27 Section 3. MOF Model and Interfaces

Operations

lookupElementExtended

Returns the element whose name matches the provided name. Like findElement defined for Namespace, this operation searches the elements contained by the GeneralizableElement. However, the lookupElementExtended also searches the elements contained by all GeneralizableElement supertypes (direct and indirect) of the GeneralizableElement. Subtypes can include a larger overall are for the lookup. Package, a subtype of GeneralizableElement, also considers the elements brought into this Namespace through the use of the Import type. return type: ModelElement (multiplicity zero or one) isQuery: yes parameters: name : in NameType

findElementsByTypeExtended

Provides an extension of the findElementsByType defined for Namespace so that contained elements of all supertypes (direct and indirect) of the GeneralizableElement are included in the search. The order of the returned elements is determined by the order of the elements contained in the GeneralizableElements and a depth-first traversal of the supertypes. Subtypes can include a larger overall are for the lookup. Package, a subtype of GeneralizableElement, also considers the elements brought into this Namespace through the use of Import return type: ModelElement (multiplicity zero or more; ordered; unique) isQuery: yes parameters: ofType : in Type includeSubtypes : in boolean

Constraints

None

Interface

interface GeneralizableElementClass : NamespaceClass { readonly attribute GeneralizableElementUList

3-28 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

all_of_kind_generalizable_element;

const string supertype_contents_must_be_unique = "::Model::GeneralizableElement::supertype_contents_must_be_unique"; const string supertypes_must_obey_diamond_rule = "::Model::GeneralizableElement::supertypes_must_obey_diamond_rule"; const string supertype_must_not_be_self = "::Model::GeneralizableElement::supertype_must_not_be_self"; const string supertype_is_of_the_same_type = "::Model::GeneralizableElement::supertype_is_of_the_same_type"; const string supertype_visible_from_subtype = "::Model::GeneralizableElement::supertype_visible_from_subtype"; const string is_root_yes_implies_no_supertypes = "::Model::GeneralizableElement::is_root_yes_implies_no_supertypes"; const string is_root_no_implies_supertypes = "::Model::GeneralizableElement::is_root_no_implies_supertypes"; const string is_leaf_yes_implies_no_subtypes = "::Model::GeneralizableElement::is_leaf_yes_implies_no_subtypes"; const string is_leaf_no_implies_subtypes = "::Model::GeneralizableElement::is_leaf_no_implies_subtypes"; }; // end of interface GeneralizableElementClass

interface GeneralizableElement : GeneralizableElementClass, Namespace { TristateKind is_root () raises (Reflective::StructuralError, Reflective::SemanticError); void set_is_root (in TristateKind new_value) raises (Reflective::SemanticError); void set_is_leaf (in TristateKind new_value) raises (Reflective::SemanticError); boolean is_abstract () raises (Reflective::StructuralError, Reflective::SemanticError); void set_is_abstract (in boolean new_value) raises (Reflective::SemanticError); VisibilityKind visibility () raises (Reflective::StructuralError, Reflective::SemanticError); void set_visibility (in VisibilityKind new_value) raises (Reflective::SemanticError); GeneralizableElementUList supertypes () raises (Reflective::SemanticError); void set_supertypes (in GeneralizableElementUList new_values) raises (Reflective::StructuralError, Reflective::SemanticError); void add_supertypes (in GeneralizableElement new_value) raises (Reflective::StructuralError, Reflective::SemanticError); void add_supertypes_before (in GeneralizableElement new_value, in GeneralizableElement before) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_supertypes (in GeneralizableElement old_value, in GeneralizableElement new_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove_supertypes (in GeneralizableElement old_value) raises (Reflective::StructuralError, Reflective::NotFound,

9/1/97 Meta Object Facility 1.1 3-29 Section 3. MOF Model and Interfaces

Reflective::SemanticError); GeneralizableElementSet all_supertypes () raises (Reflective::SemanticError); ModelElement lookup_element_extended (in NameType name) raises (Reflective::SemanticError); ModelElementUList find_elements_by_type_extended (in NameType name) raises (Reflective::SemanticError); };

OCL

[4] GeneralizableElement self.allSupertypes-> forAll(s | s.contents->forAll(superC | self.contents-> forAll(selfC | superC.name.toUpper <> selfC.name.toUpper))))

[5] GeneralizableElement allSupertypes : Sequence(GeneralizableElement) -- defines a specific order allSuperTypes = self.supertypes-> collect(s | { s }->union(s.allSupertypes))->asSet->asSequence -- convert to set and back to sequence removed dups and preserve order -- alternatively, express as the sequence minus the intersection of -- the sequence and the ->asSet of the sequence

3.7.4 TypedElement The TypedElement type is an abstraction of ModelElements who require a type as part of their definition. A TypedElement does not itself define a Type, but relies on a Type for a portion of its definition, through a link with a Classifier.

Supertypes

ModelElement

Contained Elements

None (not a Namespace)

Attributes

None

3-30 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

References

type

Provides the representation of the type supporting the TypedElement through this reference. type: Classifier defined by: the TypedElement-IsOfType-Classifier association and its type end. multiplicity: exactly one constraints: see the TypedElement-IsOfType-Classifier association

TypedElement

GeneralizableElement 0..*

type IsOfType Classifier 1

DataType Class typeCode : TypeDescriptor isSingleton : boolean

Figure 3-4. MOF Model Classifiers

Operations

None

Constraints

None

9/1/97 Meta Object Facility 1.1 3-31 Section 3. MOF Model and Interfaces

Interface

interface TypedElementClass : ModelElementClass { // get all typed_element including subtypes of typed_element readonly attribute TypedElementUList all_of_kind_typed_element;

const string type_visible_from_typed_element = "::Model::TypedElement::type_visible_from_typed_element"; }; // end of interface TypedElementClass

interface TypedElement : TypedElementClass, ModelElement { Classifier type () raises (Reflective::SemanticError); void set_type (in Classifier new_value) raises (Reflective::SemanticError); };

OCL

None

3.7.5 Classifier abstract A classifier provides a classification of instances through a set of Features it contains.

Supertypes

GeneralizableElement

Contained Elements

Not Applicable (abstract type)

Attributes

None

References

None

Operations

None

3-32 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Constraints

None

Interface

interface ClassifierClass : GeneralizableElementClass { readonly attribute ClassifierUList all_of_kind_classifier; }; // end of interface ClassifierClass

interface Classifier : ClassifierClass, GeneralizableElement { };

OCL

None

3.7.6 Class A Type defines a classification over a set of object instances by defining the behavior they exhibit. This behavior is represented through operations, attributes, references, participation in associations, nested types, constants, and constraints. Although the same or similar elements are used in other environments for representing Classes and their implementations, in the MOF these elements specify the type characteristics in an implementation-independent manner. For instance, defining a Type as having an attribute does not require the implementation of the Type (the software which provides the type- conformant behavior) to have an attribute, to hold the attribute value, etc. The implementation simply must insure that the behavior conforms to the definition of the attribute. The use of all the additional elements beyond operations provides a much richer environment for defining Type behavior. Likewise, this construct is not an interface. Its expressibility goes beyond interface representations. The MOF’s IDL translation capabilities map a single Type onto two interfaces. It would be possible to define transformations to alternate interface representations, such as Java’s interfaces.

There are – an probably always will be – divergent views among industry leaders on the definition of the concepts of Class, Type, and Interface. As a domain-specific modeling environment, so long as the MOF is clear about the meaning of Type within the MOF, it should remain immune from such concerns.

Supertypes

Classifier

Contained Elements

Type

9/1/97 Meta Object Facility 1.1 3-33 Section 3. MOF Model and Interfaces

DataType MofAttribute Reference Operation MofException Constraint Constant Tag [6]

Attributes

isSingleton

When a type has isSingleton with a value of true, it is constrained to at most one object instance, within the boundary of a model repository (for a description of model repositories, see Section 4 Facility Package). This constraint does not apply to subtypes of the type. A value of false for isSingleton does not constrain the type. [7] type: boolean multiplicity: exactly one constraints: a type which is abstract cannot be defined as singleton. [8]

References

None

Operations

None

Constraints

None

Interface

interface ClassClass : ClassifierClass { readonly attribute ClassUList all_of_kind_class; readonly attribute ClassUList all_of_type_class;

3-34 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

const string abstract_implies_not_singleton = "::Model::Class::abstract_implies_not_singleton"; const string type_containment_rules = "::Model::Class::type_containment_rules";

Class create_class ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from GeneralizableElement */ in ::Model::TristateKind is_root, /* from GeneralizableElement */ in ::Model::TristateKind is_leaf, /* from GeneralizableElement */ in boolean is_abstract, /* from GeneralizableElement */ in ::Model::VisibilityKind visibility, /* from Class */ in boolean is_singleton) raises (Reflective::SemanticError); }; // end of interface ClassClass

interface Class : ClassClass, Classifier { boolean is_singleton () raises (Reflective::StructuralError, Reflective::SemanticError); void set_is_singleton (in boolean new_value) raises (Reflective::SemanticError); };

OCL

[6] Class (self.contents - { Class, DataType, MofAttribute, Reference, Operation, MofException, Constraint })->isEmpty

[7] Class self.isSingleton implies self.AllInstances < 2

[8] Class self.isAbstract implies self.isSingleton = false

3.7.7 DataType Each DataType instance represents a data type. A data type is a classification of values or non-object instances. This type, DataType, is not itself a data type, since its instances are objects representing different data types.

Supertypes

Classifier

9/1/97 Meta Object Facility 1.1 3-35 Section 3. MOF Model and Interfaces

Contained Elements

TypeAlias Constraint Tag [9]

Attributes

typeCode

The typeCode distinguishes data types. This attribute is defined as the type TypeDescriptor, a type which must be mapped to a specific type appropriate for the interface and implementation type systems. The CORBA data type definition capability is employed, so that any valid CORBA TypeCode can be used, with the exceptions of those where invoking the kind() operation would return tk_void, tk_principal, or tk_except. Because a data type can be constructed of other data types, as structs, typedefs, and arrays, a DataType instance may depend on the definition of other DataTypes or Types in the Model. DataTypes contain TypeAlias objects to represent these dependencies on other ModelElements. Dependencies on primitive data types and external data types are not referenced with TypeAliases. The use of CORBA TypeCodes and MOF TypeAliases is described in 6.3 MOF Data Type Encoding and Translation Conventions. type: TypeDescriptor multiplicity: exactly one constraints: The typeCode cannot be of kind tk_void, tk_principal, or tk_except, nor can any typecode which it uses as its content_type, discriminator_type, or member_type. [10] Any typecode which is the content_type, discriminator_type, or a member_type of this typeCode must be one of: • A primitive typecode; • Represented with an instance of TypeAlias, contained by this DataType instance, with a RepositoryId uniquely identifying the TypeAlias; or • A representation of an external type, or data type [11]

3-36 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

ModelElement

TypedElement Namespace

Feature visibility : VisibilityKind scope : ScopeKind

StructuralFeature BehavioralFeature multiplicity : MultiplicityType isChangeable : boolean

MofAttribute Reference Operation CanRaise MofException isDerived : boolean isQuery : boolean 0..* 0..* {ordered}

Figure 3-5. Feature Types of the MOF Model

References

None

Operations

None

Constraints

None

9/1/97 Meta Object Facility 1.1 3-37 Section 3. MOF Model and Interfaces

Interface

interface DataTypeClass : ClassifierClass { readonly attribute DataTypeUList all_of_kind_data_type; readonly attribute DataTypeUList all_of_type_data_type;

const string data_type_is_not_abstract = "::Model::DataType::data_type_is_not_abstract"; const string data_type_allowable_typecode_kinds = "::Model::DataType::data_type_allowable_typecode_kinds"; const string typecode_directly_embedded_types_represented = "::Model::DataType::typecode_directly_embedded_types_represented"; const string data_type_containment_rules = "::Model::DataType::data_type_containment_rules";

DataType create_data_type ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from GeneralizableElement */ in ::Model::TristateKind is_root, /* from GeneralizableElement */ in ::Model::TristateKind is_leaf, /* from GeneralizableElement */ in boolean is_abstract, /* from GeneralizableElement */ in ::Model::VisibilityKind visibility, /* from DataType */ in TypeCode type_code) raises (Reflective::SemanticError); }; // end of interface DataTypeClass

interface DataType : DataTypeClass, Classifier { TypeCode type_code () raises (Reflective::StructuralError, Reflective::SemanticError); void set_type_code (in TypeCode new_value) raises (Reflective::SemanticError); };

OCL

[9] DataType (self.contents - Set{ TypeAlias, Tag })->isEmpty

required operation -- return the typecode and all the embedded typecodes TypeCode allTypes : Set(TCKind) allTypes = { self.kind }->union( if Set{tk_struct, tk_union, tk_except}->includes(self.kind) then self.member_types->collect(mt | mt.allTypes)-> union( if self.kind = tk_union then self.discriminator_type.allTypes else { } endif

3-38 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

) else if Set{tk_sequence, tk_array, tk_alias}->includes(self.kind) then self.content_type.allTypes else { } endif

[10] DataType self.typeCode.allTypes-> intersection({ tk_void, tk_principal, tk_except })->isEmpty

[11] DataType -- because foreign type cannot be verified, expression -- currently must always evaluate to true self.typeCode.allTypes-> forAll(tc | {set of MOF data type names }->includes(tc.name) or self.contents->select(c | c.isOfType(TypeAlias))-> collect(ta | ta.name)->includes(tc.name) or true)

3.7.8 Feature abstract A Feature defines a characteristic of the ModelElement that contains it. Specifically, Classifiers are defined largely by a composition of Features.

Supertypes

ModelElement

Contained Elements

None (not a Namespace)

Attributes

visibility

The visibility of a Feature defines the ability of ModelElements outside the Namespace containing the Feature to access the feature. A visibility of public grants access to ModelElements outside the namespace directly containing the Feature (subject to other constraints); private visibility denies access to those elements; protected visibility denies access, except for GeneralizableElements which are subtypes (directly or derivable) of the Namespace directly containing the Feature. See the description of visibility in 6.5 Rules of Importing and Visibility.

9/1/97 Meta Object Facility 1.1 3-39 Section 3. MOF Model and Interfaces

type: VisibilityType (enumeration type with values {public, private, protected}) multiplicity: exactly one constraints: none

scope

The scope defines whether a Feature supports the definition of instances of the Classifier owning the Feature or of the Classifier as a whole. When scope is instanceLevel, the Feature is accessed through instances of the Feature’s owning Classifier; when scope is classifier, the Feature is accessed through the Classifier itself (or through its instances). For StructuralFeatures, a scope of instanceLevel indicates that a value represented by the StructuralFeature is associated with each instance of the Classifier; a scope of classifierLevel indicates that the StructuralFeature value is shared by the Classifier and all its instances. type: ScopeType (enumeration type with values {instanceLevel, classifierLevel}) multiplicity: exactly one

References

None

Operations

None

Constraints

None

Interface

interface FeatureClass : ModelElementClass { readonly attribute FeatureUList all_of_kind_feature; }; // end of interface FeatureClass

interface Feature : FeatureClass, ModelElement { ScopeKind scope () raises (Reflective::StructuralError, Reflective::SemanticError);

3-40 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

void set_scope (in ScopeKind new_value) raises (Reflective::SemanticError); VisibilityKind visibility () raises (Reflective::StructuralError, Reflective::SemanticError); void set_visibility (in VisibilityKind new_value) raises (Reflective::SemanticError); };

OCL

None

3.7.9 StructuralFeature abstract A StructuralFeature defines a static characteristic of the ModelElement that contains it. The attributes and references of a type define structural properties which provide for the representation of the state of its instances.

Supertypes

Feature, TypedElement

Contained Elements

None (not a Namespace)

Attributes

multiplicity

Multiplicity defines constraints on the collection of instances or values that a StructuralFeature can hold. Multiplicity defines a lower and upper bound to the cardinality of the collection, although the upper bound can be specified as unbounded. Additionally multiplicity defines two other characteristics of the collection – a constraint on collection member ordering and a constraint on collection member uniqueness. Specifically, Multiplicity contains an isOrdered field. When isOrdered is true, then the ordering of the elements in the set are preserved. Typically, a mechanism is provided for adding elements to the collection positionally. Multiplicity also has an isUnique field. When isUnique is true, then the collection is constrained to hold no more than one of any value or instance. type: MultiplicityType, a struct with fields of lower, upper, isOrdered, and isUnique multiplicity: exactly one

9/1/97 Meta Object Facility 1.1 3-41 Section 3. MOF Model and Interfaces

constraints: see constraints on MultiplicityType

isChangeable

The isChangeable attribute places restrictions on the use of certain operations which could change the set of values or instances of the StructuralFeature, and on the operations which will get generated in IDL or other language generation. For any elaboration, no means are automatically created which provides a means of altering the attribute value. When IDL is generated, for instance, the operations which are normally generated for changing the StructuralFeature will not be generated. However, isChangeable does not actually constrain the StructuralFeature to make it immutable – any operations explicitly defined in a model with may change the StructuralFeature values or instances (assuming the operation would have otherwise been able to do so). type: boolean multiplicity: exactly one

References

None

Operations

None

Constraints

None

Interface

interface StructuralFeatureClass : FeatureClass, TypedElementClass { readonly attribute StructuralFeatureUList all_of_kind_structural_feature;

const string parameter_not_an_association = "::Model::StructuralFeature::parameter_not_an_association"; }; // end of interface StructuralFeatureClass

interface StructuralFeature : StructuralFeatureClass, Feature, TypedElement { boolean is_changeable () raises (Reflective::StructuralError, Reflective::SemanticError); void set_is_changeable (in boolean new_value)

3-42 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

raises (Reflective::SemanticError); };

OCL

None

3.7.10 MofAttribute A MofAttribute (allso called an Attribute in this submission) defines a StructuralFeature which contains values for Classifiers or their instances.

Supertypes

StructuralFeature

Contained Elements

None (not a Namespace)

Attributes

isDerived

A derived attribute is one whose values are not part of the state of the object instance, but instead whose values can be determined or computed. In a sense, all attributes are derived, since it is up to the type’s implementation to hold or calculate the values. However, isDerived, by convention, indicates the derived state is based on other information in the model. Modification of the derived Attribute causes the information upon which the Attribute is derived to be updated. type: boolean multiplicity: exactly one

References

None

9/1/97 Meta Object Facility 1.1 3-43 Section 3. MOF Model and Interfaces

Operations

None

Constraints

None

Interface

interface MofAttributeClass : StructuralFeatureClass { readonly attribute MofAttributeUList all_of_kind_mof_attribute; readonly attribute MofAttributeUList all_of_type_mof_attribute;

MofAttribute create_mof_attribute ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from Feature */ in ::Model::ScopeKind scope, /* from Feature */ in ::Model::VisibilityKind visibility, /* from StructuralFeature */ in boolean is_changeable, /* from MofAttribute */ in boolean is_derived) raises (Reflective::SemanticError); }; // end of interface MofAttributeClass

interface MofAttribute : MofAttributeClass, StructuralFeature { boolean is_derived () raises (Reflective::StructuralError, Reflective::SemanticError); void set_is_derived (in boolean new_value) raises (Reflective::SemanticError); };

OCL

None

3.7.11 Reference A Reference defines a Classifier’s knowledge of and access to links and their instances defined by an Association. Although a Reference derives much of its state from a corresponding AssociationEnd, it provides additional information; therefore the MOF cannot adequately represent some metamodels without this mechanism. The inherited attributes defined in StructuralFeature are all derived. However, it has its own visibility, name, and annotation defined. For further discussion on Reference, is purpose, and how it derives its attributes, see the Section on Associations.

3-44 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Supertypes

StructuralFeature

Contained Elements

None (not a Namespace)

Attributes

None

References

referencedEnd

The referencedEnd of a Reference is the end representing the set of LinkEnds of principle interest to the Reference. The Reference provides access to the instances of that AssociationEnd’s type, which are participants in that AssociationEnd’s Association, connected through that AssociationEnd’s LinkEnds. In addition, the Reference derives the majority of its state information – multiplicity, etc., from that Reference type: AssociationEnd defined by: the Reference-RefersTo-AssociationEnd association and its referencedEnd end. multiplicity: exactly one constraints: defined in the Reference-RefersTo-AssociationEnd association

exposedEnd

The exposedEnd of a Reference is the AssociationEnd representing the end of the Reference’s owning Classifier within the defining Association. See the discussion in Section 6.2.2 References for a detailed explanation. type: AssociationEnd defined by: the Reference-RefersTo-AssociationEnd association and its exposedEnd end. multiplicity: exactly one constraints: defined in the Reference-Exposes-AssociationEnd association

9/1/97 Meta Object Facility 1.1 3-45 Section 3. MOF Model and Interfaces

Operations

None

Constraints

The multiplicity of a reference is constrained to equal the multiplicity of its referencedEnd. [12]

The scope of a reference is instance-scope (because, as a simplification, all LinkEnds connect instances). [13]

The isChangeable attribute of a reference represents the same value as the isChangeable attribute of its referencedEnd. [14]

A Reference’s type reference must refer to the same Class instance as the type reference of its referencedEnd. [15]

Interface

interface ReferenceClass : StructuralFeatureClass { readonly attribute ReferenceUList all_of_kind_reference; readonly attribute ReferenceUList all_of_type_reference;

const string reference_is_instance_scope = "::Model::Reference::reference_is_instance_scope"; const string referenced_end_type_consistent_with_container = "::Model::Reference::referenced_end_type_consistent_with_container"; const string referenced_end_visible_from_reference = "::Model::Reference::referenced_end_visible_from_reference"; const string changeable_reference_has_changeable_referent = "::Model::Reference::changeable_reference_has_changeable_referent"; const string reference_multiplicity_matches_referenced_end = "::Model::Reference::reference_multiplicity_matches_referenced_end"; const string reference_type_is_referenced_ends = "::Model::Reference::reference_type_is_referenced_ends";

Reference create_reference ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from Feature */ in ::Model::ScopeKind scope, /* from Feature */ in ::Model::VisibilityKind visibility, /* from StructuralFeature */ in boolean is_changeable) raises (Reflective::SemanticError); }; // end of interface ReferenceClass

interface Reference : ReferenceClass, StructuralFeature { AssociationEnd exposed_end () raises (Reflective::SemanticError); void set_exposed_end (in AssociationEnd new_value) raises (Reflective::SemanticError);

3-46 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

AssociationEnd referenced_end () raises (Reflective::SemanticError); void set_referenced_end (in AssociationEnd new_value) raises (Reflective::SemanticError); };

OCL

[12] Reference self.muliplicity = self.referencedEnd.multiplicity

[13] Reference self.scope = instance_level

[14] Reference self.isChangeable = self.referencedEnd.isChangeable

[15] Reference self.type = self.referencedEnd.type

3.7.12 BehavioralFeature abstract A BehavioralFeature defines a dynamic characteristic of the ModelElement that contains it. Because a BehavioralFeature is partially defined by the Parameters it contains, it is both a Feature and a Namespace

Supertypes

Feature, Namespace

Contained Elements

Not Applicable (abstract type)

Attributes

None

References

None

9/1/97 Meta Object Facility 1.1 3-47 Section 3. MOF Model and Interfaces

Operations

None

Constraints

None

Interface

interface BehaviouralFeatureClass : FeatureClass, NamespaceClass { readonly attribute BehaviouralFeatureUList all_of_kind_behavioural_feature; }; // end of interface BehaviouralFeatureClass

interface BehaviouralFeature : BehaviouralFeatureClass, Feature , Namespace {};

OCL

None

3.7.13 Operation An Operation defines a dynamic feature which offers a service. The behavior of an operation is activated through the invocation of the operation.

Supertypes

BehavioralFeature

Contained Elements

Parameter Constraint [16]

3-48 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Attributes

isQuery

Defining an Operation with a isQuery value of true denotes that the behavior of the operation will not alter the state of the object. The state of a Classifier, for this definition, is the set of values of all of the Classifier’s type-scope and instance-scope StructuralFeatures. For instance, an Operation of a Type, defined with a scope of instance, will not change the values or instances of any instance-scope StructuralFeature of the Type instance, as a result of invoking this Operation; an Operation of a Type with a scope of classifier will not change the values or instances of any of the classifier-scope StructuralFeatures or instance-scope StructuralFeatures. This attribute does not define a constraint enforced by the model, but rather a promise that the operation’s implementation is expected to uphold. An operation which is not defined as isQuery equals false is not guaranteed to change the state of its object. The isQuery constraint does not proscribe any specific implementation, so long as the definition of isQuery above is observed. type: boolean multiplicity: exactly one

References

exceptions

An Operation, upon encountering an error or other abnormal condition, may raise an Exception. The exceptions reference provides the Operation with the set of Exceptions it is allowed to raise. type: MofException defined by: the Operation-Raises-MofException association and its exception end. multiplicity: zero or more constraints: defined in the Reference-RefersTo-AssociationEnd association

Operations

None

9/1/97 Meta Object Facility 1.1 3-49 Section 3. MOF Model and Interfaces

Constraints

In an Operation’s set of Parameters, at most one Parameter may have its direction parameter set to return. [17]

Interface

interface OperationClass : BehavioralFeatureClass { readonly attribute OperationUList all_of_kind_operation; readonly attribute OperationUList all_of_type_operation;

const string operation_has_at_most_one_return_parameter = "::Model::Operation::operation_has_at_most_one_return_parameter"; const string operation_containment_rules = "::Model::Operation::operation_containment_rules"; const string exception_visible_from_operation = "::Model::Operation::exception_visible_from_operation";

Operation create_operation ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from Feature */ in ::Model::ScopeKind scope, /* from Feature */ in ::Model::VisibilityKind visibility, /* from Operation */ in boolean is_query) raises (Reflective::SemanticError); }; // end of interface OperationClass

interface Operation : OperationClass, BehavioralFeature { boolean is_query () raises (Reflective::StructuralError, Reflective::SemanticError); void set_is_query (in boolean new_value) raises (Reflective::SemanticError); MofExceptionUList exceptions () raises (Reflective::ConstraintError, Reflective::SemanticError); void set_exceptions (in MofExceptionUList new_values) raises (Reflective::StructuralError, Reflective::ConstraintError, Reflective::SemanticError); void add_exceptions (in MofException new_value) raises (Reflective::StructuralError, Reflective::ConstraintError, Reflective::SemanticError); void add_exceptions_before (in MofException new_value, in MofException before) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::ConstraintError, Reflective::SemanticError); void modify_exceptions (in MofException old_value, in MofException new_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::ConstraintError, Reflective::SemanticError);

3-50 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

void remove_exceptions (in MofException old_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::ConstraintError, Reflective::SemanticError); };

OCL

[16] Operation (self.contents - { Parameter, Constraint })->isEmpty

[17] Operation self.contents->select(c | c.oclIsTypeOf(Parameter))-> select(p : Parameter | p.direction = return)->size < 2

3.7.14 MofException An MofException (also referred to as Exception) defines an error or other abnormal condition. The Parameters of an Exception hold a record of an occurrence of the exceptional condition.

Supertypes

BehavioralFeature

Contained Elements

Parameter [18]

Attributes

None

References

None

Operations

None

9/1/97 Meta Object Facility 1.1 3-51 Section 3. MOF Model and Interfaces

Constraints

In a MofException’s set of Parameters, the direction attribute of each Parameter is not applicable – each attribute must be each set to out. [19]

Interface interface MofExceptionClass : BehavioralFeatureClass { readonly attribute MofExceptionUList all_of_kind_mof_exception; readonly attribute MofExceptionUList all_of_type_mof_exception;

const string exception_has_only_out_parameters = "::Model::MofException::exception_has_only_out_parameters"; const string exception_containment_rules = "::Model::MofException::exception_containment_rules";

MofException create_mof_exception ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from Feature */ in ::Model::ScopeKind scope, /* from Feature */ in ::Model::VisibilityKind visibility) raises (Reflective::SemanticError); }; // end of interface MofExceptionClass

interface MofException : MofExceptionClass , BehavioralFeature { };

OCL

[18] MofException (self.contents - { Parameter, Constraint })->isEmpty

[19] MofException self. contents->select(c | c.oclIsTypeOf(Parameter))-> forAll(p : Parameter | p.direction = out)

3-52 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

TypedElement

Classifier AssociationEnd multiplicity : MultiplicityType aggregation : AggregationKind referencedEnd isNavigable : boolean RefersTo isChangeable : boolean Association 1 / otherEnd : AssociationEnd referent isDerived : boolean 1 0..* referrer /Exposes Reference exposedEnd 0..*

Figure 3-6. MOF Model Elements for Association

3.7.15 Association An association defines a classification over a set of links, through a relationship between Classifiers. Each link which is an instance of the association denotes a connection between object instances of the Classifiers of the Association. The MOF restricts associations to binary – restricting each link to two participating objects. This restriction also means that the association is defined between two Classifiers (which may be the same Classifier). The name of the Association is considered directional if it provides a clearer or more accurate representation of the association when stated with one participating type first rather than the other. For instance, Operation Raises MofException is correct; MofException Raises Operation is incorrect. The definition of an Association requires two AssociationEnds. If the name of the association is directional, the name is understood to read in the order: first contained element; association name; second contained element. These contained elements are AssociationEnd instances, and the reading of the subject; verb; object uses either the AssociationEnd name or the AssociationEnd’s type name. The onus is on the MOF user to determine whether the name is directional, and place the AssociationEnds in to proper order within the Association’s contents to support the name direction. The representation of a Classifier’s knowledge of its participation in an association requires the use of a Reference.

Supertypes

Classifier

9/1/97 Meta Object Facility 1.1 3-53 Section 3. MOF Model and Interfaces

Contained Elements

AssociationEnd Constraint [20]

Attributes

isDerived

A derived association has no Links as instances. Instead, its Links are derived from other information in a metamodel. The addition, removal, or modification of a derived Association’s Link causes the information upon which the Association is derived to be updated. The results of such an update are expected to appear, upon subsequent access of the derived Association’s Links, to have the same effect as an equivalent operation on an Association which is not derived. type: boolean multiplicity: exactly one

References

None

Constraints

As a simplification, an Association cannot participate in a Generalizes Association; [21] therefore, its isRoot and isLeaf attributes are not applicable (the values are required to be dont_care). [22]

An Association cannot be abstract. [23]

An Association must have a visibility of public. [24]

An Association must contain exactly two AssociationEnd instances. [25]

Interface

interface AssociationClass : ClassifierClass { readonly attribute AssociationUList all_of_kind_association; readonly attribute AssociationUList all_of_type_association; const string association_has_no_supertypes = "::Model::Association::association_has_no_supertypes"; const string association_root_and_leaf_dont_care = "::Model::Association::association_root_and_leaf_dont_care";

3-54 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

const string association_is_not_abstract = "::Model::Association::association_is_not_abstract"; const string association_has_two_ends = "::Model::Association::association_has_two_ends"; const string association_less_than_two_aggregate_ends = "::Model::Association::association_less_than_two_aggregate_ends"; const string association_less_than_two_ordered_ends = "::Model::Association::association_less_than_two_ordered_ends"; const string association_containment_rules = "::Model::Association::association_containment_rules"; const string non_public_association = "::Model::Association::non_public_association";

Association create_association ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from GeneralizableElement */ in ::Model::TristateKind is_root, /* from GeneralizableElement */ in ::Model::TristateKind is_leaf, /* from GeneralizableElement */ in boolean is_abstract, /* from GeneralizableElement */ in ::Model::VisibilityKind visibility, /* from Association */ in boolean is_derived) raises (Reflective::SemanticError); }; // end of interface AssociationClass

interface Association : AssociationClass, Classifier {

boolean is_derived () raises (Reflective::StructuralError, Reflective::SemanticError); void set_is_derived (in boolean new_value) raises (Reflective::SemanticError); };

OCL

[20] Association (self.contents - Set{ AssociationEnd, Constraint })->isEmpty

[21] Association self.supertypes->isEmpty

[22] Association self.isRoot = dont_care and self.isLeaf = dont_care

[23] Association self.isAbstract = false

[24] Association self.visibility = public

[25] Association self.contents->select(c | c.oclIsTypeOf(AssociationEnd))->size = 2

9/1/97 Meta Object Facility 1.1 3-55 Section 3. MOF Model and Interfaces

3.7.16 AssociationEnd An association is composed of two AssociationEnds. Each AssociationEnd defines a Classifier participant in the Association, the role it plays, and constraints on sets of the Classifier instances participating. An instance of an AssociationEnd is a LinkEnd, which defines a relationship between a link – in instance of an Association – and an instance of the AssociationEnd’s Classifier, provided in its type attribute.

Supertypes

TypedElement

Contained Elements

None (not a Namespace)

Attributes

multiplicity

Multiplicity defines constraints on sets of instances. Each instance of the Classifier defined by the opposite AssociationEnd’s type defines a set which this multiplicity attribute constrains. Given one of those instances, x, the set is defined as the instances connected by LinkEnds of this AssociationEnd to that instance x. Refer to 3.9.2.1. MultiplicityType for a description on how the multiplicity attribute constrains a set. In its use is describing AssociationEnds, isUnique has been constrained to be true, as a simplification. This constraint means that the same two instances cannot participate in more than one Link while participating under the same AssociationEnd. Normally, two instances cannot be linked by more than one Link of an Association at all. But when the AssociationEnd types allow the two instances switch ends – they can form a second Link without violating the isUnique constraint. type: MultiplicityType multiplicity: exactly one constraints: for AssociationEnds, isUnique is always true. [26] See specific constraints on values of all MultiplicityType instances

3-56 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

aggregation

Certain associations define aggregations – directional associations with additional implied semantics. The strongest form of aggregation, composition, defines strict containment; The component elements’ lifetimes are bound to their composition. The section on aggregation defines these additional semantics, in 6.2.3. Aggregations. When an AssociationEnd is defined as composite or shared, the instance connected by a LinkEnd of the AssociationEnd is acting as the composite, or whole, in the links. The instances connected to the links by the opposite LinkEnds of the Links are considered the components, or parts, in the aggregation. type: AggregationType (enumeration with values {none, shared, composite}) multiplicity: exactly one constraints: Within an Association, at most one AssociationEnd may have its aggregation with a value not equal to none. [27]

isNavigable

The ability of an instance of a Classifier to access the instances in links defined by an association is provided through a Reference. The isNavigable attribute on an AssociationEnd constrains the ability to define a Reference which provides navigability to the instances of the AssociationEnd’s Classifier. If isNavigable is false, no Reference may be defined which uses this AssociationEnd as its referencedEnd. type: boolean multiplicity: exactly one constraints: If the AssociationEnd is in a link with a Reference, defined by the RefersTo Association, isNavigable may not be set to false. [28]

9/1/97 Meta Object Facility 1.1 3-57 Section 3. MOF Model and Interfaces

isChangeable

The isChangeable attribute restricts the capability to perform actions which would modify sets of instances corresponding to this AssociationEnd (the same sets to which multiplicity is applied). Specifically, the set may be created when the instance defining the set – the instance at the opposite end of the Links – is created. This attribute does not make the set immutable. Instead, it affects the generation of operations in Model Elaboration which would allow modification of the set. For IDL generation, the only operation which allows the set to be modified would be one or more factory operations which create the instance, and also create the set. The modeler is free to define specific operations which allow modification of the set. Note that defining this AssociationEnd with isChangeable equals false places restrictions on the changeability of the other AssociationEnd, due to their interdependence. See 6.2.1.3 Changeability Constraints. type: boolean multiplicity: exactly one

otherEnd

Provides the representation of the type supporting the TypedElement through this reference type: AssociationEnd multiplicity: exactly one changeable: no derived from: the AssociationEnd’s container’s other AssociationEnd

References

None

Operations

None

Constraints

As a simplification, at most one AssociationEnd of the Association can have a multiplicity defined with isOrdered equal to true. [29]

3-58 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Interface

interface AssociationEndClass : ModelElementClass { readonly attribute AssociationEndUList all_of_kind_association_end; readonly attribute AssociationEndUList all_of_type_association_end;

const string association_end_is_unique = "::Model::AssociationEnd::association_end_is_unique"; const string association_end_has_referent_implies_is_navigable = “::Model::AssociationEnd::” “association_end_has_referent_implies_is_navigable"; const string association_end_type_not_association_or_data_type = "::Model::AssociationEnd::” “association_end_type_not_association_or_data_type";

AssociationEnd create_association_end ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from AssociationEnd */ in boolean is_navigable, /* from AssociationEnd */ in ::Model::AggregationKind aggregation, /* from AssociationEnd */ in ::Model::MultiplicityType multiplicity) raises (Reflective::ConstraintError, Reflective::SemanticError); }; // end of interface AssociationEndClass

interface AssociationEnd : AssociationEndClass, ModelElement { boolean is_navigable () raises (Reflective::StructuralError, Reflective::SemanticError); void set_is_navigable (in boolean new_value) raises (Reflective::SemanticError); AggregationKind aggregation () raises (Reflective::StructuralError, Reflective::SemanticError); void set_aggregation (in AggregationKind new_value) raises (Reflective::SemanticError); MultiplicityType multiplicity () raises (Reflective::StructuralError, Reflective::ConstraintError, Reflective::SemanticError); void set_multiplicity (in MultiplicityType new_value) raises (Reflective::ConstraintError, Reflective::SemanticError); AssociationEnd other_end () raises (Reflective::StructuralError, Reflective::SemanticError); void set_other_end (in AssociationEnd new_value) raises (Reflective::SemanticError); }; // end of interface AssociationEnd

OCL

[26] AssociationEnd self.multiplicity.isUnique = true

9/1/97 Meta Object Facility 1.1 3-59 Section 3. MOF Model and Interfaces

[27] Association self.contentsÆselect(c | c.oclIsTypeOf(AssociationEnd))-> select(r | r.aggregation <> none)->size < 2

[28] AssociationEnd not self.referent-> isEmpty implies self.isNavigable = true

required operation AssociationEnd otherEnd : AssociationEnd otherEnd = self.container.contents-> select(c | c.oclIsKindOf(AssociationEnd) and c <> self)

[29] AssociationEnd self.multiplicity.isOrdered = true implies self.otherEnd.multiplicity.isOrdered = false

3-60 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

ModelElement

imported Namespace Aliases 1 Import importer visibility : VisibilityKind 0..*

GeneralizableElement

Package

copyModel( ) externalize( ) $internalize( )

Figure 3-7. MOF Model Packaging

3.7.17 Package A package is formed as a composition of ModelElements. A package defines a modeling unit – models are constructed and presented as packages. A model is a package. Packages are also uses as organizational constructs in modeling – nesting, importation, and generalization are used to manage the complexity of models. Unlike a Classifier, a Package (an instance of the Package Type or the thing that instance represents) does not have instances.

9/1/97 Meta Object Facility 1.1 3-61 Section 3. MOF Model and Interfaces

Supertypes

GeneralizableElement

Contained Elements

Package Type Association DataType MofException Import Constraint Constant [30]

Attributes

None

References

None

Operations

copyModel

This operation is only available to top-level Packages (Packages not contained by another Package). The copyModel operation creates a copy of the model in the target Namespace. For copying a MOF-compliant metamodel, this Namespace must be an instance of MofRepository. The boundaries of the copy are determined by the transitive closure of the model’s requiredElements (elements it depends on). The operation could result in copying not only this model, but imported Packages from this model’s repository or other repositories. If however, an imported Package is already in the target repository, it is not copied. return type: ModelElement parameters: target : in Namespace

3-62 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

externalize

Externalize the Package and all of its ModelElements (transitive closure on the containment hierarchy) in a format specified by the format parameter, into a stream of type any. parameters: format : in string stream : inout any exceptions: ObjectNotExternalizable, FormatNotSupported

internalize

Translate a model in some external format specified by the format parameter, encoded in the stream, into a package return type: Package scope: type-scope parameters: format : in string stream : in any exceptions FormatNotSupported, IllformedExternalizedObject

Constraints

A Package cannot be abstract. [31]

Interface

interface PackageClass : GeneralizableElementClass { readonly attribute PackageUList all_of_kind_package; readonly attribute PackageUList all_of_type_package;

const string package_not_abstract = "::Model::Package::package_not_abstract"; const string package_containment_rules = "::Model::Package::package_containment_rules";

typedef string FormatType;

exception FormatNotSupported {}; exception ObjectNotExternalisable { string explanation; }; exception IllformedExternalisedObject { string explanation; };

GeneralizableElement internalise (in any flattened,

9/1/97 Meta Object Facility 1.1 3-63 Section 3. MOF Model and Interfaces

in PackageClass::FormatType format) raises (PackageClass::FormatNotSupported, PackageClass::IllformedExternalisedObject, Reflective::SemanticError);

Package create_package ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from GeneralizableElement */ in ::Model::TristateKind is_root, /* from GeneralizableElement */ in ::Model::TristateKind is_leaf, /* from GeneralizableElement */ in boolean is_abstract, /* from GeneralizableElement */ in ::Model::VisibilityKind visibility) raises (Reflective::SemanticError); }; // end of interface PackageClass

interface Package : PackageClass, GeneralizableElement {

any externalise (in PackageClass::FormatType format) raises (PackageClass::ObjectNotExternalisable, PackageClass::FormatNotSupported, Reflective::SemanticError); };

OCL

[30] Package (self.contents - { Package, Type, DataType, Association, MofException, Constraint, Import })->isEmpty

[31] Package self.isAbstract = false

3.7.18 Import An Import provides a mechanism for a Package to explicitly import a Namespace element into the Package’s namespace. An imported Namespace is treated much as though the Namespace itself were contained by the Package. The Import allows for the visibility of the imported Namespace’s contained ModelElements to be further restricted. See the description of Package importing for a complete description, in Section 6.5 Rules of Importing and Visibility.

Supertypes

ModelElement

3-64 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Contained Elements

None (not a Namespace)

Attributes

visibility

The visibility of an Import partially determines visibility of the imported Namespace, as it appears in the importing Package. The visibility of that Namespace is specified as the more restrictive of the inherent visibility (as determined by the visibility specified for each ModelElement to be accessed and the visibility rules for importing) and the visibility specified here. This attribute cannot increase the visibility of the ModelElements. type: boolean multiplicity: exactly one

References

importedNamespace

The Import knows about the Namespace that it references. type: Namespace defined by: the Import-Aliases-Namespace association and its imported end. multiplicity: exactly one constraints: defined in the Import-Aliases-Namespace association

Operations

None

Constraints

A Package can only import a Namespace if the Namespace is visible from the Package. [32]

An imported Namespace must have a unique qualifiedName within the extended namespace of the importing package. [33]

9/1/97 Meta Object Facility 1.1 3-65 Section 3. MOF Model and Interfaces

Interface

interface ImportClass : ModelElementClass { readonly attribute ImportUList all_of_kind_import; readonly attribute ImportUList all_of_type_import;

const string import_imports_type_or_package = "::Model::Import::import_imports_type_or_package"; const string import_does_not_import_container = "::Model::Import::import_does_not_import_container"; const string imports_imported_does_not_contain_import = "::Model::Import::imports_imported_does_not_contain_import"; const string imported_visible_from_import = "::Model::Import::imported_visible_from_import";

Import create_import ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from Import */ in ::Model::VisibilityKind visibility) raises (Reflective::SemanticError); }; // end of interface ImportClass

interface Import : ImportClass, ModelElement { VisibilityKind visibility () raises (Reflective::StructuralError, Reflective::SemanticError); void set_visibility (in VisibilityKind new_value) raises (Reflective::SemanticError); Namespace imported_namespace () raises (Reflective::SemanticError); void set_imported_namespace (in Namespace new_value) raises (Reflective::SemanticError); };

OCL

[32] Import self.container.isVisible(self.importedNamespace)

[33] Import self.container.extendedNamespace-> forAll(e | e.qualifiedName = self.importedNamespace.qualifiedName implies e = self)

3-66 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

AttachesTo

1..*

ModelElement constrainedElement 1..* Constrains

TypedElement 0..* 0..* Tag Constraint tagId : string expression : any values : any language : string evaluationPolicy : EvaluationKind $createTagWithValue( ) TypeAlias multiplicity : MultiplicityType

Parameter Constant direction : DirectionKind value : any multiplicity : MulitiplicityType

Figure 3-8. MOF Model – Other Elements

3.7.19 Parameter A parameter provides a means of communication with operations and other BehavioralFeatures. A parameter passes or communicates values of its defined type.

Supertypes

TypedElement

Contained Elements

None (not a Namespace)

Attributes

direction

This attribute specifies the purpose of the parameter; to input a value, to output a value, both purposes, or to provide an operation return value. type: DirectionType (enumeration with values {in, out, inout, return}) multiplicity: exactly one

9/1/97 Meta Object Facility 1.1 3-67 Section 3. MOF Model and Interfaces

multiplicity

Multiplicity defines cardinality constraints on the set of instances or values that a Parameter can hold. Multiplicity defines a lower and upper bound on the set, although the upper bound can be specified as unbounded. Additionally multiplicity defines two other characteristics of the set – constraints on set member ordering and constraints on unique set elements. Specifically, Multiplicity contains an isOrdered field. When isOrdered is true, then the ordering of the elements in the set are preserved. Multiplicity also has an isUnique field. When isUnique is true, then the set is constrained to hold no more than one of any value or instance. type: MultiplicityType, a struct with fields of lower, upper, isOrdered, and isUnique; multiplicity: exactly one

References

None

Operations

None

Constraints

None

Interface

interface ParameterClass : TypedElementClass { readonly attribute ParameterUList all_of_kind_parameter; readonly attribute ParameterUList all_of_type_parameter;

const string parameter_not_an_association = "::Model::Parameter::parameter_not_an_association";

Parameter create_parameter ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from Parameter */ in ::Model::DirectionKind direction, /* from Parameter */ in ::Model::MultiplicityType multiplicity) raises (Reflective::ConstraintError, Reflective::SemanticError);

3-68 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

}; // end of interface ParameterClass

interface Parameter : ParameterClass, TypedElement { DirectionKind direction () raises (Reflective::StructuralError, Reflective::SemanticError); void set_direction (in DirectionKind new_value) raises (Reflective::SemanticError); MultiplicityType multiplicity () raises (Reflective::StructuralError, Reflective::ConstraintError, Reflective::SemanticError); void set_multiplicity (in MultiplicityType new_value) raises (Reflective::ConstraintError, Reflective::SemanticError); };

OCL

None

3.7.20 Constraint A Constraint defines a restriction on the state or behavior of models defined by the Constraint’s metamodel. A Constraint holds over one or more ModelElements – it is restricting the state or behavior of the ModelElement or the instances of that ModelElement. Because of the wide variety of constraint representations; the inability of any existing representation to represent all possible constraints; and the lack of a clear standard for constraint representation, the Constraint’s expression is allowed to take any form. The Constraint specifies the language used to represent the expression. Certain constraints must be held invariant – they must be evaluated whenever the constraint may be violated. Other constraints are impractical to hold invariant; these will be evaluated when explicitly requested. The verify operation on ModelElement triggers evaluation of these Constraints.

Supertypes

ModelElement

Contained Elements

None (not a Namespace)

9/1/97 Meta Object Facility 1.1 3-69 Section 3. MOF Model and Interfaces

Attributes

expression

The Constraint’s expression attribute provides a representation of the constraint. The MOF has no specific requirement to interpret this expression, or to validate it against the language attribute; the specific handling of the expression will necessarily vary with the language used. However, it is expected that, for any language an implementation accepts, it will enforce the constraints expressed in that language. The expression can be represented in any format – including text or a composition of objects. type: any multiplicity: exactly one

language

The language representing this Constraint’s expression is defined in this attribute. Since it is a string, most any language can be represented, including format variances in a language (e.g. OCL as text verses OCL as a parse tree). Type: string multiplicity: exactly one

evaluationPolicy

Each constraint can be defined as immediate, deferrable, or deferred. For immediate Constraints, the constraint violation will be detected and reported within an operation in the chain of operations between the operation initiated by the MOF user and the operation which caused the constraint violation. The effect of an operation that violates an immediate constraint on the state of the object or objects being altered is implementation specific, and possibly undefined. However, if possible an implementation should reverse the effects of the operation. For deferred Constraints, the constraint violation can only be detected when the Constraint is explicitly evaluated. The MOF defines an operation for such constraint evaluation, the verify operation. When the verify operation is invoked on a Constraint’s container, the constraint is evaluated and a constraint violation is detected, if present.. Deferrable Constraints can either be treated as immediate or deferred Constraints. Currently, all deferrable Constraints are treated as deferred Constraints. Marking those Constraints which could be evaluated under either policy as deferrable allows for a more flexibility in future constraint checking. type: EvaluationType , with values {immediate, deferrable, deferred} multiplicity: exactly one

3-70 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

References

constrainedElements

The Constraint has access to its the ModelElements it constrains, through this reference. Note that the Constraint may depend on other ModelElements not represented in this reference. For instance, a Constraint may state that attribute A::x cannot exceed A::y in magnitude. The Constraint is on A::x, although it also depends on A::y. The link between the Constraint and A::x will be represented in the metamodel, not the link between the Constraint and A::y. type: ModelElement defined by: the Constraint-Constrains-ModelElement association and its constrainedElement end. multiplicity: one or more constraints: A Constraint may not constrain a Constraint. [34] A constraint may not constrain a ModelElement which is not in the extended contents of the innermost Type or Package which contains this constraint. [35]

Operations

None

Constraints

None

Interface

interface ConstraintClass : ModelElementClass { readonly attribute ConstraintUList all_of_kind_constraint; readonly attribute ConstraintUList all_of_type_constraint;

enum EvaluationKind { immediate, deferred };

const string constraint_does_not_constrain_constraints = "::Model::Constraint::constraint_does_not_constrain_constraints"; const string constraint_does_not_constrain_element = "::Model::Constraint::constraint_does_not_constrain_element"; const string constraints_only_allowed_within_container =

9/1/97 Meta Object Facility 1.1 3-71 Section 3. MOF Model and Interfaces

"::Model::Constraint::constraints_only_allowed_within_container";

Constraint create_constraint ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from Constraint */ in any expression, /* from Constraint */ in string language, /* from Constraint */ in ::Model::ConstraintClass::EvaluationKind evaluation_policy) raises (Reflective::SemanticError); }; // end of interface ConstraintClass

interface Constraint : ConstraintClass, ModelElement { any expression () raises (Reflective::StructuralError, Reflective::SemanticError); void set_expression (in any new_value) raises (Reflective::SemanticError); string language () raises (Reflective::StructuralError, Reflective::SemanticError); void set_language (in string new_value) raises (Reflective::SemanticError); ConstraintClass::EvaluationKind evaluation_policy () raises (Reflective::StructuralError, Reflective::SemanticError); void set_evaluation_policy (in ConstraintClass::EvaluationKind new_value) raises (Reflective::SemanticError); ModelElementSet constrained_elts () raises (Reflective::SemanticError); void set_constrained_elts (in ModelElementSet new_values) raises (Reflective::StructuralError, Reflective::SemanticError); void add_constrained_elts (in ModelElement new_value) raises (Reflective::StructuralError, Reflective::SemanticError); void modify_constrained_elts (in ModelElement old_value, in ModelElement new_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove_constrained_elts (in ModelElement old_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

[34] Constraint self.constrainedElements->forAll(c | not c.oclIsTypeOf(Constraint))

[35] Constraint self.constrainedElements-> forAll(c | self.container.extendedContents->includes(c))

3-72 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

3.7.21 Constant This type provides a mechanism for defining constant values of simple data types, in the support of model development.

Supertypes

TypedElement

Contained Elements

None (not a Namespace)

Attributes

value

The value of the constant. type: any multiplicity: exactly one constraints: value must be of the type defined in the type attribute [36]

References

None

Operations

None

Constraints

None

Interface

interface ConstantClass : TypedElementClass { readonly attribute ConstantUList all_of_kind_constant; readonly attribute ConstantUList all_of_type_constant;

9/1/97 Meta Object Facility 1.1 3-73 Section 3. MOF Model and Interfaces

const string constant_type_must_be_corba_const_type = "::Model::Constant::constant_type_must_be_corba_const_type"; const string constant_value_compatible_with_type = "::Model::Constant::constant_value_compatible_with_type";

Constant create_constant ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from Constant */ in ::Model::LiteralType const_value) raises (Reflective::SemanticError); }; // end of interface ConstantClass

interface Constant : ConstantClass, TypedElement { LiteralType const_value () raises (Reflective::StructuralError, Reflective::SemanticError); void set_const_value (in LiteralType new_value) raises (Reflective::SemanticError); };

OCL

[36] Constant self.value.oclIsTypeOf(self.type)

3.7.22 Tag The principle means of metamodel extensibility is through defining new metamodels based on existing models. Tags and Tag values provide an alternate extensibility mechanism. Tags provide a flexible means of extending, adapting, and customizing metamodels, but often at the price of model interoperability. Unlike the MOF model elements, tags have no defined semantics.

A Tag is applied to one or more ModelElements, and may be contained by either a Namespace in the model or a ModelRepository.

Supertypes

ModelElement

Contained Elements

None (not a Namespace)

3-74 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Attributes

tagId

Defines the Tag categorization or Tag kind. The tagId need not be unique. type: string multiplicity: exactly one

values

The Tag values carry the information associated with the Tag. type: any multiplicity: zero or more

References

elements

The ModelElement or ModelElements that this Tag is attached to. type: ModelElement defined by: the Tag-AttachesTo-ModelElement association and its modelElement end multiplicity: one or one (a Tag must be attached to at least one ModelElement)

Operations

None

Constraints

None

Interface

interface TagClass : ModelElementClass {

9/1/97 Meta Object Facility 1.1 3-75 Section 3. MOF Model and Interfaces

readonly attribute TagUList all_of_kind_tag; readonly attribute TagUList all_of_type_tag;

Tag create_tag ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from Tag */ in string tag_id, /* from Tag */ in any values) raises (Reflective::SemanticError); }; // end of interface TagClass

interface Tag : TagClass, ModelElement { string tag_id () raises (Reflective::StructuralError, Reflective::SemanticError); void set_tag_id (in string new_value) raises (Reflective::SemanticError); AnyBag values () raises (Reflective::SemanticError); void set_values (in AnyBag new_value) raises (Reflective::SemanticError); void unset_values () raises (Reflective::SemanticError); void add_values (in any new_value) raises (Reflective::SemanticError); void modify_values (in any old_value, in any new_value) raises (Reflective::NotFound, Reflective::SemanticError); void remove_values (in any old_value) raises (Reflective::NotFound, Reflective::SemanticError); TagUList elements () raises (Reflective::SemanticError); void set_elements (in TagUList new_values) raises (Reflective::StructuralError, Reflective::SemanticError); void add_elements (in Tag new_value) raises (Reflective::StructuralError, Reflective::SemanticError); void add_elements_before (in Tag new_value, in Tag before) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_elements (in Tag old_value, in Tag new_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove_elements (in Tag old_value) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

None

3-76 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

3.7.23 TypeAlias A TypeAlias represents the use of a type in a definition where a direct link to the Type instance is not feasible. In the MOF Model, it is used to represent the use (or multiple uses) of a type in the definition of a TypeCode.

Supertypes

TypedElement

Contained Elements

None (not a Namespace)

Attributes

multiplicity

The MOF does not maintain separate Classifier instances for a type and a type which is a collection that holds the type (although the modeler is free to do so). The use of multiplicity in features, association ends, and parameters allows representation of collections of types, for which types, or aliases will have to be defined at elaboration. So, if a sequence type is used in the definition of a typecode, but only the element of the sequence is represented in the model, this multiplicity indicates the fact that the type in the typecode is not the type represented by this TypeAliases’ type reference, but by a sequence type of that reference. Further, the ordering and uniqueness defines the specific kind of sequence. type: MultiplicityType multiplicity: exactly one

References

None

Operations

None

Constraints

None

9/1/97 Meta Object Facility 1.1 3-77 Section 3. MOF Model and Interfaces

Interface

interface TypeAliasClass : TypedElementClass { readonly attribute TypeAliasUList all_of_kind_type_alias; readonly attribute TypeAliasUList all_of_type_type_alias;

TypeAlias create_type_alias ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation) raises (Reflective::SemanticError); }; // end of interface TypeAliasClass

interface TypeAlias : TypeAliasClass, TypedElement { };

OCL

None

3.8 MOF Model Associations

3.8.1 Namespace-Contains-ModelElement A metamodel is defined through a composition of ModelElements. A Namespace defines a ModelElement which composes other ModelElements. Since Namespace has several subtypes, there is a sizable combinatorial set of potential Namespace-ModelElement pairings. However, Some of these pairings are not appropriate for building an object- oriented metamodel, such as a Type containing a Package. Several constraints are defined in Section 6.3, to restrict instances of certain Namespace subtypes from containing instances of certain ModelElements. This approach allows for factoring of container and contained mechanisms into single abstractions, and provides the greatest flexibility for future changes to the MOF Model.

Ends

container

Each Namespace is a composition of zero or more ModelElements. type: Namespace multiplicity: zero or one aggregation: Namespace forms a composite aggregation of ModelElements

3-78 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

constraints: Subject to the Rules of Containment, Section 6.3. A Namespace cannot be the container of itself (directly or indirectly). [37]

containedElement

Each ModelElement, with the exception of top-level packages participates in the association as a containedElement. type: ModelElement multiplicity: zero or more; ordered constraints: Subject to the rules of containment, in Table 6-2. Rules of Containment The Namespace defines a namespace – the current set of allowable names – applied to the contents of the Namespace. For a given Namespace, each ModelElement in a LinkEnd defined by the containedElements end must have a unique name, where the all characters of the name are considered, but upper and lower case letters are not distinguished. [38]

Constraints

None

Interface interface Contains : Reflective::RefAssociation { ContainsLinkSet all_Contains_links (); boolean exists (in Namespace container, in ModelElement contained_element); ModelElementUList with_container (in Namespace container); Namespace with_contained_element (in ModelElement contained_element); void add (in Namespace container, in ModelElement contained_element) raises (Reflective::StructuralError, Reflective::SemanticError); void add_before_contained_element (in Namespace container, in ModelElement contained_element, in ModelElement before) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_container (in Namespace container, in ModelElement contained_element, in Namespace new_container) raises (Reflective::StructuralError, Reflective::NotFound,

9/1/97 Meta Object Facility 1.1 3-79 Section 3. MOF Model and Interfaces

Reflective::SemanticError); void modify_contained_element (in Namespace container, in ModelElement contained_element, in ModelElement new_contained_element) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove (in Namespace container, in ModelElement contained_element) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

[37] Namespace not self.allContents->includes(self)

[38] Namespace self.contents.forAll( e1, e2 | e1.name.toUpper = e2.name.toUpper implies r1 = r2 )

3.8.2 GeneralizableElement-Generalizes-GeneralizableElement The Association defined on GeneralizableElement. A Link of this Association represents a supertype/subtype relationship (or a generalizes/specializes relationship).

Ends

supertype

The GeneralizableElement which is more general is the supertype type: GeneralizableElement multiplicity: zero or more (a GeneralizableElement may have zero or more supertypes); ordered

3-80 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

constraints: A GeneralizableElement cannot be its own supertype, either directly or indirectly. [39] A GeneralizableElement with the isRoot set to yes cannot have any supertypes. [40] A GeneralizableElement with the isRoot set to no must have at least one supertype. [41] A GeneralizableElement cannot have another GeneralizableElement as its supertype if that candidate supertype is not visible to it. [42]

subtype

The subtype is the GeneralizableElement which is more specific. The supertype Generalizes the subtype. type: GeneralizableElement multiplicity: zero or more (a GeneralizableElement may have zero or more subtypes) constraints: A GeneralizableElement cannot be its own subtype, either directly or indirectly. [43] A GeneralizableElement with the isLeaf set to yes cannot have any subtypes. [44] A GeneralizableElement with the isLeaf set to no must have at least one subtype. [45]

Constraints

A GeneralizableElement can only generalize another GeneralizableElement if both are instances of the same GeneralizableElement subtype (e.g. A Type instance cannot be a supertype to a DataType instance). [46]

Interface

interface Generalizes : Reflective::RefAssociation { GeneralizesLinkSet all_Generalizes_links (); boolean exists (in GeneralizableElement supertype, in GeneralizableElement subtype); GeneralizableElementSet with_supertype (in GeneralizableElement supertype); GeneralizableElementUList with_subtype (in GeneralizableElement subtype); void add (in GeneralizableElement supertype, in GeneralizableElement subtype) raises (Reflective::StructuralError,

9/1/97 Meta Object Facility 1.1 3-81 Section 3. MOF Model and Interfaces

Reflective::SemanticError); void add_before_supertype (in GeneralizableElement supertype, in GeneralizableElement subtype, in GeneralizableElement before) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_supertype (in GeneralizableElement supertype, in GeneralizableElement subtype, in GeneralizableElement new_supertype) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_subtype (in GeneralizableElement supertype, in GeneralizableElement subtype, in GeneralizableElement new_subtype) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove (in GeneralizableElement supertype, in GeneralizableElement subtype) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

[39] GeneralizableElement self.allSupertypes->forAll(s | s <> self)

[40] GeneralizableElement self.isRoot = yes implies self.supertypes->isEmpty

[41] GeneralizableElement self.isRoot = no implies not self.supertypes-> isEmpty

[42] GeneralizableElement self.supertypes->forAll(s | self.isVisible(s))

[43] (redundant constraint, convered by [39])

[44] GeneralizableElement self.supertypes->forAll(s | s.isLeaf <> yes)

[45] GeneralizableElement self.isLeaf = no implies self.subtypes-> isEmpty

[46] GeneralizableElement self.supertype->forAll(s | s.oclType = self.oclType)

3-82 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

3.8.3 Reference-RefersTo-AssociationEnd A Reference derives most of its state from the AssociationEnd that it is linked to, based on this Association. For a Type defined with a Reference, each of its instances can be used to access the referenced object or objects. Those referenced objects will be of the Type defined by this referencedEnd AssociationEnd, playing the defined end.

Ends

referent

The Reference which is providing the reference through which instances playing the end defined by the AssociationEnd can be accessed. type: Reference multiplicity: zero or one (an AssociationEnd may or may not be used by any Reference). constraints: A Reference cannot be linked to an AssociationEnd through the RefersTo association an unless the AssociationEnd’s other end in the Association defines its type as the Classifier which owns the Reference or a subtype of that Classifier. [47]

referencedEnd

The AssociationEnd which provides the majority of information for the Reference, including the LinkEnds which supply the referenced instances. type: AssociationEnd multiplicity: exactly one constraints: An AssociationEnd with its isNavigable attribute set to false cannot participate in this association with a Reference. [48] A Reference must have visibility of an AssociationEnd in order to link with it in this association [49]

Constraints

None

9/1/97 Meta Object Facility 1.1 3-83 Section 3. MOF Model and Interfaces

Interface

interface RefersTo : Reflective::RefAssociation { RefersToLinkSet all_RefersTo_links (); boolean exists (in Reference referent, in AssociationEnd referenced_end); AssociationEnd with_referent (in Reference referent); Reference with_referenced_end (in AssociationEnd referenced_end); void add (in Reference referent, in AssociationEnd referenced_end) raises (Reflective::StructuralError, Reflective::SemanticError); void modify_referent (in Reference referent, in AssociationEnd referenced_end, in Reference new_referent) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_referenced_end (in Reference referent, in AssociationEnd referenced_end, in AssociationEnd new_referenced_end) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove (in Reference referent, in AssociationEnd referenced_end) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

[47] Reference self.referencedEnd.otherEnd.type = self.container or self.container.allSupertypes->includes(self.referencedEnd.otherEnd.type)

[48] (redundant constraint, covered by [28])

[49] Reference self.isVisible(self.referencedEnd)

3.8.4 Reference-Exposes-AssociationEnd derived A Reference defines a reference for a Type. For an instance of that type, which holds one or more links to some object or objects conforming to the reference, the instance will be playing the role (end) defined by the AssociationEnd in this Association. Although this association can be derived in the current MOF, the use of n-ary associations, where a single Type has multiple ends, specification of this Association is necessary.

3-84 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Ends

referrer

The Reference which is providing the exposedEnd’s type instances within the Reference’s Classifier. type: Reference multiplicity: zero or one (an AssociationEnd may or may not be used by any Reference).

exposedEnd

The AssociationEnd representing the Reference’s owning Classifier’s end in the Association. type: AssociationEnd multiplicity: exactly one

Derivation

For a given Reference, the Link of this Association is derived as: the referrer’s Reference is the given Reference; the exposedEnd’s AssociationEnd is the given Reference’s referent’s container Association’s other AssociationEnd.

Constraints

None

Interface

interface Exposes : Reflective::RefAssociation { ExposesLinkSet all_Exposes_links (); boolean exists (in Reference referrer, in AssociationEnd exposed_end); AssociationEnd with_referrer (in Reference referrer); Reference with_exposed_end (in AssociationEnd exposed_end); void add (in Reference referrer, in AssociationEnd exposed_end) raises (Reflective::StructuralError, Reflective::SemanticError); void modify_referrer (in Reference referrer, in AssociationEnd exposed_end, in Reference new_referrer)

9/1/97 Meta Object Facility 1.1 3-85 Section 3. MOF Model and Interfaces

raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_exposed_end (in Reference referrer, in AssociationEnd exposed_end, in AssociationEnd new_exposed_end) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove (in Reference referrer, in AssociationEnd exposed_end) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

None

3.8.5 TypedElement-IsOfType-Classifier A Link between a TypedElement subtype and a Classifier supports the definition of the TypedElement.

Ends

type

The type defining the TypedElement type: Classifier multiplicity: exactly one constraints: An TypedElement can only be of a Type which is visible to it. [50] An AssociationEnd may not be typed with an Association or a DataType. [51] A StructuralFeature may not be typed with an Association. [52] A Parameter may not be typed with an Association. [53] A Constant may be only a data type value, and within data types, only those representing integers (signed and unsigned short and long), char, boolean, float and string [54]

3-86 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

typedElements

The set of typed elements supported by a Classifier. type: TypedElement multiplicity: zero or more

Constraints

None

Interface

interface IsOfType : Reflective::RefAssociation { IsOfTypeLinkSet all_IsOfType_links (); boolean exists (in Classifier type, in TypedElement typed_elements); TypedElementSet with_type (in Classifier type); Classifier with_typed_elements (in TypedElement typed_elements); void add (in Classifier type, in TypedElement typed_elements) raises (Reflective::StructuralError, Reflective::SemanticError); void modify_type (in Classifier type, in TypedElement typed_elements, in Classifier new_type) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_typed_elements (in Classifier type, in TypedElement typed_elements, in TypedElement new_typed_elements) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove (in Classifier type, in TypedElement typed_elements) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

[50] TypedElement self.isVisible(self.type)

[51] AssociationEnd

9/1/97 Meta Object Facility 1.1 3-87 Section 3. MOF Model and Interfaces

not self.type.oclIsKindOf(Association) and not self.type.oclIsKindOf(DataType)

[52] StructuralFeature not self.type.oclIsKindOf(Association)

[53] Parameter not self.type.oclIsKindOf(Association)

required operation TypeCode baseType : TCKind baseType = if self.kind = tk_alias then self.content_type.baseType else self endif

[54] Constant self.type.oclIsKindOf(DataType) and Set{tk_short, tk_ushort, tk_long, tk_ulong, tk_char, tk_float, tk_double, tk_boolean, tk_string}-> includes(self.type.typeCode.baseType)

3.8.6 Operation-CanRaise-MofException Represents the Exceptions that operations can raise.

Ends

operation

Given an Exception, the set of Operations which can Raise that Exception. type: Operation multiplicity: zero or more (an Exception may be defined which is not currently used by any Operation; an Exception may support multiple Operations) constraints: An operation can only raise an exception if that exception is visible from the operation [55]

3-88 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

exception

The set of Exceptions for an Operation type: MofException multiplicity: zero or more (an Operation may be defined to raise no exception, or multiple exceptions); ordered – an Operation’s Exceptions are ordered

Constraints

None

Interface

interface CanRaise : Reflective::RefAssociation { const string exception_is_not_visible = "::Model::CanRaise::exception_is_not_visible";

CanRaiseLinkSet all_CanRaise_links (); boolean exists (in Operation operation, in MofException except); MofExceptionUList with_operation (in Operation operation); OperationSet with_except (in MofException except); void add (in Operation operation, in MofException except) raises (Reflective::StructuralError, Reflective::ConstraintError, Reflective::SemanticError); void add_before_except (in Operation operation, in MofException except, in MofException before) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::ConstraintError, Reflective::SemanticError); void modify_operation (in Operation operation, in MofException except, in Operation new_operation) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::ConstraintError, Reflective::SemanticError); void modify_except (in Operation operation, in MofException except, in MofException new_except) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove (in Operation operation, in MofException except) raises (Reflective::StructuralError, Reflective::NotFound,

9/1/97 Meta Object Facility 1.1 3-89 Section 3. MOF Model and Interfaces

Reflective::ConstraintError, Reflective::SemanticError); };

OCL

[55] Operation self.exceptions->forAll(e | self.isVisible(e))

3.8.7 Import-Aliases-Namespace An Import aliases or imports a single Namespace.

Ends

importer

A Namespace may be aliased by an Import, which is the importer. type: Import multiplicity: zero or more (an Namespace may not be aliased, or may be aliased by multiple Imports)

imported

The Namespace that an Import imports or aliases type: Namespace multiplicity: exactly one constraints: Only instances of Package and Type can be imported. [56] An Import can not import its containing Package [57] An Import can not import a Namespace contained directly or transitively) by the Import’s containing Package, [58]

Constraints

None

3-90 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Interface

interface Aliases : Reflective::RefAssociation { AliasesLinkSet all_Aliases_links (); boolean exists (in Import importer, in Namespace imported); Namespace with_importer (in Import importer); ImportSet with_imported (in Namespace imported); void add (in Import importer, in Namespace imported) raises (Reflective::StructuralError, Reflective::SemanticError); void modify_importer (in Import importer, in Namespace imported, in Import new_importer) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_imported (in Import importer, in Namespace imported, in Namespace new_imported) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove (in Import importer, in Namespace imported) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

[56] Import self.imported.oclIsKindOf(Type) or self.imported.oclIsKindOf(Package)

[57] Import self.container <> self.imported

[58] Import not self.container.allContents->includes(self.imported)

OCL

None

3.8.8 Constraint-Constrains-ModelElement Each Constraint constrains one or more ModelElements.

9/1/97 Meta Object Facility 1.1 3-91 Section 3. MOF Model and Interfaces

Ends

constrainedElement

The ModelElements that a Constraint holds its constraint against type: ModelElement multiplicity: one or more (a Constraint must constrain at least one ModelElement)

constraint

A Constraint which constrains a ModelElement type: MofException multiplicity: zero or more (a ModelElement need not be constrained, but could be constrained by more than one Constraint)

Constraints

None

Interface

interface Constrains : Reflective::RefAssociation { ConstrainsLinkSet all_Constrains_links (); boolean exists (in Constraint constraints, in ModelElement constrained_element); ModelElementSet with_constraints (in Constraint constraints); ConstraintSet with_constrained_element (in ModelElement constrained_element); void add (in Constraint constraints, in ModelElement constrained_element) raises (Reflective::StructuralError, Reflective::SemanticError); void modify_constraints (in Constraint constraints, in ModelElement constrained_element, in Constraint new_constraints) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_constrained_element (in Constraint constraints, in ModelElement constrained_element, in ModelElement new_constrained_element) raises (Reflective::StructuralError, Reflective::NotFound,

3-92 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Reflective::SemanticError); void remove (in Constraint constraints, in ModelElement constrained_element) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

None

3.8.9 ModelElement-DependsOn-ModelElement derived Dependency is derived from a small set of Associations.

Ends

dependent

The set of ModelElements which depend on a ModelElement are in the end of dependent. type: ModelElement multiplicity: zero or more (a ModelElement can have no ModelElement depend on it, or many may depend on it)

provider

For a ModelElement ME1, the set of ModelElements that ME1 depends on. type: Namespace multiplicity: zero or more (a ModelElement can depend on no other ModelElements or multiple ModelElements)

9/1/97 Meta Object Facility 1.1 3-93 Section 3. MOF Model and Interfaces

Derivation

The dependents of a ModelElement are those that use the ModelElement in their definition. In the following definition, a ModelElement may have dependents defined in a type-specific manner; when considering a ModelElement to be some type, it means that type or a subtype of that type. For a given ModelElement ME1, the set of dependent ModelElements are the union of: ME1’s container ModelElement; if ME1 is a GeneralizableElement, the set of ME1’s subtypes; if ME1 is a Namespace, the sets of owning Packages of the set of importing Imports of ME1; if ME1 is a Parameter, a StructuralFeature, an AssociationEnd, or a Constant, the instance of ME1’s type attribute; if ME1 is an AssociationEnd, the referent and referencedEnd References, if either exist; if ME1 is a MofException, the set ME1’s operations; and the set of Constraints which constrain ME1.

Constraints

None

Interface

interface DependsOn : Reflective::RefAssociation { DependsOnLinkSet all_DependsOn_links (); boolean exists (in ModelElement dependent, in ModelElement provider); ModelElementSet with_dependent (in ModelElement dependent); ModelElementSet with_provider (in ModelElement provider); void add (in ModelElement dependent, in ModelElement provider) raises (Reflective::StructuralError, Reflective::SemanticError); void modify_dependent (in ModelElement dependent, in ModelElement provider, in ModelElement new_dependent) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_provider (in ModelElement dependent, in ModelElement provider, in ModelElement new_provider) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove (in ModelElement dependent, in ModelElement provider) raises (Reflective::StructuralError,

3-94 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

Reflective::NotFound, Reflective::SemanticError); };

OCL

None

3.8.10 Tag-AttachesTo-ModelElement This association represents Tags attached to ModelElements.

Ends

modelElement

The ModelElements that an attached Tag describes, modifies, or otherwise associates. type: ModelElement multiplicity: one or more (a Tag must be attached to at least one ModelElement)

tag

The set of Tags attached to a ModelElement type: Tag multiplicity: zero or more (a ModelElement need not have a Tag) ordered: Yes, ModelElement’s Tags are ordered, although the ordering may not be of any significance, depending on the meaning of the Tags. Ordering is preserved in case some Tags, in conjunction with some defined semantics, requires an ordering.

Constraints

None

9/1/97 Meta Object Facility 1.1 3-95 Section 3. MOF Model and Interfaces

Interface

interface AttachesTo : Reflective::RefAssociation { AttachesToLinkSet all_AttachesTo_links (); boolean exists (in ModelElement model_element, in Tag tag); TagUList with_model_element (in ModelElement model_element); ModelElementSet with_tag (in Tag tag); void add (in ModelElement model_element, in Tag tag) raises (Reflective::StructuralError, Reflective::SemanticError); void add_before_tag (in ModelElement model_element, in Tag tag, in Tag before) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_model_element (in ModelElement model_element, in Tag tag, in ModelElement new_model_element) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void modify_tag (in ModelElement model_element, in Tag tag, in Tag new_tag) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove (in ModelElement model_element, in Tag tag) raises (Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

OCL

None

3.9 MOF Model Data Types The following data types are part of the MOF Model. Since these are data types, classifying values, they are not strictly meta-metamodel constructs, but since they are needed for defining metamodels, they are included in the MOF’s Model Package. Since the MOF Model is defined as an instance of itself (the MOF Model is the metamodel of itself), many of these data types are also used in the specification of the MOF Model.

Each of these data types are represented in the MOF Model as an instance of the DataType type. For each instance, a CORBA-compliant typecode is supplied. In the following description, an IDL representation of each typecode is provided.

3-96 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

3.9.1 Primitive Data Types

3.9.1.1 CORBA Basic Types Each of the CORBA basic types are available as instances of DataType. The typecodes are not presented here, but can be obtained by using the get_primitive_tc defined in Module ORB. The data types are:

short, long, ushort, ulong, float, double, boolean, char, octet, any, string, TypeCode

3.9.1.2 NameType NameType is an unbounded string data type.

The NameType data type is defined with an instance of the DataType Type, with a typecode corresponding to:

typedef string NameType; 3.9.1.3 AnnotationType AnnotationType is an unbounded string data type, used to define the strings used as annotations.

The AnnotationType data type is defined with an instance of the DataType Type, with a typecode corresponding to:

typedef string AnnotationType; 3.9.1.4 TypeDescriptor A TypeDescriptor value represents a particular type. By defining TypeDescriptor as a CORBA TypeCode, the MOF makes use of CORBA’s types and type definition capabilities.

The TypeDescriptor data type is defined with an instance of the DataType Type, with a typecode corresponding to:

typedef CORBA::TypeCode TypeDescriptor; 3.9.2 Constructed Types

3.9.2.1 MultiplicityType A MultiplicityType instance is a composition of values, as defined by the constructed data type. MultiplicityType has three four fields, lower, of long type; upper, of long type; isOrdered, a boolean; and isUnique, a boolean.

9/1/97 Meta Object Facility 1.1 3-97 Section 3. MOF Model and Interfaces

MultiplicityType is represented with an instance of the DataType Type with typeCode attribute having the value of the TypeCode corresponding to:

struct MultiplicityType { long lower; long upper; boolean isOrdered; boolean isUnique };

Constraints:

The lower bounds cannot be have the value of the constant UNBOUND [59]

The lower bounds cannot be greater than the upper bounds [60]

The upper bounds must be greater than zero [61]

When the upper bounds is less than two (denoting a single-valued set), isOrdered and isUnique are not applicable – they must be each set to false. [62]

OCL

[59] for an object with attribute m of MultiplicityType self.m.lower <> UNBOUND

[60] for an object with attribute m of MultiplicityType self.m.lower <= self.m.upper or self.m.upper = UNBOUND

[61] for an object with attribute m of MultiplicityType self.m.upper > 0

[62] for an object with attribute m of MultiplicityType self.m.upper < 2 implies (is_ordered = false and is_unique = false)

3.9.2.2 VisibilityType This data type enumerates the possible kinds of visibility is represented by:

enum VisibilityType {public, private, protected}; 3.9.2.3 TristateType Similar to the boolean type, this data type enumerates three choices:

enum TristateType {yes, no, dont_care}; 3.9.2.4 DepthType DepthType enumerates values as:

3-98 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

enum DepthType {shallow, deep}; 3.9.2.5 DirectionType DirectionType represent possible directions as:

enum DirectionType {in, out, inout, return}; 3.9.2.6 ScopeType ScopeType enumerates the possible scopes as:

enum ScopeType {instanceLevel, classifierLevel}; 3.9.2.7 AggregationType AggregationType is defined with:

enum AggregationType {none, shared, composite}; 3.9.2.8 EvaluationType Represents approaches to evaluation as:

enum EvaluationType {immediate, deferrable, deferred}; 3.9.2.9 DependencyKind DependencyKind is a string representing the cause of a particular dependency:

typedef string DependencyKind;

Within the MOF, defined values of this type are provided through the following constants, as instances of the Constant type:

const DependencyKind CONTAINMENT_DEP = “containment"; const DependencyKind SIGNATURE_DEP = "signature"; const DependencyKind CONSTRAINT_DEP = "constraint"; const DependencyKind SPECIALIZATION_DEP = "specialization"; const DependencyKind TYPEDEFINITION_DEP = " type definition "; const DependencyKind INDIRECT_DEP = "indirect"; const DependencyKind ALL_DEP = "all";

When a ModelElement depends on a second model element under one kind of dependency; and the second model element depends on a third under some other kind of dependency; then the first ModelElement depends on the third ModelElement. However, the kind of dependency cannot be specified, based on the other two dependency kinds, except to categorize the dependency as indirect.

3.9.2.10 VerificationResultKind A values of this data type represents the results of a verification operation, as:

9/1/97 Meta Object Facility 1.1 3-99 Section 3. MOF Model and Interfaces

enum VerificationResultKind {valid, invalid, published};

3.10 MOF Model Exceptions The following exceptions are contained in the MOF Model Package. The generated IDL interfaces for the MOF Model make use of more exceptions, which are defined in the Reflective Package and assigned to operations based on criteria determinable during generation.

3.10.1 NameNotResolved

Indicates that an attempt to resolve a qualified name failed. parameters: missingName : out NameType resolvedPart : out NameType (multiplicity: zero or more; ordered; not unique)

3.10.2 ObjectNotExternalizable

An object cannot be externalized in the requested format. parameters: explanation : out string

3.10.3 FormatNotSupported

The specified format for internalize/externalize is not supported. parameters: none

3.11 OCL Representation of the MOF Model Constraints In using OCL, we have made allowance for representing navigation through References as well as AssociationEnds. We express navigation through References, when available, in the same manner as AssociationEnds. Also, because navigation through AssociationEnds can only be accomplished in the MOF through References, we avoid, as much as is practical, such navigation. Although it is possible to navigate indirectly through the Association, if the Association contains inter-repository links, it may not be possible to find the link for traversal. Since OCL is just specifying the constraint, the ability to implement the navigation is not paramount. However, we want to provide, among multiple possible representations, the constraint that would be the easiest to implement. Somebody may want to build a MOF in which the OCL constraints from this

3-100 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

submission are evaluated directly. Also, we want to avoid specifying constraints which simply cannot be enforced.

Whenever an operation or property in OCL has the same name as an operation, reference, association end, or attribute in the MOF Model, such that the use of the name could indicate either the OCL definition or the MOF Model definition, the MOF Model definition will be considered the definition for that use. For instance, in defining an constraint on Type, if self.allSupertypes is used, the MOF-defined version of this feature will be used as the definition, even though an OCL definition exists.

[1] ModelElement not self.oclIsTypeOf(Package) implies self.container->size = 1 and self.oclIsTypeOf(Package) implies self.container->size < 2

[2] ModelElement –- not expressable in OCL: if self.is_frozen, then: every attribute of ModelElement, and of any ModelElement subtypes for which this object is an isntance, are immutable; also this object can only be removed through removal of its container.

[3] ModelElement –- not expressable in OCL: if self.is_frozen, then: for each Reference of self.object_type, the links corresponding to each reference are immutable; the may only be removed when this object is deleted.

[4] GeneralizableElement self.allSupertypes-> forAll(s | s.contents->forAll(superC | self.contents-> forAll(selfC | superC.name.toUpper <> selfC.name.toUpper))))

[5] GeneralizableElement allSupertypes : Sequence(GeneralizableElement) -- defines a specific order allSupertypes = self.supertypes-> collect(s | Set{s}->union(s.allSupertypes))->asSet->asSequence -- convert to set and back to sequence removed dups and preserve order -- alternatively, express as the sequence minus the intersection of -- the sequence and the ->asSet of the sequence

[6] Class (self.contents - Set{Class, DataType, MofAttribute, Reference, Operation, MofException, Constraint, Tag})->isEmpty

[7] Class self.isSingleton implies self.AllInstances < 2

[8] Class self.isAbstract implies self.isSingleton = false

9/1/97 Meta Object Facility 1.1 3-101 Section 3. MOF Model and Interfaces

[9] DataType (self.contents - Set{TypeAlias, Tag})->isEmpty

required operation -- return the typecode kind and the kinds directly contained by a typecode TypeCode containedTypes : Set(TCKind) containedTypes = Set{self.kind}->union( if Set{tk_struct, tk_union, tk_except}->includes(self.kind) then self.member_types->collect(mt | mt.kind)->union( if self.kind = tk_union then self.discriminator_type.kind else { } endif) else if Set{tk_sequence, tk_array, and tk_alias}->includes(self.kind) then self.content_type.kind else { } endif)

[10] DataType self.typeCode.allTypes-> intersection(Set{tk_void, tk_principal, tk_except})->isEmpty

[11] DataType -- because foreign type cannot be verified, expression -- currently must always evaluate to true self.typeCode.allTypes-> forAll(tc | Set{set of CORBA basic types}->includes(tc.name) or self.contents->select(c | c. oclIsTypeOf(TypeAlias))-> collect(ta | ta.name)->includes(tc.name) or true) [12] Reference self.muliplicity = self.referencedEnd.multiplicity

[13] Reference self.scope = instance_level

[14] Reference self.isChangeable = self.referencedEnd.isChangeable

[15] Reference self.type = self.referencedEnd.type

[16] Operation (self.contents - Set{Parameter, Constraint, Tag})->isEmpty

3-102 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

[17] Operation self.contents->select(c | c.oclIsTypeOf(Parameter))-> select(p : Parameter | p.direction = return)->size < 2

[18] MofException (self.contents - Set{Parameter, Constraint, Tag})->isEmpty

[19] MofException self. contents->select(c | c.oclIsTypeOf(Parameter))-> forAll(p : Parameter | p.direction = out)

[20] Association (self.contents - Set{AssociationEnd, Constraint, Tag})->isEmpty

[21] Association self.supertypes->isEmpty

[22] Association self.isRoot = dont_care and self.isLeaf = dont_care

[23] Association self.isAbstract = false

[24] Association self.visibility = public

[25] Association self.contentsÆselect(c | c.oclIsTypeOf(AssociationEnd))->size = 2

[26] AssociationEnd self.multiplicity.isUnique = true

[27] Association self.contentsÆselect(c | c.oclIsTypeOf(AssociationEnd))-> select(r | r.aggregation <> none)->size < 2

[28] AssociationEnd not self.referent-> isEmpty implies self.isNavigable = true

[29] AssociationEnd self.multiplicity.isOrdered = true implies self.otherEnd multiplicity.isOrdered = false

[30] Package (self.contents - Set{Package, Type, DataType, Association, MofException, Constraint, Import, Tag})->isEmpty

[31] Package

9/1/97 Meta Object Facility 1.1 3-103 Section 3. MOF Model and Interfaces

self.isAbstract = false

[32] Import self.container.isVisible(self.importedNamespace)

[33] Import self.container.extendedNamespace-> forAll(e | e.qualifiedName = self.importedNamespace.qualifiedName implies e = self)

[34] Constraint self.constrainedElements->forAll(c | not c.oclIsTypeOf(Constraint))

[35] Constraint self.constrainedElements-> forAll(c | self.container.extendedContents->includes(c))

[36] Constant self.value.oclIsTypeOf(self.type)

[37] Namespace not self.allContents->includes(self)

[38] Namespace self.contents.forAll( e1, e2 | e1.name.toUpper = e2.name.toUpper implies r1 = r2 )

[39] GeneralizableElement self.allSupertypes->forAll(s | s <> self)

[40] GeneralizableElement self.isRoot = yes implies self.supertypes->isEmpty

[41] GeneralizableElement self.isRoot = no implies not self.supertypes-> isEmpty

[42] GeneralizableElement self.supertypes->forAll(s | self.isVisible(s))

[43] (redundant constraint, convered by [39])

[44] GeneralizableElement self.supertypes->forAll(s | s.isLeaf <> yes)

[45] GeneralizableElement self.isLeaf = no implies self.subtypes-> isEmpty

[46] GeneralizableElement self.supertype->forAll(s | s.oclType = self.oclType)

3-104 Meta Object Facility 1.1 9/1/97 Section 3. MOF Model and Interfaces

[47] Reference self.referencedEnd.otherEnd.type = self.container or self.container.allSupertypes->includes(self.referencedEnd.otherEnd.type)

[48] (redundant constraint, covered by [28])

[49] Reference self.isVisible(self.referencedEnd)

[50] TypedElement self.isVisible(self.type)

[51] AssociationEnd not self.type.oclIsKindOf(Association) and not self.type.oclIsKindOf(DataType)

[52] StructuralFeature not self.type.oclIsKindOf(Association)

[53] Parameter not self.type.oclIsKindOf(Association)

[54] required operation TypeCode baseType : TCKind baseType = if self.kind = tk_alias then self.content_type.baseType else self endif

Constant self.type.oclIsKindOf(DataType) and Set{tk_short, tk_ushort, tk_long, tk_ulong, tk_char, tk_float, tk_double, tk_boolean, tk_string}-> includes(self.type.typeCode.baseType)

[55] Operation self.exceptions->forAll(e | self.isVisible(e))

[56] Import self.imported.oclIsKindOf(Type) or self.imported.oclIsKindOf(Package)

[57] Import self.container <> self.imported

[58] Import not self.container.allContents->includes(self.imported)

[59] for an object with attribute m of MultiplicityType

9/1/97 Meta Object Facility 1.1 3-105 Section 3. MOF Model and Interfaces

self.m.lower <> UNBOUND

[60] for an object with attribute m of MultiplicityType self.m.lower <= self.m.upper or self.m.upper = UNBOUND

[61] for an object with attribute m of MultiplicityType self.m.upper > 0

[62] for an object with attribute m of MultiplicityType self.m.upper < 2 implies (is_ordered = false and is_unique = false)

3-106 Meta Object Facility 1.1 9/1/97 4. Facility Package

4.1 Introduction The definition of a meta-model does not itself provide the capabilities for defining models of the meta-model. The meta-model must be elaborated. Expected elaboration would be the generation of IDL interfaces corresponding to elements in the meta-model, development of interface implementations, and creation of some objects to provide the modeling capabilities. Objects defined in the Facility Package support access and management of an elaborated meta-model instance.

The MOF Model allows classifier-level attributes and operations to be defined for types. To support these features, the MOF introduces the notion of class proxies. Since the elements of a published meta-model are immutable, those Class instances do not provide the classifier-level features. Instead, for each Class in the metamodel, a class proxy is introduced at model elaboration. For the MOF model, the scope of a class proxy is the MofRepository. In general, the scope of each class proxy corresponding to a Class in a metamodel is a model repository.

For instance, if a meta-model defines a Class called table with a classifier-level attribute called averageColumns, representing the average number of columns per Table, over what set of Table instances does this attribute hold? Obviously not all instances of Table in the universe. A distinct boundary is defined, called a model repository.

For each type in a metamodel, one class proxy is defined at elaboration. For generated IDL interfaces, the class proxy is represented with an interface separate from the interface for instances of the type. When instance of an elaborated metamodel is created, one object for each class proxy is created (conceptually, since many implementations are possible). An instance of an elaborated metamodel is a model repository. It consists of the defining meta-model (or access to it, since it may be shared among repositories); a set of class proxies for each instance of Class in the metamodel; and zero or more models conforming to the metamodel. While the metamodel, as immutable, may be shared, the corresponding class proxy instances are scoped to the metamodel.

In addition to class proxies, model elaboration generates association proxies corresponding to each Association in the metamodel. For each Package in the metamodel, a package proxy is defined at elaboration. These class, association, and package proxies mirror the structure of the metamodel, with a package proxy containing the package, type, and association proxies to the Packages, Classes, and Associations in the meta-model.

In addition to the classifier-level features defined in the meta-model, each class proxy is given one or more standard classifier-level features at elaboration. For the class proxy of an abstract Class, only one attribute is added, which provides the instances in the model

9/1/97 Meta Object Facility 1.1 4-1 Section 4. Facility Package

repository which conform to the type. Since the type is abstract, each instance will also conform to one of more subtypes of the type. For a concrete type, another attribute provides the instances specifically of this type within the repository. Also, for a concrete type, a factory operation is provided for creating new instances of the type.

For association proxies, operations are provided for obtaining all the Links of the defining Association within the repository, querying for the Links in which some object participates, adding Links, modifying LinkEnds, and removing Links. For package proxies, attributes provide the class proxies, package proxies, and association proxies corresponding to the Classes, Packages, and Associations contained by the Package corresponding to this package proxy.

The types of the Facility Package provide representations of model repositories. Since this Package contains nothing required by the other Packages, it would be possible to use a MOF which did not include this Package.

Namespace (from Model)

ModelRepository

lookupType( )

MofRepository package : Reflective::RefPackage packageFactory : Reflective::RefPackage

Figure 4-1. The MOF Facility Package

4.2 Facility Package Types

4.2.1 ModelRepository abstract The boundary of a metamodel elaboration a the set of models conforming to the metamodel is the ModelRepository. For the MOF, it is a subtype of ModelRepository,

4-2 Meta Object Facility 1.1 9/1/97 Section 4. Facility Package

the MofRepository. In the industry, repositories take on many forms. Many current repositories include a heterogeneous mix of metamodels and a large number of diverse capabilities. A MofRepository and other ModelRepositories are not repositories on that scale, more likely being just parts of a much larger repository. It is not the goal of this submission, or part of the MOF vision, to be a repository on that scale. So the submission does not define mechanisms for defining and managing collections of ModelRepositories.

A ModelRepository is an abstract representation of a metamodel elaboration and its constituent set of models. Thus, a role of the ModelRepository is a container for models. Because of the wide variety of metamodels which may be defined by the MOF, a specific Type is not defined which can be the ModelRepository for any metamodel. Instead, if metamodelers wish to provide capabilities in a manner similar to the MOF, they are encouraged to define a subtype of ModelRepository specific to, and appropriate for, each metamodel.

Supertypes

Namespace

Operations

lookupType

Returns the class proxy object associated with the fully qualified name of a Type instance in the metamodel. Convenience operation for traversing down meta-levels, from a metamodel to its models, or from a Type in the metamodel to the corresponding instances in the models. Return type: Reflective::RefObject isQuery: yes parameters: qualifiedName : in NameType (multiplicity one or more; ordered; not unique)

Constraints

None

Interface

interface ModelRepositoryClass : ::Model::NamespaceClass { readonly attribute ModelRepositoryUList all_of_kind_model_repository; }; // end of interface ModelRepositoryClass

9/1/97 Meta Object Facility 1.1 4-3 Section 4. Facility Package

interface ModelRepository : ModelRepositoryClass, ::Model::Namespace { ::Reflective::RefObject lookup_type ( in ::Facility::NameTypeList qualified_name) raises (Reflective::SemanticError); }; // end of interface ModelRepository

OCL

None

4.2.2 MofRepository Each instance of MofRepository provides access to the package proxy representing the MOF Model, and a collection of zero or more metamodels (compete or incomplete) which are compliant with the MOF Model.

Supertypes

ModelRepository

Composing Elements

Package Tag

Attributes

packageClass

The package proxy representing MOF’s Model Package within this repository. From this package proxy, all the class proxies and association proxies of the repository, corresponding to the elements of the MOF Model, can be traversed. type: Reflective::RefPackage (the single instance of ModelPackage, the package proxy for MOF’s Model Package) multiplicity: exactly one changeable: no

4-4 Meta Object Facility 1.1 9/1/97 Section 4. Facility Package

packageFactory

The factory object for creating the packageClass, an object required for creation of a MofRepository. type: Reflective::RefPackage (a ModelPackageFactory, which can create the proxy for MOF’s Model Package, and, in so doing, all the class proxies and association proxies for one MofRepository) scope: type-scope multiplicity: exactly one changeable: no

Operations

addPragma

A pragma is a directive to a tool interacting with MofRepository models or perhaps to an aspect of the MOF’s implementation. The pragma may be applied repository- wide, or to a specific top-level package. When the allModels argument is true, the value provided in the appliesTo argument (if any) is ignored;. The MofRepository may or may not support the added pragma. . return type: none (exception raised if pragma is not supported). parameters: pragma : in Tag allModels : in boolean appliesTo : in Package

removePragma

Remove an existing pragma. return type: none (exception raised if pragma is not supported). parameters: pragma : in Tag

modifyPragmaSetting

Change the setting of an existing pragma.

9/1/97 Meta Object Facility 1.1 4-5 Section 4. Facility Package

return type: none (exception raised if pragma is not supported). parameters: pragma : in Tag any : in new_value

Constraints

None

Interface

interface ModelRepositoryClass : ::Model::NamespaceClass { readonly attribute ModelRepositoryUList all_of_kind_model_repository; }; // end of interface ModelRepositoryClass

interface ModelRepository : ModelRepositoryClass, ::Model::Namespace { ::Reflective::RefObject lookup_type ( in ::Facility::NameTypeList qualified_name) raises (Reflective::SemanticError); }; // end of interface ModelRepository

OCL

None

interface MofRepositoryClass : ModelRepositoryClass { readonly attribute MofRepositoryUList all_of_kind_mof_repository; readonly attribute MofRepositoryUList all_of_type_mof_repository;

exception PragmaNotSupported { }; exception PragmaNotPresent { };

MofRepository create_mof_repository ( /* from ModelElement */ in ::Model::NameType name, /* from ModelElement */ in ::Model::AnnotationType annotation, /* from MofRepository */ in ::Reflective::RefPackage package, /* from MofRepository */ in ::Reflective::RefPackage package_factory) raises (Reflective::SemanticError); }; // end of interface MofRepositoryClass

interface MofRepository : MofRepositoryClass, ModelRepository { ::Reflective::RefPackage package () raises (Reflective::StructuralError, Reflective::SemanticError); ::Reflective::RefPackage package_factory () raises (Reflective::StructuralError, Reflective::SemanticError); void add_pragma (in ::Model::Tag pragma, in boolean all_models,

4-6 Meta Object Facility 1.1 9/1/97 Section 4. Facility Package

in ::Model::Package applies_to) raises (MofRepositoryClass::PragmaNotSupported, Reflective::SemanticError); void remove_pragma (in ::Model::Tag pragma) raises (MofRepositoryClass::PragmaNotPresent, Reflective::SemanticError); void modify_pragma (in ::Model::Tag pragma, in any new_value) raises (MofRepositoryClass::PragmaNotPresent, Reflective::SemanticError); }; // end of interface MofRepository

OCL

None

4.3 Facility Package Exceptions The following exceptions are contained in the MOF Model Package. The generated IDL interfaces for the MOF Model make use of more exceptions, which are defined in the Reflective Package and assigned to operations based on criteria determinable during generation.

4.3.1 PragmaNotSupported

Indicates an attempt to use a pragma which is not known or supported by this MofRepository. parameters: none

4.3.2 PragmaNotPresent

An attempt to modify or remove a pragma which is not present was detected. parameters: explanation : out string

9/1/97 Meta Object Facility 1.1 4-7 Section 4. Facility Package

4-8 Meta Object Facility 1.1 9/1/97 5. Reflective Package Types

5.1 Introduction One of the greatest benefits of meta-objects is the support they lend to accessing and manipulating the objects they describe, without prior knowledge of the objects’ interfaces. In the MOF context, an object’s meta-object representation allows users to “discover” the nature of the object, both at a syntactic level and at a deeper level. The MOF provides a set of Reflective interfaces that allow a user program to create, update and access objects, association instances and package instances using model independent interfaces, and also gain access to an object’s meta-objects.

While these capabilities are correctly described as reflective, it must be noted that the MOF does not offer the full repertoire of reflective programming features. Since it does not define object behavior, the MOF does not define interfaces for reflective behavior modification. Even if it did, these interfaces could not be implemented in many CORBA contexts.

The CORBA Interface Repository (IR) and the Dynamic Invocation Interface (DII), provide similar capabilities in the context of a CORBA object’s Interface. However, using the IR and DII for this purpose means that the user cannot make use of the richer semantic information in models defined using the MOF meta-model. For example, the IR can tell the user that the “Model::Contains” IDL interface has an operation called “exists”, but it is only by using MOF meta-objects that the user knows that the “exists” operation tests whether one object “contains” another one.

The MOF Reflective module contains 4 interfaces that are designed to be inherited by “real” MOF objects. The Reflective::RefObject interface provides common functionality for all objects and their class proxies. The Reflective::RefAssociation interface provides common behavior for instances of associations. The Reflective::RefPackage interface provides a common for instances of packages. The fourth interface is the Reflective::RefBaseObject interface, which provides operations common to all reflective interfaces.

With just these base types, and without any prior knowledge of the types or composition of a model, the user can:

• retrieve meta-object descriptions of object types, association instances and package instances • find all objects within a package instance of a given type; • create new object instances; • access and update object attributes and references, and invoke operations;

9/1/97 Meta Object Facility 1.1 5-1 Section 5. Reflective Package Types

• query, navigate, and update associations between objects.

Note however that the access and update functionality above is all available through the “model specific” interfaces defined by the MOF’s model to IDL mapping. The Reflective interfaces do not allow the user to access or update objects and associations contrary to their meta-object descriptions. For example, they do not undefined attributes to be created or links to be created or updated in violation of multiplicity constraints. Similarly, they do not allow the user to bypass the checking of Constraint violations.

5.2 The Reflective Module In this section we describe the interfaces defined in the “Reflective” module. While these are described in terms of the MOF meta-model, the reader should understand that this a notational convenience rather than a semantic statement. The Reflective layer of the MOF should really be viewed as an interface onto the data model that underpins the MOF meta-model. The full data model is not described in terms of the MOF meta- model, but is described elsewhere in this document in other terms.

The Reflective “Package” makes use of a limited subset of the MOF meta-model. At the top level, it only defines Types, DataTypes and Exceptions. Types are defined using Operations only. In addition, the Reflective “Package” avoids using the types defined in the Model Package defined previously. The resultant MOF Package can be translated using the standard mapping rules to produce self-contained, compilable CORBA IDL.

Unfortunately, the IDL generated from the Reflective “Package” contains a number of oddities. This is predictable, given that the MOF model and the IDL mapping rules are designed for information modeling at a more abstract level. In reality, the Reflective "Package" is not an information model at all in the normal sense. All of the model's relationships are hidden behind operations whose semantics are inherently inexpressible in terms of the MOF Model. It was therefore decided to write code the definitive IDL for the Reflective interfaces directly in CORBA IDL.

The Reflective module has been designed to support a simpler data model than that which underlies by the MOF meta-model and the IDL mapping rules. For example:

• MOF Attributes and References are treated as identical. • MOF Classifier level attributes and operations on Types are not explicitly supported. Hence there is no explicit support for typeClass proxy objects. • The operation that gives access to an object’s meta-objects returns a RefObject instance rather than some subtype of Model::ModelElement

In this way, it is anticipated that the Reflective interfaces will support a broader range of data models than is required to support the MOF model to IDL mapping.

Support for specific meta-model / data model functionality such as References, classifier-level Attributes and so on depend on the way that the Reflective interface is used. It is assumed that the system designer will specify a coherent set of Usage Conventions that will cover issues such as the inheritance patterns for the Reflective interfaces, the parameter and result encoding conventions, and the meanings of the exceptions raised.

5-2 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

In the case of interfaces that result from applying the IDL mapping to a model expressed using the MOF model, the Usage Conventions are described in the section on Reflective Usage Conventions .

5.2.1 Reflective::RefBaseObject abstract The RefBaseObject interface is inherited by the other three reflective interface. It provides common operations for testing for object identity, returning an object’s meta- object and returning its “repository container” as required for implementing structural constraints such as the MOF’s type closure rule and composition restrictions.

Supertypes

none (root object)

Operations

metaObject

A reflective object reveals its nature through the meta-object returned by the metaObject operation. The CORBA object type of the returned meta- object depends on the usage conventions which govern this use of the Reflective interfaces. The operation may return an invalid (nil) object reference if no descriptive meta-objects for the object are available. return type: DesignatorType isQuery: yes parameters: none required

itself

The itself operation tests whether this object and another object provided as an argument are identical. The precise semantics of this operation depends on the usage conventions. return type: boolean isQuery: yes parameters: otherObject : in RefBaseObject

9/1/97 Meta Object Facility 1.1 5-3 Section 5. Reflective Package Types

repository_container

The repository_container operation returns the repository container for an object. The precise semantics of this operation depends on the usage conventions. return type: RefBaseObject isQuery: yes

5.2.2 Reflective::RefObject abstract The RefObject interface provides the meta-object description of an object that inherits from it, provides generic operations for testing for object identity and type membership, and a range of operations for accessing and updating the object in a model independent way.

The model assumed by the interface is that an object has structural features and operations. The model allows structural features to have single values or collection values. In the latter case, the collection values may have ordering or uniqueness semantics. There is provision for creation of new object instances, and for obtaining the set of objects that exist in a context.

Supertypes

RefBaseObject

Operations

isInstanceOf

This operation tests whether the RefObject is an instance of the type described by the “someType” meta-object. If the “considerSubtypes” argument is true, an object whose type is a subtype of the type described by “someType” will be considered as an instance of the type. When the type system does not have a notion of subtyping, the “considerSubtypes” argument is ignored. return type: boolean isQuery: yes parameters: someType : in DesignatorType considerSubtypes : in boolean

5-4 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

createInstance

This createInstance operation creates a new instance of the RefObject’s most derived type. The “args” list gives the initialization parameters for the new object as required. If it is inappropriate to create an object (e.g. the type is “abstract”) or the arguments are incorrect, exceptions will be raised. If a meta-model supports multiple “factory” operations for a given type, the usage conventions should define how to decide which factory operation to use based “args” provided. (The invokeOperation operation is also available as a possible alternative.) return type: RefObject parameters: args : in ValueType (multiplicity: zero or more; ordered)

allObjects

The allObjects operation returns the collection of all known instances of this objects model type that are present in the context. If the model has a well defined notion of subtyping and “includeSubtypes” is true, the resulting collection will also include the object instances that are subtypes. The specific definition of what constitutes the object’s context should be defined in the usage conventions. return type: RefObject (multiplicity zero or more; unique; unordered) isQuery: yes parameters: includeSubtypes : in boolean

9/1/97 Meta Object Facility 1.1 5-5 Section 5. Reflective Package Types

setValue

The setValue operation assigns a new “value” to a “feature” (e.g. attribute or object link) of the object as allowed by the object’s type and its meta- model. The precise meaning of assignment, the kinds of features it applies to, and the set of exceptions that can be raised are dependent on the usage conventions. Standard exceptions are raised if the “feature” is not a known changeable feature of the object, if the type of "value" is incorrect, or if the update would violate structural or semantic integrity constraints. For meta-models that support collection valued features, the setValue operation replaces the current collection value with a new one. More specialized operations are defined below for updating the individual values of a feature collection. return type: nothing returned parameters: feature : in DesignatorType value : in ValueType

value

The value operation fetches the current value of some “feature”. The precise method of obtaining the value returned and the set of exceptions that can be raised are dependent on the usage conventions. Standard exceptions are raised if the “feature” is not known, is not appropriate for “fetching”, or if some semantic error was detected during the access attempt. return type: ValueType isQuery: yes parameters: feature : in DesignatorType

addValue

The addValue operation allows the user to add a new component value into a feature that is a collection. The precise semantics of the add operation depends on the usage conventions. Standard exceptions are raised if the “feature” is not a known changeable collection, if the “value” has the wrong type, or if the add operation would violate structural or semantic integrity rules. return type: nothing returned

5-6 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

parameters: feature : in DesignatorType value : in ValueType

addValueBefore

The addValueBefore operation is similar to the addValue operation, except that the user can control the point at which the new value is inserted into the collection. The operation is intended to be used to update ordered collections with unique elements. The precise semantics of the insertion (including the position) depend on the usage conventions. NotFound should be raised if “existingValue” is not a member of the collection. Standard exceptions are raised for other errors as described above. return type: nothing returned parameters: feature : in DesignatorType value : in ValueType existingValue : in ValueType

addValueAt

The addValueAt operation is similar to the addValueBefore operation, except that the user specifies the insertion point using an index. The operation is intended to be used to update ordered collections with non- unique elements. The precise semantics of the insertion (including the position) depend on the usage conventions. If the “position” value does not denote a valid location in the collection, InvalidPosition should be raised. Standard exceptions are raised for other errors as described above. return type: nothing returned parameters: feature : in DesignatorType value : in ValueType position : in long

9/1/97 Meta Object Facility 1.1 5-7 Section 5. Reflective Package Types

modifyValue

The modifyValue operation replaces one value in a feature collection with another one. The operation is intended to be used to update collections with unique elements. The precise semantics of the update depend on the usage conventions. Standard exceptions are raised if the “feature” is not a known changeable collection, if the “newValue” has the wrong type or if the update would violate structural or semantic integrity constraints. Similarly, the NotFound exception should be raised if the “existingValue” is not in the collection. return type: nothing returned parameters: feature : in DesignatorType existingValue : in ValueType newValue : in ValueType

modifyValueAt

The modifyValueAt operation is similar to the modifyValue operation, except that the existing value to be modified is specified by position rather than by value. The operation is intended to be used to update collections with non-unique elements. The precise semantics of the modification (including the position) depend on the usage conventions. Standard exceptions are raised if the “feature” is not a known changeable collection, if the “newValue” has the wrong type or if the update would violate structural or semantic integrity constraints. If “position” does not denote a valid location in the collection, InvalidPosition will be raised. return type: nothing returned parameters: feature : in DesignatorType newValue : in ValueType position : in long

5-8 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

removeValue

The removeValue operation is used to remove a value from a feature collection. The operation is intended to be used with collections with unique elements. The precise semantics of the deletion depend on the usage conventions. Standard exceptions are raised if the “feature” is not a known changeable collection, if the “existingValue” has the wrong type, or if the removal would violate structural or semantic integrity constraints. If the “existingValue” is not present in the collection, NotFound will be raised. return type: nothing returned parameters: feature : in DesignatorType existingValue : in ValueType

removeValueAt

The removeValueAt operation is similar to the removeValue operation except that the value to be removed is specified by an index. The operation allows removal from collections with non-unique elements. The precise semantics of the deletion depend on the usage conventions. Standard exceptions are raised if the “feature” is not a known changeable collection, or if the removal would violate structural or semantic integrity constraints. If the “position” is out of range for the collection, InvalidPosition will be raised. return type: nothing returned parameters: feature : in DesignatorType position : in long

invokeOperation

The invokeOperation operation causes a model-specific operation to be invoked with the arguments supplied. The conventions for encoding and passing arguments, results and exception values should be defined by the usage conventions. Exceptions are raised if “requestedOperation” does not designate an operation for the object, or the number or types of the “args” are not as required. If the invoked operation raises an exception, this is mapped onto OtherException, with exception parameters as defined by the usage conventions. return type: ValueType (multiplicity: zero or more; ordered; not unique)

9/1/97 Meta Object Facility 1.1 5-9 Section 5. Reflective Package Types

parameters: requestedOperation : in DesignatorType args : inout ValueType (multiplicity: zero or more; ordered; non-unique)

5.2.3 Reflective::RefAssociation abstract The RefAssociation interface provides the meta-object description of an association that inherits from it. It also provides generic operations querying and updating the links that belong to the association.

The model of association supported by this interfaces is of collection of two ended asymmetric links between objects. The links may be viewed as ordered on one or other of the ends, and there may be some form of cardinality constraints on either end.

The RefAssociation interface is designed to be used with associations that contain no duplicate links, though this is not an absolute requirement. There is no assumption that different association objects for a given association type are mutually aware. Links are modeled as having no object identity.

(A data model that required “heavy weight” links with object identity (e.g. so that attributes could be attached to them) would need to represent them as RefObject instances. The RefAssociation interface could be used to manage light weight links between heavy weight link objects and the objects they connect. Similar techniques could be used to represent N-ary associations. However, in both cases better performance would be achieved using a purpose built reflective layer.)

Supertypes

RefBaseObject

Operations

exists

The exists operation tests whether the supplied link is a member of this association. The precise meaning of link existence depends on the usage conventions The ends of as Link must be given in the order defined by the association’s defining model. The InvalidLink exception will be raised if the CORBA object types of the two ends of “someLink” do not match the defining model. return type: boolean isQuery: yes

5-10 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

parameters: someLink : in Link

query

Given an object value for one end of a link, the query operation returns the set of objects linked to it in the association. The precise semantics of “linked to” are determined by the usage conventions. The operation should raise InvalidDesignator if the “queryEnd” designator is not a known association "end", or InvalidObject if the “queryObject” is invalid, or does not have an appropriate type. return type: RefObject (Multiplicity zero or more; ordered; unique)

isQuery: yes

parameters: queryEnd : in DesignatorType queryObject : in RefObject

addLink

The addLink operation adds “newLink” into the set of links that comprise the association. If the association has ordering semantics, the link should be inserted at the last position for that ordering. As with other operations, the precise semantics of link insertion depends on the usage conventions. The addLink operation should raise InvalidLink if the “newLink” object references are invalid or have the wrong type, and other standard exceptions if adding the link violates structural or semantic integrity constraints. return type: nothing returned parameters: newLink : in Link

addLinkBefore

The addLinkBefore operation adds “newLink” at a particular position in the association. The precise semantics of link insertion (including the position at which the link is inserted) depends on the usage conventions. The operation should raise standard exceptions if the “newLink” object references are invalid or have the wrong type, if either of “positionEnd” or “positionValue” is inappropriate, if “positionValue” is not found in an existing link, or if adding the link violates structural or semantic constraints.

9/1/97 Meta Object Facility 1.1 5-11 Section 5. Reflective Package Types

return type: nothing returned parameters: newLink : in Link positionEnd : in DesignatorType positionValue : in RefObject

modifyLink

The modifyLink operations replaces one or other of the end values for an existing link with a new value. The precise semantics of the update depend on the usage conventions. However, it is recommended that the update be modeled as a single logical operation rather separate deleteLink and an addLink operations. Standard exceptions should be raised if the arguments are incorrect or the modification violates structural or semantic constraints. return type: nothing returned parameters: exisitingLink : in Link positionEnd : in DesignatorType positionValue : in RefObject

removeLink

The removeLink operation removes the “existingLink” from the association. The precise semantics of link removal depend on the usage conventions.

Standard exceptions should be raised if “existingLink” is invalid, does not exist, or if removing it would violate structural or semantic constraints.

return type: nothing returned parameters: existingLink : in Link

5.2.4 Reflective::RefPackage abstract The RefPackage interface is an abstraction for accessing a collection of objects and their associations. The interface provides an operation to access the meta-object description for the package, and operations to access the package instance’s class proxy objects (one for each type) and its association objects.

5-12 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

Supertypes

RefBaseObject

Operations

getClassRef

The getClassRef operation returns the object reference for a class proxy object for a given type in the package’s model. The precise type and purpose of the proxy object depends on the usage conventions. If the meta-model does not require the use of a class proxy object for the type, then an invalid object reference should be returned. The InvalidDesignator exception should be raised if “type” does not denote a type in the package’s meta-object description. return type: RefObject isQuery: yes parameters: type : in DesignatorType

getAssociation

The getAssociation operation returns a object reference for an association object that holds links between the types in the context of the package instance. The precise type and semantics of the association object returned depend on the usage conventions. The InvalidDesignator exception should be raised if “association” does not denote a valid association in the package’s meta-object description. return type: RefAssociation isQuery: yes parameters: association : DesignatorType

getNestedPackage

The getSubpackage operation returns a package instance object reference for a package nested with the current one. The precise type and semantics of the package object returned depend on the usage conventions. The InvalidDesignator exception should be raised if “nestedPackage” does not denote a nested package in the package’s meta-object description. return type: RefPackage

9/1/97 Meta Object Facility 1.1 5-13 Section 5. Reflective Package Types

isQuery: yes parameters: nestedPackage : DesignatorType

5.3 The CORBA IDL for the Reflective Interfaces This section describes the relevant excerpts of the CORBA IDL for the Reflective module.

5.3.1 Introduction The Reflective module starts with forward declarations of the 3 object types RefObject, RefAssociation and RefPackage. module Reflective {

interface RefBaseObject;

interface RefObject; typedef sequence < RefObject > RefObjectUList;

interface RefAssociation;

interface RefPackage;

5.3.2 Data Types Operations on the Reflective interfaces need to identify the elements (e.g. attributes, operations, roles, types, etc.) that they apply to. Some exceptions have similar requirements. The type DesignatorType is used to denote uses of RefObject with this meaning. typedef RefObject DesignatorType;

Values of attributes, operation parameters and results and so on are passed using the CORBA “any” data type. The type ValueType is used to denote uses of “any” with this meaning. The encoding of values using the “any” type is model specific. typedef any ValueType;

Links are expressed as bounded sequences of (two) RefObject values.

5-14 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

typedef sequence Link;

5.3.3 Common Exceptions The exceptions described in this section are raised in a variety of interfaces. These include the Reflective interfaces, the Model interfaces and interfaces produced by the MOF model to IDL mapping.

The StructuralError exception is raised when the implementation detects that an operation violates the structural integrity of the model. The kind of error is expressed as a CORBA string so that different data models can support different structural integrity rules.

In the context of the MOF IDL mapping rules, six kinds of structural error may occur:

• An “Underflow” error occurs when a collection contains fewer values than is required by Multiplicity.lower. • A “Overflow” error occurs when a collection contains more values than is allowed by Multiplicity.upper. • A “Duplicate” error occurs when a collection with Multiplicity.is_unique true contains multiple copies of a given value.

• A “Type Closure” error can occur when an update would insert an object into an association object belonging to the “wrong” package instance. The situation in which this error may occur is when the object’s Type has a Reference to the Association. See the INSERT CROSS-REFERENCE section.

• A “Composition” error can occur when an update would make an object a member of a composite which crosses a control boundary. See the INSERT CROSS- REFERENCE section.

• A “Invalid Object” error occurs when a CORBA invalid (nil) object reference or a reference to a non-existent object is detected. (Note: an object server is not required to check that object references supplied to it point to valid objects, or to guarantee that they will continue to do so.)

Since a given operation can result in more than one structural error, the exception returns a sequence of violations. For each one it identifies the model element whose multiplicity constraints have been violated and (in the case of a Duplicate violation) the set of values that have been duplicated.

typedef sequence < ValueType > ErroneousValues;

// The following constant give the strucural violation kinds // defined for object servers conforming to the IDL mapping rules. const string UNDERFLOW_VIOLATION = “underflow”; const string OVERFLOW_VIOLATION = “overflow”;

9/1/97 Meta Object Facility 1.1 5-15 Section 5. Reflective Package Types

const string DUPLICATE_VIOLATION = “duplicate”; const string TYPE_CLOSURE_VIOLATION = “type closure”; const string COMPOSITION_VIOLATION = “composition”; const string INVALID_OBJECT_VIOLATION = “invalid object”;

struct StructuralViolation { string violation_kind; RefObject element_designator; ErroneousValues offending_values; };

typedef sequence < StructuralViolation > StructuralViolationSet;

exception StructuralError { StructuralViolationSet violations; };

The ConstraintViolation exception is raised when an operation violates a formal model constraint. (The ConstraintViolation type is also returned by the ModelElement::verify operation in the Model Package.)

struct ConstraintViolation { RefObject constraint_designator; ErroneousValues offending_values; string explanation_text; };

exception ConstraintError { ConstraintViolation violation; };

The SemanticError exception is raised when an operation violates some informal semantic check implemented by the object, or when some other implementation specific error occurs.

struct ErrorDescription { string error_name; ErroneousValues offending_values; string explanation_text; };

exception SemanticError { ErrorDescription error; };

The NotFound exception is raised when an operation attempts to modify or remove a non-existent association link or attribute value.

5-16 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

exception NotFound {};

The NotSet exception is raised when an operation attempts to read the singleton value of an optional element; i.e. an element defined with cardinality [0..1].

exception NotSet {};

The BadPosition exception is raised when a positional update operation has a position parameter whose value is out of range; i.e. it doesn’t indicate a valid position in the collection being updated. exception BadPosition {};

The AlreadyCreated exception is raised when an attempt is made to create a second instance of a type that has been defined as a “singleton” type. exception AlreadyCreated {};

5.3.4 Reflective Exceptions These exceptions will be raised by operations in the Reflective interfaces when an operation is invoked with parameter values that contradict the object’s meta-object description in some way.

When an object that supports the Reflective interfaces detects an error that could be expressed as either a Reflective exception or a Common exception, it should raise the latter rather than the former. For example, if one end of Link is an invalid object reference, StructuralError should be raised rather than InvalidLink.

The InvalidLink exception is raised when the RefObject instances given in a Link are not members of the type required. exception InvalidLink {};

The InvalidDesignator exception is raised when a meta-object supplied as a DesignatorType is not appropriate. For example:

9/1/97 Meta Object Facility 1.1 5-17 Section 5. Reflective Package Types

• when it denotes the wrong kind of model element: e.g. an attribute was given where an operation is required • when it denotes a model element that is not a feature in the right context; e.g. an attribute that applies to another type, possibly in another model • when it denotes a feature that has the wrong multiplicity for the operation requested; e.g. when an unordered feature is used with add_before, or an update operation is applied to a read-only feature. • when it is an unrecognizable object • when it is an invalid object reference.

The “designator” parameter indicates the meta-object that was incorrect, and the “element_kind” parameter tells the client what kind of model element was expected. (This is expressed as a string whose value depends on the usage conventions that apply.)

exception InvalidDesignator { DesignatorType designator; string element_kind; };

The InvalidValue exception is raised when a ValueType parameter of a Reflective operation is an ANY of the wrong kind. For example, when the supplied any contains:

• a singleton value where a sequence was expected, or vice versa • a value of the wrong base type The exception returns the “designator” for which the value was supplied and its kind, the actual value that was incorrect and the CORBA TypeCode for the type that it should have been.

exception InvalidValue { DesignatorType designator; string element_kind; ValueType value; TypeCode type_expected; };

The InvalidObject exception is raised when a RefObject parameter of a Reflective operation is of the wrong kind. The exception returns the “designator” for which the value was supplied, the object that was supplied and the CORBA TypeCode for the type that it should have been.

exception InvalidObject { DesignatorType designator; RefObject obj;

5-18 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

TypeCode type_expected; };

The MissingParameter and TooManyParameters exceptions are raised by createInstance and invokeOperation when they are called with the wrong numbers of parameters. In the case of MissingParameter, the “designator” member indicates the first missing parameter.

exception MissingParameter { DesignatorType designator; };

exception TooManyParameters {};

The OtherException exception is raised when a call to invoke_operation results in some model specific exception. The exception gives the designator for the model exception raised, and the values returned with the model exception.

exception OtherException { DesignatorType exception_designator; ValuesType exception_values; };

5.3.5 Reflective::RefObject Interface The RefBaseObject interface is an abstract interface that provides core reflective capabilities RefObject, RefAssociation and RefPackage. The operations supported by the interface were described in a previous section.

interface RefBaseObject {

DesignatorType meta_object ();

boolean itself (in RefBaseObject other_object);

RefBaseObject repository_container ();

}; // end of RefBaseObject

9/1/97 Meta Object Facility 1.1 5-19 Section 5. Reflective Package Types

5.3.6 Reflective::RefObject Interface The RefObject interface is an abstract interface that provides Reflective capabilities for an object type defined by a higher level meta-model. It is not anticipated that objects will be created whose most-derived type is RefObject. The operations supported by the interface were described in a previous section.

interface RefObject : RefBaseObject {

boolean is_instance_of (in DesignatorType obj_type, in boolean consider_subtypes);

RefObject create_instance (in ValueTypeList args) raises (TooManyParameters, MissingParameter, InvalidValue, AlreadyCreated, StructuralError, ConstraintError, SemanticError);

RefObjectSet all_objects (in boolean include_subtypes);

void set_value (in DesignatorType feature, in ValueType value) raises (InvalidDesignator, InvalidValue, StructuralError, ConstraintError, SemanticError);

ValueType value (in DesignatorType feature) raises (InvalidDesignator, SemanticError);

void add_value (in DesignatorType feature, in ValueType value) raises (InvalidDesignator, InvalidValue, StructuralError, ConstraintError, SemanticError);

void add_value_before (in DesignatorType feature, in ValueType value, in ValueType existing_value) raises (InvalidDesignator, InvalidValue, StructuralError, ConstraintError, SemanticError);

void add_value_at (in DesignatorType feature, in ValueType value,

5-20 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

in long position) raises (InvalidDesignator, InvalidValue, InvalidPosition, StructuralError, ConstraintError, SemanticError);

void modify_value (in DesignatorType feature, in ValueType existing_value, in ValueType new_value) raises (InvalidDesignator, InvalidValue, NotFound, StructuralError, ConstraintError, SemanticError);

void modify_value_at (in DesignatorType feature, in ValueType new_value, in long position) raises (InvalidDesignator, InvalidValue, InvalidPosition, StructuralError, ConstraintError, SemanticError);

void remove_value (in DesignatorType feature, in ValueType existing_value) raises (InvalidDesignator, InvalidValue, NotFound, StructuralError, ConstraintError, SemanticError);

void remove_value_at (in DesignatorType feature, in ValueType existing_value, in long posotion) raises (InvalidDesignator, InvalidValue, InvalidPosition NotFound, StructuralError, ConstraintError, SemanticError);

ValueType invoke_operation (in DesignatorType requested_operation, in ValueTypeList args) raises (InvalidDesignator, TooManyParameters, MissingParameter, InvalidValue, OtherException, ConstraintError,

9/1/97 Meta Object Facility 1.1 5-21 Section 5. Reflective Package Types

SemanticError);

}; // end of interface RefObject

5.3.7 Reflective::RefAssociation Interface Reflective::RefAssociation is the abstract interface that provides Reflective capabilities for a MOF association (table) and similar objects. It is not anticipated that objects would be created whose most-derived type is RefAssociation.

The operations supported by the interface were described in a previous section.

interface RefAssociation : RefBaseObject {

boolean exists (in Link some_link) raises (ElementHasWrongType, InvalidLink, SemanticError);

RefObjectUList query (in DesignatorType query_end, in RefObject query_object) raises (InvalidDesignator, InvalidObject, SemanticError);

void add_link (in Link new_link) raises (InvalidLink, StructuralError, ConstraintError, SemanticError);

void add_link_before (in Link new_link, in DesignatorType position_end, in RefObject position_value) raises (InvalidDesignator, InvalidObject, InvalidLink, NotFound, StructuralError, ConstraintError, SemanticError);

void modify_link (in Link existing_link, in DesignatorType position_end, in RefObject position_value) raises (InvalidDesignator, InvalidObject, InvalidLink, NotFound, StructuralError, ConstraintError,

5-22 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

SemanticError);

void remove_link (in Link existing_link) raises (InvalidLink, NotFound, StructuralError, ConstraintError, SemanticError);

}; // end of interface RefAssociation

5.3.8 Reflective::RefPackage Interface Reflective::RefPackage is the abstract interface that provides Reflective capabilities for a MOF package instance and similar objects. It is anticipated that the RefPackage interface would not be implemented directly.

The operations supported by the interface were described in a previous section.

interface RefPackage : RefBaseObject {

RefObject get_class_ref (in DesignatorType type) raises (InvalidDesignator);

RefAssociation get_association (in DesignatorType association) raises (InvalidDesignator);

RefPackage get_nested_package (in DesignatorType nested_package) raises (InvalidDesignator)

}; // end of interface RefPackage

5.4 Reflective Usage Conventions for the MOF IDL Mapping This section describes the relationship between the Reflective layer and the set of model specific interfaces produced by apply the IDL mapping rules to a MOF model. Since the IDL interfaces for the MOF Model package are produced this way, this section applies to those interfaces as well.

5.4.1 Reflective Interface Inheritance The IDL mapping defines five kinds of CORBA objects:

• For each MOF Type, there is an IDL interface for objects that represent instances of the type. This contains IDL operations to access and update the Attributes and References for each type instance, and invoke the Operations for them.

9/1/97 Meta Object Facility 1.1 5-23 Section 5. Reflective Package Types

• For each MOF Type, there is also an IDL interface for the type’s class proxy objects. This contains IDL operations to access and update the classifier-level Attributes and invoke the classifier-level Operations for the type. It also contains IDL attributes that hold the collections of type instances, and the IDL operations for creating the instances. (The class proxy interface is also inherited by the type interface above • For each MOF Association, there is an IDL interface for association objects. This contains IDL operations for querying and updating an association’s links. • For each MOF Package, there is an IDL interface for objects that represent instances of the package. This contains IDL attributes which hold references to the instance’s association and class proxy objects, and to the instances of any nested packages. • For a top level MOF Package, there is an IDL interface for a package factory object.

All type and class proxy IDL interfaces that conform to the standard IDL mapping will inherit from the Reflective::RefObject interface. For a type instance, the RefObject interface gives access to the instance level and class level attributes and operations and the references. For a class proxy object, only the class level attributes and operations are available. The other difference between the type and class proxy cases is that, in the latter case, the is_instance_of operation tests to see if the object is a proxy for the parameter type rather than an instance of the type.

Apart from this, the RefObject interface will behave the same for both type instances and class proxy objects. In both cases, the create_instance operation will create an new type instance in the context of the current object’s package instance, and the all_objects operation will return the type instances from the current package instance. The feature access and update operations and the create and invoke operations will behave precisely as the corresponding operations defined in the IDL mapping. All checks for multiplicity, constraint and semantic errors will be precisely as for the IDL mapped interfaces.

All association IDL interfaces that conform to the standard IDL mapping will inherit from the Reflective::RefAssociation interface. An association object will manage the links for a given association that belong to a given package instance. The access and update operations will behave precisely as the corresponding update operations defined in the IDL mapping. All checks for multiplicity, constraint and semantic errors will be precisely as for the IDL mapped interfaces.

Similarly, all package IDL interfaces that conform to the standard mapping will inherit from the Reflective::RefPackage interface. The get_class_ref , get_association and get_nested_package operations will return class proxies, association objects and package instance objects belonging to the current package instance. They will have most derived types as defined by the IDL mapping.

The operations defined in Reflective::RefBaseObject map onto mapped operations as follows:

• The repository_container operation maps onto the enclosing_package_ref operation defined in a the class proxy, association and package interfaces. • The itself and meta_object operations are pure reflective operations; i.e. they have no corresponding operations in the IDL mapped interfaces.

5-24 Meta Object Facility 1.1 9/1/97 Section 5. Reflective Package Types

5.4.2 Parameter Mapping for Reflective Operations. This section describes how an implementation of the Reflective interfaces (in the context of the standard IDL mapping) should encode and interpret the various operation parameters and results.

In cases where the Reflective interfaces use a DesignatorType, the implementation should expect or supply an RefObject belonging to the appropriate subtype of Model::ModelElement depending on the context. The value should be an object reference for a frozen MOF model element object from the defining meta-model description. For example, meta_type should return an object reference for a Model::Type. Similarly, lookup_association should expect a Model::Association object reference.

In cases where the Reflective interfaces use a ValueType, the implementation should expect or supply a CORBA “any” value which holds a value of the correct type, depending on the context:

• For a single-valued feature, the ValueType should contain an instance of the appropriate base type or (for an object reference) a subtype of that type. • For a multi-valued feature in a context where a single value is expected, the ValueType should contain a simple instance as above. • For a multi-valued feature in a context where multiple values may be supplied or returned, the ValueType should contain a sequence of the base type. It is recommended that the typecode be CORBA::TypeCode::equal to that used for the collection in the mapped IDL. In cases where the Reflective interfaces use the RefObject type, the implementation should expect or supply an object reference for instance of a type or association interface defined by the IDL mapping. The instance should have a CORBA object type corresponding to the defining MOF model element (under the mapping), or in some cases a subtype of that type.

The sequence of ValueType that are supplied as the “params” argument to create_instance should contain the correct number of parameters, in the correct order with the correct types. In the case of invoke_operation, the implementation should ignore the values passed to it in the “out” parameter positions, and may return any values it chooses in the “in” parameter positions.

The semantics of the reflective forms of the add, modify and delete operations use the same as for the IDL mapped forms. Each collection is viewed as an array of elements whose elements are subscripted starting from zero. For positional updates, elements are specified either by value or by a position number; i.e. a subscript value starting from zero.

Given that the collection is defined to be ordered with unique elements, the semantics of the update operations are as follows:

• A positional add (i.e. add_before or add_at) inserts the new value or link into the array between the specified element and the one immediately before it. In other words, after the insertion, the subscript of the inserted value / link will be the

9/1/97 Meta Object Facility 1.1 5-25 Section 5. Reflective Package Types

original subscript of the specified element, and the subscripts of specified element and all following ones will have been increased by one. • A non-positional add inserts the new value or link at the end of the array, after all existing elements. • A modify operation replaces the specified element with a new value or link. The replacement should have the same subscript in the array as the original, as should all other elements. • A delete operation removes the specified element from the array. The subscripts of all elements that followed the specified element in the original array are decreased by one.

When the collection is ordered but duplicate elements are allowed, the forms of positional add, modify and delete that specify an element by value are defined to operate on the first element (i.e. the one with the lowest subscript) that matches the value / link supplied. The forms that specify the value by position number work as described above.

When the collection is unordered, the relative position of the elements in the collection is undefined, and may change at any time. This has the following consequences:

• The effects of modify or delete operations that use a position number cannot be predicted. In this case, the operations should raise the CORBA System Exception NO_IMPLEMENT to avoid. (No analog of these operations is available through the IDL mapped interfaces either.) • For an unordered collection with duplicates, the modify and delete operations may update or remove any value / link that matches. • The position specification for a positional add operation on an unordered collection is irrelevant, and may be ignored by an implementation.

5-26 Meta Object Facility 1.1 9/1/97 6. MOF Semantics Details

6.1 Introduction Sections 3 - 5 described the structure and semantics of the MOF Model. This section provides a more detailed semantic description of certain topics requiring more in-depth explanations.

6.2 Associations, Aggregations, and References

6.2.1 Associations Associations provide an essential tool for metamodel development. Many modeling languages have forgone associations, utilizing attributes, references, or both. An association conveys additional meaning, and can be used to associate types without impact on the definition of either type. For the MOF, the ability to associate types without alteration is vital.

The MOF restricts the number of types defining an association to be at most two (binary associations) as a simplification. However, the definition of Association, AssociationEnd, and Reference lend themselves for easy extension or evolution to support higher-order associations, as described in Appendix F: Future Directions of the MOF

A Link connects two objects (or one object to itself). A Link is defined as a connection between two objects, and can be considered as an ordered pair of objects (except the Link does not define, contain, or destroy the objects). Every link is an instance of exactly one Association. For example consider two Types, State and Transition, and the Association ExitsThrough (State ExitsThrough Transition). Suppose there are two instances of State, s1 and s2, and two instances of Transition, t1 and t2; and that there are two links (s1, t1) and (s2, t2). These links are instances of the ExitsThrough Association.

A LinkEnd defines an endpoint of a Link – the connection between a Link and an instance. Considering the Link as an ordered pair, a LinkEnd corresponds to an element of the pair (either the first or the second element). Each LinkEnd is an instance of exactly one AssociationEnd. For this example Association, the AssociationEnds have been defined as exit and source. The exit AssociationEnd defines the participation of Transition objects in the Association; the source AssociationEnd defines the participation of State objects. In the links (s1, t1) and (s2, t2), the elements occupied by s1 and s2 correspond to the source AssociationEnd and the elements occupied by t1 and t2 correspond to the exit AssociationEnd.

9/1/97 Meta Object Facility 1.1 6-1 Section 6. MOF Semantics Details

The distinction between LinkEnds and participating instances becomes clearer when considering Associations which relate a Type to itself. For instance, consider a Association representing the fact that a System may be composed of Subsystems; the Association is Contains, the Type at both ends is System, and the AssociationEnds are system and subsystem. If the first AssociationEnd is system, and sys1 contains sys2, then a Link would be (sys1, sys2). Yet, if sys1 were also a subsystem to another System, sys3, then sys1 would be in a LinkEnd corresponding to the subsystem AssociationEnd in the link (sys3, sys1).

6.2.1.1 Constraints on Associations Associations are constrained by attributes defined on their AssociationEnds. The complex data type MultiplicityType is defined as a constraint on collections. In its uses as an attribute of AssociationEnd, the constrained collection is defined as the instances connected by LinkEnds corresponding to an AssociationEnd, where each LinkEnd’s opposite LinkEnd connects the same instance. Stated another way – given an instance, the collection of LinkEnds corresponding to an AssociationEnd and connecting that instance, the constrained collection contains the instances connected by those LinkEnds’ opposite LinkEnds.

Considering the first example, the ExitsThrough Association, the collections corresponding to the exit AssociationEnd are defined as the instances of Transition which are connected via Links to a single State instance, with that State instance connected to the links by LinkEnds defined by the source AssociationEnd. So, if the ExitsThrough Association consists of the Links (s1, t1), (s2, t2), (s1, t3), and (s3, t4), then the two constrained collections would be {t1, t3}, {t2}, and {t4}.

This constraining attribute of an AssociationEnd, MultiplicityType, has four fields, lower, upper, isOrdered, and isUnique (isUnique will always be true for AssociationEnds, as a simplification). The lower and upper fields define cardinality constraints on the collection. Cardinality is the count of the number of elements, so lower constraint specifies the minimum number of elements; the upper constraint specifies the maximum number of elements. In many cases, the maximum number may be unconstrained (also called unbounded). When the upper constraint is set to one, the collection constraint is sometimes referred to as single-valued; multi-valued refers to a collection constraint with upper set to greater than one, or unbounded. When the lower field is set to zero, the collection constraint can be referred to as optional; lower set to a number larger than zero can be called required.

When isOrdered is set to true, then the constrained collection preserves the ordering of its elements. These elements are not sorted by any mechanism of the AssociationEnd, but typically means are provided for inserting elements into the collection at prescribed location. Thus, the constrained collection is not responsible for determining the order of the elements, only for maintaining the ordering.

6.2.1.2 Dynamic Semantics of AssociationEnd Constraints These collection constraints affect the behavior of models, since there is enforcement of the constraints. When a Link (a, b) of Association X on Types A and B with

6-2 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

AssociationEnds ae and be, is added to an Association, the following activities take place:

For the first AssociationEnd, the current collection of LinkEnds defined by instance b at the second AssociationEnd is examined. If the addition of a would make the collection cardinality greater than the upper field of the multiplicity attribute value of the first AssociationEnd, the link is not added. The same constraint checking is performed on the second AssociationEnd. The pre-condition which must be satisfied for the Link to be added can be expressed as:

Pre-Condition on: X::add(a : A, b : B) pre: not b.ae->includes(a) and b.ae->size + 1 <= A.lookupElement(“ae”).multiplicity.upper and a.be->size + 1 <= B.lookupElement(“be”).multiplicity.upper

If neither constraint is violated, the Link is added to the Links of the Association. The following OCL expression defines a post-condition on a successful Link addition:

Post-Condition on: X::add(a : A, b : B) post: [email protected] = b.ae->including(a) and a.be = [email protected]>including(b)

For an AssociationEnd defined as isOrdered equals true, the above post-condition still holds. However, in that case, since the AssociationEnd (ae or be) returns a sequence instead of a set (within OCL) the semantics of the include operation changes, placing the included element at the end of the sequence.

When a Link (a, b) of Association X on Types A and B with AssociationEnds ae and be, is removed to an Association, the following activities take place:

For the first AssociationEnd, the current collection of LinkEnds defined by instance b at the second AssociationEnd is examined. If instance a is not in that collection, the Link to be removed does not exist. No change is made to the Links of the Association. If the removal of a would make the collection cardinality less than the lower field of the multiplicity attribute value of the first AssociationEnd, the link is not removed. The same constraint checking is performed on the second AssociationEnd.

Pre-Condition on: remove(a : A, b : B) pre: b.ae->includes(a) and b.ae->size - 1 >= A.lookupElement(“ae”).multiplicity.lower and a.be->size - 1 >= B.lookupElement(“be”).multiplicity.lower

If neither constraint is violated, the Link is removed from the Links of the Association. The following OCL expression defines a post-condition on a successful Link removal:

Post-Condition on remove(a : A, b : B) post: b.ae = [email protected]>exclude(a) and a.be = [email protected]>exclude(b)

When the multiplicity constraint at either AssociationEnd (or both) has isOrdered equal to true, then the addition of Links should include the capability to place instances within

9/1/97 Meta Object Facility 1.1 6-3 Section 6. MOF Semantics Details

the constraint collections at a specified location, to control the ordering. The MOF IDL mapping uses an addBefore operation to place the instance of the LinkEnd corresponding to the ordered AssociationEnd before some other instance in the constrained collection. Given a Link (a, b) of Association X on Types A and B with AssociationEnds ae and be, with be ordered, to be added to an Association with b before bx, the following activities take place:

Subject to the constraints on adding a Link above, the collection of instances defined by the LinkEnd instances of the be AssociationEnd with the opposite LinkEnd instance equal to a is checked for the existence of bx. If bx is not in that collection, the Link is not added. Otherwise, the Link is added in a manner which places b directly before bx in the collection.

To make use of OCL’s integer indexing for Sequences, the following operation is required.

Required operation: Sequence(T)::index(ele : B) : Integer index(ele) = Set{1..self.size}->select(i | self->at(i) = ele)->first

Pre-Condition on: X::addBefore(a : A, b : B, bx : B) pre: B.lookupElement(“be”).multiplicity.isOrdered and a.be->includes(bx)

Post-Condition on: X::addBefore(a : A, b : B, bx : B) post: a.be = [email protected]>subSequence(1, index(bx)-1)-> including(b)-> append(subSequence([email protected]>index(bx), [email protected]>size) and b.ae = [email protected]>including(a)

The Association itself has, as its instances, the Links defined by the association. For an Association X on Types A and B with AssociationEnds ae and be, the Links of X can be determined as the collection of all the Links in which an instance of Type A is participating through a LinkEnd defined by ae (or similarly through the instances of Type B). In OCL, this is given by

X::allLinks() : Set(Sequence{A, B}) allLinks = A.allInstances->collect(a | a.be->collect(b | Sequence{a, b}))

Notice that the Links of an Association will not be ordered. In the case where, given the example above, with AssociationEnd be ordered, if no instance of A has more than one instance of B connected through a Link of Association X, there will be no defined order of the collection of Links in the Association. If, among all instances of A, only one instance participates in a Link of Association X, the Links of the Association will be completely ordered. For any other situation, there will be a partial ordering of the Links.

It may be possible to modify Links, if such a capability is provided. In this case no links are added nor removed. Instead, one instance is substituted for another. When a b2 is

6-4 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

substituted for b, a current participant in the Link (a, b) of Association X on Types A and B with AssociationEnds ae and be, the following activities take place:

For the ae AssociationEnd, the current collection of LinkEnds defined by instance b at the be AssociationEnd is examined. If the removal of a would make the collection cardinality less than the lower field of the multiplicity attribute value of the first AssociationEnd, the Link is not changed. The collection defined by the instances of ae LinkEnds connected to b1 by a Link of X is considered. If addition of a will make the collection cardinality exceed the ae multiplicity upper field, then the Link is not changed.

Pre-Condition on: X::change(a : A, b : B, b1 : B) pre: b.ae->includes(a) and b.ae->size - 1 >= A.lookupElement(“ae”).multiplicity.lower and b1.ae->size + 1 <= B.lookupElement(“ae”).multiplicity.upper

Performing the change substitutes b1 for b in the collection defined by the set of instances connected by be LinkEnds to a; removes a from the set of instances connected by ae LinkEnds to instance b, and adds a to the set of instances connected by ae LinkEnds to instance b1.

Post-Condition on: X::change(a : A, b : B, b1 : B) post: a.be = ([email protected]>exclude(b))->including(b1) and b.ae = [email protected]>exclude(a) and b1.ae = [email protected]>including(a)

6.2.1.3 Changeability Constraints In addition to the constraints on collections defined in the multiplicity attribute, the AssociationEnds have an isChangeable attribute. Equal in intent to isChangeable on Attributes, this attribute can constrain the ability to change Links, except through specific operations defined by the model. Normally operations are provided through language transformations (such as IDL generation) supporting the addition, removal, and changing of Links. When isChangeable is set to false, however, the users are restricted from making changes, except through operations explicitly defined by the modeler.

In the case of the isChangeable attribute on AssociationEnd, marking one AssociationEnd with isChangeable set to false restricts the changeability of the other AssociationEnd as well. Yet, there is a distinction between setting each end and setting both ends. Consider Association X on Types A and B, with corresponding AssociationEnds ae and be. If AssociationEnd be is set with isChangeable equal to false, then a collection defined by AssociationEnd be corresponding to a particular instance a cannot be altered, after the instance a is initialized. If a language binding intends to make Link creation available, it will have to accept one or more b instances in a factory operation for Type A, so that Links can be created during the creation of instances of a. Note that the restriction on be results in an even greater restriction on AssociationEnd ae. Since standard Link manipulation operations cannot be provided which alters collections defined by be, any attempt to alter an ae collection could not be allowed, due to its affect on a be collection. If both AssociationEnds of an Association

9/1/97 Meta Object Facility 1.1 6-5 Section 6. MOF Semantics Details

are set with isChangeable to false, then no Link can be created, even at initialization of either Type A or Type B instances. However, these constraints, like the isChangeable constraint on StructuralFeature, do not make the Links immutable. The modeler can still provide operations which create, change, or remove Links.

6.2.2 References A type participating in an association may view its participation as one of its structural features. An instance of the type considers the instances at the other end of any of the Association’s Links to be its references. An instance may treat reference instances and attribute instances uniformly.

The AssociationEnd representing the other type’s participation in the Association does not adequately define the reference. Three items required the separate definition of Reference:

1. Just as other features have specific visibility defined, so do references. A public reference is available to elements outside the type; while private references are only available within the type.

2. As an element contained by the Association, the AssociationEnd is within the namespace of the Association. The separate Reference construct provides for containment in the type’s namespace. As an element in the Namespace, the Reference comes under the naming constraints and the syntax an semantics of subtyping.

3. Representation through Reference supports treating the reference as a StructuralFeature. This abstraction allows references and attributes to be treated uniformly, when appropriate. Because an object’s state is often considered the collection of its attribute values and Links, this uniform treatment is often applied.

4. For ternary and higher order associations, the Reference is needed to define the set of instances that make up each reference (see discussion of MOF extensibility to n-ary associations in Section 6.5.1 Namespace Extension through Generalization and Importing.).

Conversely, it is not possible to use Reference and forgo AssociationEnds. Often, A type participates in an association “unknowingly”, without a reference to the other type. This is the case when a type’s participation is irrelevant to the type instances. There are also times when a type cannot be modified, but must be made a participant in an association.

6.2.2.1 Equivalence of Reference and Association Operations When a Reference is defined in a Type, there becomes two ways of accomplishing some tasks. For these tasks, the result of using operations defined by the Reference as compared to operations defined in the Association are identical. Consider the example of State ExitsThrough Transition. If State has a Reference, exitTransitions, then, at model elaboration time, the Type definition for State will include operations like:

exitTransitions addExitTransitions(in Transition trans) removeExitTransitions(in Transition trans)

6-6 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

and, assuming that the exit AssociationEnd is ordered:

addExitTransitionsBefore(in Transition trans, in Transition before)

The association, Exits Through, would have operations defined like:

withSource(in State source) add(in State source, in Transition trans) remove(in State source, in Transition trans) addBeforeExits(in State source, in Transition trans, in Transition existing)

For a given State, the two sets of operations can be used with identical results. The comparison of the two query operations is:

State self.exitTransitions = ExitsThrough.withSource(self)

For any given State s and Transition t, these two operations yield identical results:

s.addExitTransitions(t) is equivelant to ExitsThrough.add(s, t)

As are these two:

s.removeExitTransitions(t) is equivelant to ExitsThrough.remove(s, t)

For any State s, and Transition t and t1, these two operations yield identical results:

s.addExitTransitionsBefore(t, t2) is equivelant to ExitsThrough.addBeforeExits(s, t, t2)

6.2.3 Aggregations

An Association can be defined as an Aggregation by setting the aggregation attribute of one of the Association’s AssociationEnds to either shared or composite. The AssociationEnd so set denotes the aggregate end of the association – the instance connected by LinkEnds corresponding to this AssociationEnd becomes the aggregate or composite; the instances connected at the other ends of the Links become the parts or components.

9/1/97 Meta Object Facility 1.1 6-7 Section 6. MOF Semantics Details

Aggregations and compositions are common in modeling. Although definitions vary, aggregations and compositions are usually distinguished by their copy and delete semantics, as well as general operation propagation characteristics. Within the MOF, the two concepts have some specific behavior, as compared to Associations in general (an Association with both AssociationEnds marked with aggregation equals none). General propagation of operations is too broad, since typically only specific operations are propagated through a composition or aggregation, and even then sometimes only under certain conditions. Aggregations and Compositions are distinguished from more general Associations in their response to copy and remove operations.

Composition is the stronger form of the two concepts, denoting strict containment. A component (contained) element is never owned by more than one composite element. In terms of removing model elements, when a composite is removed, all of its component (contained) elements are removed. When a composite is copied, all of its composite (contained) elements are always copied. Shared Aggregation is a weaker form of Aggregation. It denotes a form of ownership which may be shared. That is, a part (contained element), can have more than one aggregate (owner) simultaneously. Because of the potential for shared ownership, the part is not removed with the whole unless there are no more owners.

Identifying a single copy behavior appropriate for all situations is difficult. However, most situations are covered by two kinds of copying – deep and shallow. The behavior of the two kinds of copy depends on the type of associations that the copied element participates in – no aggregation, shared aggregation, or composite.

For an Association X of Types A and B, with corresponding ends ae and be, and a Reference defined in A of bref, deletion and copying are dependent upon the value of the bref aggregation attribute. This attribute’s value is derived from the value of the ae AssociationEnd (be.aggregation = ae.aggregation).

Case 1; bref.aggreagation equals composite

On delete of an instance of A, all components are deleted (after the operation, the deleted instance of A is no longer an instance of A, for each component instance of B identified through the Reference bref at the start of the operation, the instance is no longer an instance of B, and there no longer exists a link between the instance of A and any of the instances of B previously linked by X).

Post-Condition on: A::remove() post: not A.allInstances->includes(self@pre) and (B.allInstances->intersection(bref@pre))->isEmpty and (X.with_ae(self@pre)->intersection(bref@))->isEmpty

On a deep or shallow copy of A, all the components are copied (after the operation, the target repository contains a copy of the A instance, copies of all of the B instances referenced by bref, and Links of X between the new A instance and each of the new B instances).

Post-Condition on: A::copy(r : Repository) : A post: r::A.allInstances->includes(self) and

6-8 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

r::B.allInstances->interseection(.bref) = bref and r::X.with_ae(self)->intersection(bref) = bref

Case 2; bref.aggregation equals shared

On delete of an instance of A, parts are deleted if they have no other aggregate owner (after the operation, the deleted instance of A is no longer an instance of A; for each component instance of B identified through the Reference bref at the start of the operation, if the instance had no other A instance aggregate, the instance is no longer an instance of B, otherwise it still exists; and there no longer exists a link between the instance of A and any of the instances of B previously linked by X).

Post-Condition on: A::remove() post: not A.allInstances->includes(self@pre) and bref@pre->forAll(b | if b.ae->size = 1 then not B.allInstances->includes(b) else B.allInstances->includes(b)) and (B.allInstances->intersection(bref@pre))->isEmpty and (X.with_ae(self@pre)->intersection(bref@pre))->isEmpty endif

On a deep copy of A, the behavior is identical to that of a composite aggregate. On a shallow copy, all the components are copied (after the operation, the target repository contains a copy of the A instance, and Links of X between the new A instance and each of the existing B instances).

Post-Condition on: A::copyShallow(r : Repository): A post: r::A.allInstances->includes(self) and r::X.with_ae(self)->intersection(bref) = bref

Case 3; bref.aggregation equals shared

On delete of an instance of A behaves exactly like deletion when the aggregation is shared – deletion of the element and the link to the referenced element.

For both deep and shallow copying of an element which references another element when the Reference is defined as non-aggregate, the behavior is exactly like the shallow copy described above for shared aggregation – the element and link are copied.

Table 6-1 shows the effects of deletion and deep and shallow copying on composition, shared aggregation, and association.

Table 6-1. Copy and Deletion Semantics on Forms of Aggregation

9/1/97 Meta Object Facility 1.1 6-9 Section 6. MOF Semantics Details

Composition Shared No Aggregation Aggregation

Class Representation C C C

P P P

Instance Representation c : C c : C c : C

p1 : P p1 : P p1 : P

Delete remove c remove c remove c remove (c, p) remove (c, p) remove (c, p) remove p c.removeElement p : P p : P

Copy Deep copy c copy c copy c copy (c, p) copy (c, p) copy (c, p) copy p copy p c.copyDeep(t) original: in t: original: in t: original: in t: c : C c : C c : C c : C c : C c : C

p1 : P p1 : P p1 : P p1 : P p1 : P

Copy Shallow copy c copy c copy c copy (c, p) copy (c, p) copy p c.copyShallow(t) original: in t: original: in t: original: in t: c : C c : C c : C c : C c : C c : C

p1 : P p1 : P p1 : P p1 : P

6-10 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

6.3 MOF Data Type Encoding and Translation Conventions The MOF Model is defined to use CORBA TypeCode values as its basic representation for the data types in a model. However, the MOF requires TypeCode values to be used in ways that were possibly not intended by the authors of the CORBA 2.0 specification. In particular, an IDL generator that implements the IDL mapping rules needs to do a reverse translation from TypeCodes into compilable CORBA IDL source text.

The problem with this is that CORBA TypeCode values do not contain all of the information needed to do this. This is illustrated by considering the following CORBA IDL example:

module Root {

module Inner {

struct Small_Record { long a; short b; };

}; // end of Inner

struct big_record { Inner::Small_Record x; long y; };

}; // end of Outer

The data types “small_record” and “big_record” would be encoded as the following CORBA TypeCodes (rendered here in an arbitrary “pretty-printed” format)

( tk_struct “small_record” “a” tk_long “b” tk_short )

( tk_struct “big_record” “x” ( tk_struct “small_record” “a” tk_long “b” tk_short ) “y” tk_long )

The key thing to note is that although TypeCode for a complex data type contains a description of all of its component types, it does not contain their respective fully qualified names. Thus when the MOF tries to reverse translate the TypeCode into CORBA IDL, there is insufficient information in the TypeCode to do the job correctly.

The remainder of this section describes how the MOF solves this problem.

9/1/97 Meta Object Facility 1.1 6-11 Section 6. MOF Semantics Details

6.3.1 MOF Data Type Encoding. The MOF method of representing full CORBA data type information uses two MOF model elements DataType and TypeAlias, and some conventions about the use of MOF names and CORBA RepositoryIds.

Each distinct data type used in a model has a corresponding DataType object. This object has a "typecode" attribute that holds a CORBA TypeCode value that describes the structural aspects of the type. In addition, the data type was composed from other data types, the DataType object's namespace will contain one or more TypeAlias objects that relate the DataType to the other DataTypes that it was composed from.

A primitive data type is not composed from other data types, so the encoding is straightforward. For example the data type used in the following MOF attribute

attribute unsigned long foo;

is encoded as the following DataType / typecode combination (again expressed in an arbitrary "pretty-print" format, preceded by an impression of an object reference):

++obj-ref:DataType:12345678++ DataType < name = "*not_important", typecode = ( tk_ulong ), contents = empty >

The above "anonymous" DataType for the "unsigned long" may reside in any Namespace (or none). There may be only one DataType instance per repository for each CORBA primitive type, or multiple copies.

Next, the enumeration type E below:

enum E {e1, e2};

is encoded as

++obj-ref:DataType:11112222++ DataType < name = "E", typecode = ( tk_enum "E" "e1" e2" ), contents = empty >

6-12 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

This time, the DataType object has a real name ("E1"), and it is significant which Namespace contains the object, since this determines the fully qualified name for the DataType, and the place in which the data type's declaration appears in the mapped IDL.

Next, the structure type S that makes use of the previously defined enumeration type E:

struct S { long f1; E f2; };

is encoded as

++obj-ref:DataType:33334444++ DataType < name = "S", typecode = ( tk_struct "S" "f1" tk_long "f2" (tk_enum "local:*1" "E" "e1" "e2" ) ), contents = { ++obj_ref:TypeAlias:55556666++ } >

++obj_ref:TypeAlias:55556666++ TypeAlias < name = "*1", type = ++obj-ref:DataType:11112222++ >

There are a number of important things to notice about the above:

• The embedded TypeCode for the "E1" enumeration type within the TypeCode for "S" now has a "local" RepositoryId with the key of "*1". (Refer to Section 6-6-3 of the CORBA 2.0 specification) • The namespace of the DataType object named "S" now contains an TypeAlias object. • The name of the TypeAlias object is "*1", matching the key embedded in the TypeCode for "S". • The type reference for the TypeAlias object (inherited from TypedElement of course) is a link to the DataType object corresponding to the definition of the enumeration type.

The general pattern for representing a compound data type composed from separately declared component data types is therefore:

• The namespace of the DataType for the compound data type will contain a TypeAlias object for each of the component DataTypes. • The names of the TypeAlias objects are required only to be unique within their containing namespace, and to start with the "*" character. (The latter is to avoid name collision problems in future extensions to the MOF)

9/1/97 Meta Object Facility 1.1 6-13 Section 6. MOF Semantics Details

• The embedded TypeCode for each component type must have a "local" RepositoryId which has a 1-to-1 mapping to the name of an TypeAlias object. This in turn must be linked (via the IsOfType association) to the DataType object that defines the component data type.

A similar pattern is used when a compound data type has a component which is a Type. The Type is encoded as a tk_objref TypeCode, whose id field contains a "local" identifier. That identifier matches the name of a TypeAlias whose type reference links to the defining Type object.

Note that the use of repository identifiers and TypeAliases described above is only necessary for separately declared component types and typedefs. When a component data type is a primitive type, string, array or sequence type, it must be embedded without a repository id.

6.3.2 IDL Generation from DataType Objects Given the above encoding convention for data types, the process of regenerating the CORBA IDL for types from a DataType is fairly straight forward, though it does require detailed understanding of the relevant CORBA IDL syntax. The following is a simplified explanation that glosses over certain syntactic issues.

To generate the IDL name for the data type in a DataType, do the following:

• obtain the DataType's fully qualified name (using the operation provided), • convert this into a partially qualified name relative to the current context, and • apply the Format1 name transformation defined in the IDL mapping section.

There are two exceptions to this. If the DataType denotes a primitive data type or a string type (this can be determined from the kind of the typecode attribute), the IDL syntax for the data type should normally be output. If the DataType is an anonymous sequence or array, the data type is malformed, and no valid IDL can be generated.

To generate a full IDL type declaration for a DataType, walk the DataType's typecode value:

• when the typecode part under examination is a primitive type or string, emit the corresponding IDL syntax. • when the typecode part is for a struct, union, enum, object reference or aliased type defined elsewhere: − extract the TypeAlias name from the typecode part's repository id − lookup the TypeAlias in the DataType's namespace − follow the TypeAlias's type link to the defining Type or DataType − emit the appropriately mapped form of the defining Type or DataType's fully qualified name.

6-14 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

• when the typecode part is a for a data type that is not defined elsewhere, emit the actual type declaration, recursing to handle base types, member types, switch types and so on.

In all cases, care is needed to detect cases for which it is not possible to generate valid CORBA IDL. For example, it is not legal in CORBA IDL to use an anonymous sequence type as the type of a parameter.

Note: TypeCodes have a name field that may contain the simple name of the data type. This name should not be used for IDL generation purposes, since there is no guarantee that it will be updated if the corresponding DataType is renamed. Instead, an IDL generator should always obtain and use the DataType's name attribute.

6.3.3 DataType Consistency Constraints. The consistency constraints for DataTypes and their component TypeCode values and TypeAlias objects are fairly complex.

• CORBA TypeCodes with kind of tk_null, tk_void and tk_exception have no meaning in DataTypes and are not permitted. • There must be a 1-to-1 correspondence between the "local" RepositoryIds in embedded TypeCodes within a DataType's typecode and the names of the TypeAliases in its namespace. The correspondence is that the name should be textually identical with the implementation specific part of the id. • The full typecode for a DataType should not have a "local" id. • If a TypeAlias's type is a Type, then the TypeAlias should correspond to an embedded tk_objref typecode. • If a TypeAlias's type is a DataType, then the TypeAlias should correspond to an embedded typecode with kind of tk_struct, tk_union, tk_enum or tk_alias. • The typecode of a DataType should always conform to the syntax of a CORBA type expressible in CORBA IDL that is appropriate to the context in which it is used. For example, a MOF Type should not contain a DataType whose typecode represents an anonymous type. • The value of an embedded typecode which has an associated TypeAlias must be isomorphic with the typecode for the DataType which the TypeAlias's type points to. In this context, isomorphic excludes the values of the TypeCodes name fields.

The last constraint has interesting consequences for an interactive model editor tool. Suppose that the user defines a data type A, and uses it as a component of other data types. If the user then wants to change the data type definition for A (i.e. altering its typecode), the model editor has to find all embedded examples of A's typecode and update them.

6.3.4 External Types It is feasible for the TypeCode value in a DataType to contain a TypeCode for a CORBA object reference or data type that is defined in a CORBA Interface Repository. For this

9/1/97 Meta Object Facility 1.1 6-15 Section 6. MOF Semantics Details

to work, the "external" TypeCode should have a RepositoryId encoded using a format recognized by the CORBA IR (see CORBA 2.0 section 6-6).

When the IDL mapping process encounters an "external" TypeCode, the process of generating compilable IDL will be highly vendor and site specific. For example, in a typical CORBA environment will do the following:

• Find the appropriate CORBA Interface Repository, using vendor or site specific mechanisms. • Obtain the fully qualified name of the CORBA data type or interface, from the IR. • Obtain (from somewhere) the filename for the file containing the CORBA IDL modules containing the definitions. • Emit a "#include" to include the external module declarations. • Emit an appropriately qualified name at the appropriate point. Note that this name should NOT be subjected to reformatting.

MOF support for use of external TypeCodes is optional, since it cannot be fully implemented using the standardized parts of CORBA.

6.3.5 Rationale The reader may be curious as to why the MOF represents data types in this way. Our motivation for using CORBA TypeCodes were manifold:

• A MOF implementation and “generic” MOF applications can use standard ORB functionality to handle data types and dynamic type checking. • A model expressed using the MOF Model can (in theory at least) make use of data types defined in a CORBA Interface Repository. • The MOF Model is a lot smaller since it doesn’t need to include the 25 or so model elements needed to describe CORBA data types. • The number of object invocations needed to access MOF data type definitions is far fewer than would be needed if full model elements were used. • The MOF submission is substantially smaller, since we don't need to document the model elements or their mappings to CORBA IDL.

Having decided to use TypeCodes, it becomes necessary to solve the problem of reverse compilation. A number of mechanisms were considered, but this one described above was selected because:

• It does not abuse the CORBA TypeCode abstraction in a ways that makes MOF typecodes incompatible with other ones. • TypeAliases allow DataType objects to be moved from one location in model containment hierarchy to another without changing typecode values. • TypeAliases make typecode dependencies between DataTypes visible without having to analyze the typecodes themselves.

6-16 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

The only disadvantages of the MOF approach are:

• The cost of the extra TypeAlias objects and associated constraint checking. • The complexity for an interactive model editor of changing the typecode of a DataType that has been used as a component of another DataType. • The restriction that MOF DataTypes cannot represent the data type of a MOF collection.

(In fact, the 2nd and 3rd drawbacks are both a consequence of using TypeCodes, not of TypeAliases.)

6.4 Rules of ModelElement Containment A metamodel is built by composing objects of ModelElement subtypes into a composition hierarchy. A metamodel is defined by a Package object, all the ModelElement objects contained by that Package, and all the ModelElements contained by those ModelElements, transitively – thus the hierarchy. Only those ModelElements which are Namespaces or subtypes of Namespace can contain ModelElements. The Namespace type defines the containment of a list of ModelElements.

Not all subtypes of Namespace are permitted to contain objects of any subtype of ModelElement. The MOF has taken a covariant view toward defining the containment restrictions. As Namespace is specialized, so is the domain of ModelElement subtypes which can be contained. To be more exact, the Namespace containment is invariant, as defined by the interface; constraints which restrict the allowable contained ModelElement subtypes act as a covariant. This approach provides the MOF with the simplest interfaces and supports flexibility in any subsequent evolution.

Table 6-2 lists each non-abstract subtype of Namespace. For each of those types, the table specifies which ModelElements can and cannot be contained.

9/1/97 Meta Object Facility 1.1 6-17 6.5 Rules of Importing and Visibility

6.5.1 Namespace Extension through Generalization and Importing Through generalization, a GeneralizableElement can extend its namespace with the contents of the supertypes – both direct and indirect supertypes. Although these elements do not become part of the contents of the GeneralizableElement, they are treated similarly for the purpose defining the GeneralizableElements capabilities and other characteristics.

A Package, as a subtype of GeneralizableElement, can extend its namespace through generalization (the association end names supertype and subtype can be considered generalization and specialization, respectively, if discussing supertypes of Packages seems awkward; Package supertypes can only be Packages). Beyond extension through generalization, Packages can extend their namespaces through importation. By importing a Namespace, a Package and its contents can make use of that Namespace and its contents. Generalizing and importing are two useful ways to reuse Packages and Classifiers in multiple models.

As described in Section 3.7.2 Namespace, there are four collections which can be defined for a Namespace. Specification of these four kinds of collections supports the definition of visibility and the semantics of the Namespace subtypes.

The contents of a Namespace, as represented through the contents reference, identifies the direct components of the Namespace composition. The contents are owned by the Namespace, in that they will be removed from the model if the containing Namespace is removed (Section 6.2.3 Aggregations, describes the implications of the composition form of containment). Many of the properties of composition are transitive, so it is useful to identify the transitive closure on Namespace contents.

Namespace::allContents : Set(ModelElement) -- the transitive closure on contents allContents = self.contents->union(self.contents-> Section 6. MOF Semantics Details

select(c | c.isKindOf(Namespace))->collect(c | c.allContents))

The extended namespace of a Namespace instance is the collection of contents (as represented by the contents reference) plus additional ModelElements included through the namespace extension mechanisms of generalization and importation. Since the Namespace type does not define an extension mechanism, its contents forms its namespace.

Namespace::extendedNamespace : Set(ModelElement) extendedNamespace = self.contents

A GeneralizableElement extends its namespace by including the contents of all its supertypes (direct and indirect).

GeneralizableElement::extendedNamespace : Set(ModelElement) extendedNamespace = self.Namespace::extendedNamespace-> union(self.allSupertypes->collect(s | s.extendedNamespace))

A Package further extends its namespace by including any Namespace instances imported through Import instances. This extended Namespace does not include the contents of those imported Namespaces.

Package::extendedNamespace : Set(ModelElement) extendedNamespace = self.GeneralizableElement::extendedNamespace-> union(self.GeneralizableElement::extendedNamespace-> select(e | e.oclKindOf(Import)->collect(i : Import | i.imported)))

The last collection type, extended contents, includes the extended namespace and the transitive closure on the contents of every Namespace in the extended namespace. Although labeled extended contents, the Namespace does not contain all the elements of the collection in the composition form of containment (it does not necessarily own them).

Since the Namespace type has no namespace extension capability, the extended contents are the same as the transitive closure on the actual contents.

Namespace::extendedContents : Set(ModelElement) extendedContents = self.allContents

For extended contents, GeneralizableElement includes (beyond Namespace) the transitive closure on all its supertype contents which are Namespace types.

GeneralizableElement::extendedContents : Set(ModelElement) extendedContents = self.GeneralizableElement::extendedNamespace-> union(self.GeneralizableElement::extendedNamespace-> select(s | s.isKindOf(Namespace))-> collect(ns : Namespace | ns.extendedContents))

9/1/97 Meta Object Facility 1.1 6-19 Section 6. MOF Semantics Details

Package has the ability to include still more elements in its extended contents, since the extended contents of imported elements are included.

Package::extendedContents : Set(ModelElement) extendedContents = self.GeneralizableElement::extendedContents-> union(self.GeneralizableElement::extendedContents-> select(e | e.isKindOf(Import)-> collect(i : Import | i.importedNamespace.importedContents (Set{ self })))

This derivation of extended contents requires a check to avoid infinite recursion, since there is not restriction in the MOF Model on circular importation.

Package::importedContents(visited : Set(Package)) : Set(ModelElement) -- requires a visited set avoid infinite recursion importedContents(visited) = if not visited->includes(self) then self.GeneralizableElement::extendedContents-> union(select(ex | ex.oclIsKindOf(Import))-> union(select(ex | ex.isKindOf(Import))-> collect(i | i.importedNamespace.importedContents (visited->including(self)))) else Set{ }

6.5.2 Visibility Visibility is the characteristic of a model element’s availability for another model element This availability defines specific constraints in creating links of the Associations defined in the MOF Model. That is, many of the associations constrain participation to objects in which the object of one LinkEnd must be visible from the object at the other LinkEnd. Some ModelElement subtypes have a visibility attribute which can be used to explicitly the restrict visibility of the ModelElement, described in Section 6.5.3 Explicitly Restricting Visibility. This section defines visibility in absence of any explicit visibility restriction. However, by ignoring explicit visibility, a complete definition of visibility is not provided in this section, but supports the definition in the next section. In this document, if an element is visible to second element, it is sometimes stated that the second element can see the first.

A Namespace does not restrict visibility of its contents from elements directly surrounding the Namespace (elements which directly surround a Namespace are those elements whose container is equal to the Namespace’s container). Without explicit visibility constraints, visibility is transitive – if a Namespace is visible, its contents are also visible. So all the ModelElements returned by the allContents operation invoked on a ModelElement’s container are visible from that ModelElement. A ModelElement which is not contained (a top-level Package) can see all the other uncontained ModelElements in the universe (conceptually, at least). Considering the capabilities for GeneralizableElements and Packages to extended their contents, a ModelElement can see the extendedContents of its container.

The visibility just described is looking inward, into Namespaces. When considering looking out – whether a ModelElement outside a Namespace is visible from a

6-20 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

ModelElement inside a Namespace, the Namespace subtypes of Packages and Classifiers define different visibility capabilities. A ModelElement outside a Classifier is visible from a ModelElement inside a Classifier. However, a ModelElement outside a Package is not visible from a ModelElement inside a Package. This distinction provides a means of containing the visibility of ModelElements as they look outward. Otherwise, in the absence of explicit constraints, every model element in every model in the universe would (conceptually) be visibly from any ModelElement in any model. Operations and Exceptions, which also subtype from Namespace, have the same rules as Classifiers.

Within this section (discounting explicit visibility rules), visibility is transitive. So if a ModelElement x is visible from a ModelElement y, and ModelElement y is visible from ModelElement z, then ModelElement x is visible from ModelElement z. Based on the above rules, and ignoring explicit visibility rules, as described in Section 6.5.3 Explicitly Restricting Visibility, a ModelElement is visible from a second ModelElement if the first ModelElement exists in the extended contents of the innermost Package containing the second element.

The following OCL representation (presented here only for explanatory purposes) of an operation on a ModelElement determines whether another ModelElement is visible from this ModelElement, independent of explicit visibility constraints.

ModelElement::isVisibleNoExplicit(other : ModelElement) : boolean -- is other visible from self, not considering visiblity attributes isVisible(other) = if self.nearestPackage->isEmpty then true else self.nearestPackage->member.extendedContents->includes(other)

The specify the operation, an operation which returns the innermost Package containing a ModelElement is needed.

ModelElement::nearestPackage : Set(Package) -- the innermost Package containing self nearestPackage = if self.container->isEmpty or not self.container.isKindOf(Package) then Set{ } else if self.container.isKindOf(Package) then Set{ self.container } else self.container.nearestPackage

A top-level Package does not have an enclosing Package to define the namespace in which it resides. Instead, it can see potentially any other top-level Package in the universe. A Package can only import a Namespace which is visible to the Package.

9/1/97 Meta Object Facility 1.1 6-21 Section 6. MOF Semantics Details

6.5.3 Explicitly Restricting Visibility The definition of visibility above is incomplete, because it does not take into account the explicit visibility constraints which may be placed on Packages, Classifiers, and Features. These constraints, in the form of attributes, may further restrict visibility. The can never, however, increase the visibility of any ModelElement.

The three possible values of visibility are public, private, and protected. Specifying a visibility attribute value of public maintains the visibility definition in the previous section, since it defines no additional restrictions on visibility. Defining an element as private hides the element from all elements except those in this element’s container’s contents.

Besides Packages and Classifiers (which define visibility in their common supertype GeneralizableElement) and Features, the Import type also has a visibility attribute. Within the context if an importation, as defined with an Import instance, the visibility of the imported Namespace is the more restrictive of the two visibility specifications – the visibility attributed to the imported Namespace or the visibility of the Import instance.

Specifying an element as protected results in the same visibility restrictions as specifying the element as private, except when another element gains visibility through generalization. When an element is defined as protected, and its container Namespace is a GeneralizableElement with one or more subtypes (direct and indirect), then the element is visible to each subtype’s contents. All other visibility restrictions on the protected element are the same as private.

Under explicit visibility constraints, visibility is not transitive. For example, a private operation of a Type is visible from a public operation of that type; that public operation is visible from an element outside the type; however, the private operation is not visible to that element.

6.5.4 OCL Representation of Visibility Rules Given a ModelElement, any ModelElement in the extended namespace of the first ModelElement’s container is visible from the first ModelElement, unless the second ModelElement is contained in a supertype of the first ModelElement’s container and that second ModelElement is private.

To specify the visibility of elements inside the extended namespace of a Namespace, from the perspective of a ModelElement in that Namespace, that visible extended namespace is defined for Namespaces, then GeneralizableElements, then Packages.

Inside a Namespace, the contents are visible to a ModelElement in the Namespace, regardless of any explicit visibility constraints.

Namespace::extendedNamespaceVisible : Set(ModelElement) extendedNamespaceVisible = self.contents

Inside a GeneralizableElement, the contents of all its supertypes (direct and indirect), are visible for those contents which are not explicitly specified as private.

6-22 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

GeneralizableElement::extendedNamespaceVisible : Set(ModelElement) extendedNamespaceVisible = self.Namespace::extendedNamespaceVisible-> union(self.allSupertypes->collect(s | s.contents-> select(c | c.getVisibility <> private))

Inside a Package, any imported element is visible (the imported element must be visible to the importing Package).

Package::extendedNamespaceVisible : Set(ModelElement) extendedNamespaceVisible = self.GeneralizableElement::extendedNamespaceVisible-> union(self.GeneralizableElement::extendedNamespaceVisible-> select(e | e.oclKindOf(Import)-> collect(i : Import | i.imported)))

For a ModelElement, the contents of Namespace instances in the visible extended namespace of the ModelElement’s container are considered separately from other ModelElements in determining visibility. This separate consideration is due to the fact that those Namespace instances do not restrict access to their extended namespace through any visibility restriction attributed to the Namespace instance. Since

Namespace::extendedNamespaceVisibleContents : Set(ModelElement) extendedNamespaceVisibleContents = self.extendedNamespaceVisible-> select(c | c.isTypeOf(Namespace))-> collect(ns : Namespace | ns.extendedNamespaceVisible-> select(x | x.getVisibility = public))

A Model element can have visibility beyond the two cases defined above, but the visibility is further constrained by explicit visibility constraints. As described in the previous section, a ModelElement’s visibility is driven by the extended contents of its innermost containing Package. However, that visibility is further restricted by explicit visibility constraints. Any ModelElement which does not have a public visibility is not visible; any ModelElement enclosed in a Namespace (except when that Namespace is the innermost containing Package) which does not have public visibility is not visible; any ModelElement contained in an imported Namespace where the assigned visibility of that Namespace is not public is not visible.

Namespace::extendedContentsVisible : Set(ModelElement) extendedContentsVisible = self.eNsVis(Set{ self })

Because the importation can cause circular importations, a mechanism is required to avoid infinite recursion.

Namespace::eNsVis(visited : Set(Namespace)) : Set(ModelElement) -- requires a visited set avoid infinite recursion eNsVis(visited) = if not visited->includes(self) then self.extendedNamespaceVisible-> select(c | c.getVisibility = public)-> union(select(x | x.getVisibility = public and x.isKindOf(Namespace))-> collect(ns : Namespace | ns.eNsVis(visited->including(self))

9/1/97 Meta Object Facility 1.1 6-23 Section 6. MOF Semantics Details

Given these definitions, the set of ModelElements visible from a ModelElement is the set of ModelElements in the visible extended namespace of the ModelElement container plus the public extended contents of the elements in that visible extended namespace which are Namespaces, plus the visible extended contents of the innermost Package containing the ModelElement. In the case where the ModelElement is a top-level Package, the set of visible elements are the other top-level Packages, plus the public contents of each Package, plus the extended visible contents of each Package.

ModelElement::allVisible : Set(ModelElement) if self.nearestPackage->isEmpty then Package.allInstances->select(pkg | pkg.nearestPackage->isEmpty)-> collect(pkg | pkg.extendedNamespaceVisible-> select(e | e.getVisibility = public)-> including(pkg)->union(pkg.extendedContentsVisible)) else self.container.extendedNamespaceVisible-> union(self.container.extendedNamespaceVisibleContents)-> union(self.nearestPackage.extendedContentsVisible)

Thus, the operation used in several OCL constraints is:

ModelElement::isVisible(other : ModelElement) : boolean isVisible(other) = self.allVisible->includes(other)

Supporting operations required by the above operations are defined.

ModelElement::getVisibility : VisibilityType getVisibility = public

GeneralizableElement::getVisibility : VisibilityType getVisibility = self.visibility

Feature::getVisibility : VisibilityType getVisibility = self.visibility

Import::getVisibility : VisibilityType -- the more restrictive of self’s visibility or self’s imported -- Namespace visibility getVisibility = if self.visibility = private or self.imported.visibility = private then private else if self.visibility = protected or self.imported.visibility = protected then protected else public

6-24 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

6.6 MOF and MetaModel Extensibility Mechanisms

6.6.1 MOF as an Extensibility Mechanism The MOF provides the best means of tailoring and extending meta-models. By creating new metamodels composed of or importing existing metamodels, by subtyping Packages and Types, and by versioning metamodels, new metamodels can be defined with predictable interoperability. The inclusion of Tags in the MOF is an accommodation for occasional, special purpose, ad-hoc extensions. However, they should not be used as a substitute for modeling extensibility through extension, customization, and specialization of metamodels via the MOF.

6.6.2 Using Tags and Tag Values The MOF faces two opposing goals – provide a flexible, extensible modeling environment which can meet a wide variety of unanticipated needs; and provide a means of enforcing compliance to the MOF Model and metamodels and insure metamodel integrity, to support metamodel and model interoperability. To meet the latter goals, the MOF must insure the immutability of published metamodels and enforce compliance to the MOF Model. Yet this perceived inflexibility will be intolerable to a percentage of MOF users. To support flexibility without compromising interoperability, the MOF provides Tags and corresponding Tag values. Tags are used in two distinct ways in the MOF:

1. Tags can be included in a metamodel during development, to specify characteristics of ModelElements that cannot be appropriately modeled with the constructs provided in the MOF Model. These tags become part of the metamodel as published. 2. Tags can be attached to a metamodel after publishing, local to a ModelRepository, without compromising the immutability of the metamodel. These tags, although local to a repository, can be imported and exported for sharing.

Tags provide a flexible way of adding information to a metamodel. The flexibility, however, sacrifices of interoperability. Since the Tags can express any meaning, they have no defined meaning (semantics). With no defined meaning, modelers, tool builders, and others who add Tags will invent their own meaning for each Tag. To the degree they are able to share and reach agreement on that meaning, Tag interoperability will be achieved. But Tags, if used extensively, will surely collide – one organization will define a Tag for one purpose; another organization will define the very same Tag for another purpose. A metamodel developed with the first meaning of the Tag will be interpreted by a tool or facility based on the second meaning, with potentially catastrophic results. Tags should be used sparingly; particularly when any model interoperability is anticipated!

6.6.3 Tags in the Definition of Metamodels The MOF submission has attempted to provide a comprehensive set of modeling constructs, balanced with the desire for a small MOF Model and reasonable implementation expectations. Modelers may identify information they wish to convey in the MOF, which is not appropriately expressible with the MOF Model elements. Any

9/1/97 Meta Object Facility 1.1 6-25 Section 6. MOF Semantics Details

ModelElement can have one or more Tags attached to it. Because Tags are ModelElements, they need to be contained, just like the other ModelElements. Since the metamodel is under development, ModelElements of the metamodel can contain Tags. This containment and attachment is similar to the situations with Constraints, which are contained by a ModelElement and associated with possibly different ModelElements.

An example Tag use in metamodel definition would be stereotypes in the UML metamodel. UML defines a construct, stereotype, which modifies a Class. If the UML metamodel developers wanted to make use of stereotypes in defining the UML metamodel, they could define a Tags with the name “stereotype”. For each tag, they would supply a string, representing the particular stereotype, such as “type”. Each Tag would be attached to the ModelElement it describes as a stereotype. The modeler could choose to have the Tag contained by the same ModelElement or another ModelElement in the metamodel. Suppose an instance of Type, given the name “Generalisation” was included in the metamodel. Then, a Tag with the name “stereotype” and the string “Inherits” was attached to the Generalisation Type. The goal was to represent a distinct form of Generalisation (solutions within the MOF Model constructs, without using Tags, would be an Attribute added to Generalisation representing the kind of Generalisation, or subtyping Generalisation).

When the metamodel is completed and published, the tags become a permanent part of the immutable metamodel. Every ModelRepository for defining UML models, as well as every tool and environment which complies with and makes use of the UML metamodel will have the Type object named “Generalisation” with the attached Tag named “stereotype” having the value “Inherits”. Since the Tag is part of the metamodel, any tool or other software can take advantage of its existence. For instance, when it is more appropriate to represent an inheritance relationship than a generalization (perhaps for implementation inheritance), the tool can find the classifier-level object for Generalisation that has the Inherits stereotype Tag attached to its defining Type instance in the metamodel, and use that object to create an instance of Generalisation. Although the MOF, and any portions of the MOF which may be used in UML modeling, place no meaning on any Tags or Tag values, tools may. If Tags are introduced in a metamodel underdevelopment, tools are much more likely to take advantage of the Tags attached to metamodel elements, since the attached Tags will be integrated with every copy of the published metamodel.

6.6.4 Tags added to Published Metamodels The concept of immutable published metamodels are the touchstone for model interoperability. Yet this immutability is likely to frustrate developers, who need to add information to the metamodel, or perhaps change its semantics in some modest but useful ways. Of course, the developer could always use a MOF to define an alternate metamodel, but then interoperability with the original metamodel (in terms of model exchange and tool use) would be lost. Through careful subtyping of the original metamodel, substitutability may be maintained. However, Tags provides another way of modifying metamodels.

Once a metamodel is published, Tags cannot be integrated. Tags added at this point are repository-local. Because the metamodel is published its ModelElements cannot contain the Tags. When using the MOF to define metamodels, to add Tags to the MOF Model itself, the Tags are added to the MofRepository object. To add Tags to a published

6-26 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

metamodel, the Tags would be added to a ModelRepository subclass, if available, or some other object provided by the tools in that modeling environment capable of containing Tags. Although the Tags are not contained by the published metamodel ModelElements, they are attached to the ModelElements.

For example, suppose a tool vendor wanted to integrate graphic shapes to the different constructs of the UML metamodel, to support some graphic capability. Each different elements in the UML metamodel, such as Model, State, Use-Case, etc., would each have corresponding unique information supporting visualization capabilities. If the tool vendor felt it essential to attach that information directly to the ModelElements in the metamodel defining the constructs, they could define Tag values with the name “visualize” and the values corresponding to the graphic information, and attach them to the ModelElements. The corresponding tool could browse through UML models, retrieving the ModelElements corresponding to parts of the model, and retrieving the Tags associated with the ModelElements, and making use of the Tag value in providing some visualization of the model part.

Since the Tags are local to the repository, the visualization tool would not have this capability on UML models in other repositories. However, since Tags are interoperable, the Tags in the repository could be imported to other UML metamodel based repositories. Tags added to published metamodels achieve their level of interoperability measured by their popularity. Tags which support some tool or capability of universal value and enthusiastic support will be widely accepted, will have their Tag names avoided by other Tag creators, and will probably find their purpose eventually folded into a revision of the metamodel to which they were attached.

6.7 Inter-Repository Modeling Instances of MofRepository (ModelRepository at the model level, when metamodels define a ModelRepository subtype) define a boundary for a set of models. This could be one or more metamodels by an individual developer, or all the MOF-compliant metamodels for an enterprise. But whatever the scale, the MofRepository cannot be a complete boundary for metamodels, if model sharing and collaboration, modeling transformations and other mappings, and federated repositories in general is to be achieved. The specific issues surrounding metamodels which cross repository boundaries is discussed in this section. Although this submission avoids any specific implementation decisions, inter-repository modeling does create some situations in which certain implementation approaches are recommended to insure interoperability among vendor implementations, as described in Appendix E Implementation Requirements.

6.7.1 Element, Model, and Repository Naming Within a MofRepository, the containment hierarchy defined by the MOF Model and the Namespace constraints insures that every ModelElement’s qualified name is unique (if the ModelElement is in a valid model). However, when considering ModelElements from different MofRepositories, the uniqueness cannot be insured. If every MofRepository in the universe had a unique name, ModelElements could still have unique identity, based on both their qualified name and the name of their containing repository. Considering that uniqueness across repositories is only of interest when ModelElements are being imported or generalized from other repositories, and that only

9/1/97 Meta Object Facility 1.1 6-27 Section 6. MOF Semantics Details

some repositories will be interested in sharing on a large scale, unique repository names may not be difficult.

By basing repository naming on Internet domain naming, MOF users can produce unique repository names without some new registry or other mechanism. This submission does not mandate repository naming rules. If a repository is not intended to either make its metamodels available or make use of metamodels in other repositories, the repository name is not important. If a group or organization only performs inter-repository modeling within the group, they can safely use their own naming scheme, so long as repository names are unique.

For organizations which intend to make portions of their metamodels available beyond their organization, or intend to make use of portions of metamodels outside their organization, the following MofRepository naming conventions are strongly encouraged.

An instance of MofRepository should be named in the format defined by:

ModelRepsoitoryName :== hostName ‘/’ metamodelName ‘/’ localName

where:

hostName is a name conforming to Internet conventions, defined in RFC0819: Domain naming convention for Internet user, or subsequent standards for Internet naming; the specified name must be owned by the owner of the model or assigned to the computer on which the repository resides (not the total contents of the repository, just the ModelRepository itself); although the DNS-registered hostname of the computer where the MofRepository object will often be useful, it need not be the name. As en example of why a computer hostname cannot always be used, if other metamodels are importing or otherwise using portions a metamodel in a MofRepository, the MofRepository name could not change when the MofRepository object is migrated to a different host.

is a DNS-registered name of the computer on which the ModelRepository resides.

metaModelName is the name of the metamodel upon which the ModelRepository is based. For a MofRepository, this name will always be “org.omg.Mof”.

localName is any name which will distinguish this ModelRepository from other ModelRepositories based on the same metamodel and given the same hostName. If there is only one ModelRepository based on a particular metamodel associated with a given hostName, the localName may be omitted.

So for instance, a MofRepository might be named:

mv.unisys.com/org.omg.Mof/production

A ModelRepository based on the UML metamodel (if a ModelRepository subtype is defined for UML) at the same location might be:

mv.unisys.com/org.omg.Uml/beta

6-28 Meta Object Facility 1.1 9/1/97 Section 6. MOF Semantics Details

A metamodel name is the name of its top-level Package – the Package contained by a MofRepository. During model development, the Package name is not very important, other than the meaning it conveys. However, if the resulting metamodel is published and made available outside an organization, the metamodel name needs to be globally unique. Interoperability would be compromised by accidentally using models based on disparate metamodels, and believing they were based on the same metamodel. Again, the recommended use of Internet naming conventions can assure globally unique names. Following Java’s lead, the metamodel name will use the Internet naming conventions, with the domain first, based on the owner of the metamodel. The owner of a published metamodel would be the organization which controls revisions to the metamodel. As shown before, the MOF Model is:

org.omg.Mof.

Some other metamodel might be:

au.edu.dstc.tools.MetaTranslator.

The dot notation does not indicate that the metamodel is enclosed in a Package (in the example, the top-level Package, which was published as a metamodel, was MetaTranslator, not au which contains package edu, which contains Package dstc, which contains Package MetaTranslator). Again, this metamodel naming convention is not mandated, but is strongly recommended to support interoperability.

The use of the naming conventions above insures that any ModelElement directly or indirectly contained in a MofRepository can be uniquely identified.

This approach does not preclude making ModelRepositories or models of those repositories publicly-accessible through the current Naming Service, through a URL Form when an Interoperable Naming Service is available, or through other appropriate means.

6.7.2 Defining Models across Repositories In defining a model, a Package or other Namespace can only contain elements within the same repository. That means that, given a Namespace instance, it can only contain some other element if the element’s class proxy and the Namespace’s class proxy are in the same repository. When a metamodel is constructed of multiple top-level packages, however, those two class proxies may not be directly navigable. It may not be possible to navigate from one class proxy to another class proxy through other class and package proxies.

An element in one repository can, however, reference an element in another repository. For example, a MofAttribute instance in one repository could have as its type reference an instance of a Class in a second repository.

9/1/97 Meta Object Facility 1.1 6-29 Section 6. MOF Semantics Details

6-30 Meta Object Facility 1.1 9/1/97 7. The MOF Model to IDL Mapping

This section defines the standard mapping from a model defined using the MOF Model onto CORBA IDL. The resulting interfaces are designed to allow a user to create, update and access instances of the model using CORBA client programs. While the standard IDL mapping implies detailed functional semantics for an object server for a mapped model, it does not define the implementation.

Note: while the mapping specification is defined to be easy to automate, a conformant MOF implementation is not required to support automatic IDL generation.

This section defines the standard mapping from a model defined using the MOF Model onto CORBA IDL. The resulting interfaces are designed to allow a user to create, update and access instances of the model using CORBA client programs. While the standard IDL mapping implies detailed functional semantics for an object server for a mapped model, it does not define the implementation.

Note: while the mapping specification is defined to be easy to automate, a conformant MOF implementation is not required to support automatic IDL generation.

7.1 Notation The following table gives a guide to interpreting the IDL generation templates.

Appearance (by example) Meaning

typedef The literal characters in the bold font should be generated The characters should be substituted for the described identifier using Identifier Format 1. The <> do not appear in the generated IDL. The characters should be substituted for the described identifier using the Identifier Format 2. The <> do not appear in the generated IDL. The characters should be substituted for the described identifier without formatting, i.e. as is. Typically these are literal values. The <> do not appear in the generated IDL. [CREATE TYPE TEMPLATE] Apply the named template. The [] do not

9/1/97 Meta Object Facility 1.1 7-1 Section 7. The MOF Model to IDL Mapping

appear in the generated IDL. // for each parameter Gives the rules on when and how to perform the IDL generation, or some general commentary on the process. Does not appear in the generated IDL.

7.2 Design Rationale During the design of the MOF Model to IDL mapping, several design decisions were made which are explained in this section.

7.2.1 Identifier Naming Identifier naming is an important issue for automatically generated IDL, especially when that IDL is intended to be used by applications written by human programmers. The mapping has to reach a balance between conflicting requirements:

• Syntactic correctness - all identifiers in the mapped IDL must conform to the defined CORBA IDL syntax, and they must also all conform to the CORBA scoping and upper/lower casing restrictions. • User friendliness - identifiers should be convey as much information as possible without being overly long. • Conformance to existing conventions - identifiers should conform to existing stylistic conventions.

The approved stylistic conventions for published CORBA IDL are described in the Object Services Architecture (OMG 95-1-47), which states:

• Interfaces and Types − Tokens representing interface and type names are capitalized. If the name of an interface of type consists of multiple words, each word is capitalized.

• Operations and Attributes − Tokens representing operations, attributes formal operation parameters, struct member − names, and union branches are all lower-case. If the token consists of multiple words, the − words are separated by underscores (_).

The IDL mapping expands these conventions to cover kinds of CORBA identifier not covered above; e.g. module names, constant names and enumerators below.

7-2 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

7.2.1.1 Rules for Splitting MOF Model Names into “Words” The MOF Model defines a “visible” Name as a sequence of characters that conforms to the CORBA IDL identifier syntax. (There are also “invisible” names that start with a “*” character, but these are not relevant to the IDL mapping.) The CORBA style conventions depend on the notion that an identifier may consist of a number of words.

In the absence of any formal mechanisms for defining word boundaries in MOF Names, the IDL mapping uses a heuristic to split an identifier into words. A “word” is defined to be an upper-case letter, followed optionally by more upper-case letters and digits and then optionally by lower-case letters and digits. One or more underscores will terminate a word. This can be expressed more formally by the following mini-grammar:

word ::= [A-Z][A-Z0-9]*[a-z0-9]*

| [a-z][a-z0-9]*

identifier ::= word “_”* { word "_"* }*

7.2.1.2 Identifier Format 1 In Format 1, the first letter of each word is converted into upper case, and other letters remain the same case as input. The words are not separated by other characters.

Here are some examples of :

Name Name split into words Identifier in Format 1

foo "foo" Foo foo_bar "foo" "bar" FooBar ALPHAbeticalOrder "ALPHAbetical" "Order" ALPHAbeticalOrder a1B2c3_d4_ "a1" "B2c3" "d4" A1B2c3D4 DSTC_pty_ltd "DSTC" "pty" "ltd" DSTCPtyLtd

Format 1 is used for the names of:

• modules • interfaces • data types (including typedef’d data types) • constants

9/1/97 Meta Object Facility 1.1 7-3 Section 7. The MOF Model to IDL Mapping

CORBA’s built-in types (e.g. unsigned long, string, TypeCode, Object etc.) are never re- formatted. They always appear “as-is”. However, when IDL generation creates collections kinds for built-in types, then the names are formatted according to the Format 1 rules.

7.2.1.3 Identifier Format 2 In Format 2, all letters in each word are converted into lower case. Each word is separated by an underscore “_”.

Here are some examples:

Name Name split into words Identifier in Format 2

foo "foo" foo foo_bar "foo" "bar" foo_bar ALPHAbeticalOrder "ALPHAbetical" "Order" alphabetical_order a1B2c3_d4_ "a1" "B2c3" "d4" a1_b2c3_d4 DSTC_pty_ltd "DSTC" "pty" "ltd" dstc_pty_ltd

Format 2 is used for the names of:

• operations • exceptions • attributes • formal parameters • members of structs and unions • enumerators

7.2.1.4 Literal String Values Literal string values are not re-formatted and appear in the generated IDL exactly as they were input to the MOF.

7.2.1.5 Externally Defined Identifiers A MOF implementation may allow a DataType to contain a typecode for a CORBA data type or interface type that is defined outside of the MOF (e.g. in a CORBA Interface Repository). When the IDL mapping needs to name one of these types, the qualified identifier is generated without any re-formatting.

7-4 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

7.2.2 Generation Rules for Collection Kinds At various places in the mapped interfaces it is necessary to represent collections of values. For example, the MOF Model allows type attributes and operation parameters to be defined as collections of objects or data types. In each case, the collection kind is defined by the base type or data type, a minimum and maximum number of values, and a pair of flags that determine respectively whether the collection is ordered and whether its elements must be unique.

The IDL types for collections (or more precisely any multiplicity with cardinality other than [1..1]) are all typedef aliases for an unbounded CORBA sequence of the collection base type. Different typedef names are used depending on the collection's multiplicity.

If the collection is ordered and unique, then the collection is a unique list (or UList). The typedef name for a unique list takes the form UList (i.e. the name of the collection base type followed by the characters UList). For example, if an Operation is defined as returning an ordered, unique list of values of some Type called "Foo", then the mapping rules define the result type of the corresponding IDL operation to be called FooUList. The IDL declaration for this collection kind would be:

typedef sequence FooUList;

The mapping defines four distinct collection kind suffixes corresponding to the four possible combinations of the "ordered" and "unique" flags.

Multiplicity Flags Collection Kind Suffix

none bag Bag ordered list List unique set Set ordered, unique unique list UList (ordered set)

Similar collection kind naming conventions are used when the Type is replaced by a DataType. Thus for a set of some enumeration type, the mapping would produce the following:

enum SomeEnum { e1, e2 }; typedef sequence SomeEnumSet;

When the DataType is a built-in CORBA type, the base name for the type is defined as follows:

9/1/97 Meta Object Facility 1.1 7-5 Section 7. The MOF Model to IDL Mapping

Built-in CORBA type Base name

short Short long Long unsigned short UShort unsigned long ULong float Float double Double boolean Boolean char Char octet Octet any Any TypeCode TypeCode Object Object

Thus for example, the collection kind for a set of "unsigned short" values would be defined as:

typedef sequence UShortSet;

The collection kinds for CORBA built-in data types are declared (in the Package Template) near the beginning of the CORBA module for each top-level Package.

The declarations for collections whose base types are user defined types or data types appear in one of two places. If the base type is defined within the top-level Package in which it is used, the collection kinds are declared immediately after the point at which the base type is introduced (in the DataType or Type Forward Declaration Templates). If the base type is imported or inherited, the collection kinds are declared near the beginning of the relevant Package (in the Import or Package Template).

Since CORBA sequence types require considerable run-time support code in some language bindings, the IDL mapping specification allows collection kind declarations to be omitted if they are not needed in a package.

A server implementation for the interfaces produced by the IDL mapping should ensure that a sequence passed or returned in a collection kind contains an appropriate number of elements. If the collection is a set or unique list, it should also ensure that the sequence it contains no duplicates.

7-6 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

7.2.3 Identifier Name Scoping To avoid scoping errors within the mapped IDL, identifier names must be either fully scoped, or partially scoped to an appropriate level. This submission leaves the choice between full and partial scoping to the implementor.

7.3 MOF Model to IDL Mapping Rules Model specific IDL is produced by traversing the containment hierarchy of a nominated top-level Package. The CORBA module structure of the resulting IDL directly reflects the containment hierarchy of the source Package. Thus, if element X contains element Y in the source model, then the IDL corresponding to X will have the IDL corresponding to Y embedded in it (assuming that IDL is produced for Y).

The IDL mapping supports the containment hierarchy for ModelElements described in the section named Rules for ModelElement Containment with one exception. That exception is that the IDL mapping does not provide a mapping for Types that are nested within other Types.

Note: The mapping rules described in terms of IDL templates. Each Template describes the maximum IDL which could be generated when mapping MOF Model objects. In any specific case, the actual IDL generated will depend on the properties of the corresponding MOF Model object.

Throughout the following Template descriptions, the IDL is said to be "generated by" the Templates. Clearly the Templates do not generate IDL in a literal sense. Instead, the reader should imagine that each Template has been coded as a function in a hypothetical generator program. When it is called with the appropriate kind of MOF ModelElement object as input, the function will "elaborate" the template to produce an appropriate fragment of CORBA IDL. The use of the Template terminology is a matter of notational convenience, not an implied implementation strategy.

7.3.1 Package Template This section describes the rules for mapping a MOF Package object to CORBA IDL as expressed in the Package Template.

The Package Template generates a CORBA IDL module that contains the IDL for each of the Constants, Data Types, Exceptions, Constraints, Imports, Types and Associations contained by a Package object. Additional IDL is produces for creating and managing CORBA objects that can be thought of as model instances or schemas.

Package Template

[ANNOTATION TEMPLATE]

// if the Package is a top level Package [IMPORT TEMPLATE]

9/1/97 Meta Object Facility 1.1 7-7 Section 7. The MOF Model to IDL Mapping

module {

// if the Package is a top level Package, generate any collection // kinds for builtin types that are required typedef sequence < > ;

// if the Package inherits from other Packages, generate any // collection kinds for inherited types that are required typedef sequence < > ;

[IMPORT TEMPLATE]

interface Package; // forward declaration

// for each Type contained in the Package [TYPE FORWARD DECLARATION TEMPLATE]

// for each Package, DataType, Exception, Type, Association, Constraint // and Constant contained by the Package, generate appropriate IDL [PACKAGE TEMPLATE] [DATATYPE TEMPLATE] [EXCEPTION TEMPLATE] [TYPE TEMPLATE] [ASSOCIATION TEMPLATE] [CONSTRAINT TEMPLATE] [CONSTANT TEMPLATE]

interface PackageFactory { [PACKAGE CREATE TEMPLATE] };

interface Package : Reflective::Package // if no supertypes Package, // if supertypes . . . // if supertypes Package // if supertypes { // if this Package is nested within another readonly attribute Package enclosing_package_ref;

// for each contained Package readonly attribute Package _ref;

// for contained Type readonly attribute Class _class_ref;

7-8 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

// for contained Association readonly attribute _ref; };

}; // end of module

Prior to the declaration of a Package module, an Annotation for the Package will be generated as specified by the Annotation Template.

If the Package for which IDL is being generated is a top level Package (i.e. it is not contained within another Namespace), the generated IDL for the Package will have "#include" statements for each of the items referenced or imported into the Package. The Import Template describes the IDL generated in this case.

The Package Template maps the Package name to an IDL module name and the contents of this module reflect the containment hierarchy of the Package.

If the Package is a top level Package (i.e. it is not contained within another Namespace) then collection kinds for each of the MOF built in types are then generated. If a top level Package inherits from other Packages, collection kinds are also generated for inherited Types and DataTypes. Collection kinds need only be generated if they are going to be used later within the current module.

A forward declaration is generated for the interface for package instance objects following the declarations for the collection kinds. The name of the Package interface is Package.

Next, the Package Template generates forward declarations of interfaces for each Type contained within the Package. The IDL generated at this point is described in the Type Forward Declaration Template.

Following the forward declarations for the Types contained in the Package, IDL is generated for each of the Packages, Data Types, Exceptions, Types, Associations, Constraints and Constants contained by the Package. The IDL generated for each of these items is described in the appropriate Template and can be found later in this section. The IDL for the contained objects must be generated in an order that reflects their dependencies; i.e. the IDL for an object should be generated before that for any other whose declaration depends on it.

Now that the IDL for the contents of a Package has been generated, the Package Template generates two interfaces for the Package itself; i.e. the Package Factory interface and the Package interface which was forward declared earlier in the module.

The Package Factory interface is generated for top level Packages only. It has a name of the form PackageFactory and contains a single "factory" operation to create instances of the Package type. This operation is generated by the Package Create Template.

Following the declaration for the Package Factory interface, the Package interface is generated with name Package. This interface may inherit the

9/1/97 Meta Object Facility 1.1 7-9 Section 7. The MOF Model to IDL Mapping

Reflective::Package interface (if the Package does not have supertypes) or each of its supertype’s Package interface (if it does have supertypes). The contents for the Package interface consists of a number of readonly attributes, depending on the Package's context and contents.

If the Package is nested within another Package, a readonly attribute called containing_package_ref is generated. This attribute holds an object reference for the instance of the outer Package that contains the current instance.

If the Package contains nested Packages, a readonly attribute called _ref is generated for each nested Package. These attributes hold object references for the Package instances for the nested Packages.

If the Package contains Types, a readonly attribute called _class_ref is generated for each such Type. These attributes hold references to the Package instance's class proxy object for each Type.

If the Package contains Associations, a readonly attribute called _ref is generated for each such Association. These attribute hold references to the Package instance's association (table) object for each Association.

7.3.2 Package Create Template The Package Create Template describes the IDL generation rules used to generate an operation which, when implemented, will create a new instance of the Package. The Package Create Template is called in the IDL generation process by the Package Template for top level Packages.

Package Create Template

Package create__package (

// for each non-derived class level Attribute of any directly or // indirectly contained type of this Package and any it inherits in , . . . // NB The last parameter does not have a comma ) raises (Reflective::SemanticError);

The IDL generated by the Package Create Template declares an operation called create__package which returns a new Package of type Package. The parameters to this operation give initial values for the non-derived classifier level attributes of any Types that belong to this Package. The parameter declarations are generated in the sequence defined by a recursive depth first traversal of the Package's ancestors and components, visiting a Package's supertypes before its contents.

7-10 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

The operation raises the generic MOF exception Reflective::SemanticError.

7.3.3 Type Forward Declaration Template The Type Forward Declaration Template describes the IDL mapping rules which generate forward declarations for each of the Types contained within a Package. The Type Forward Declaration Template also describes the generation of types representing the various collection kinds of the Type required by the Package. The IDL generated by this Template will be created when mapping Packages which contain Types.

Type Forward Declaration Template interface Class; interface ;

// generate any collections required by this Package typedef sequence < > Set; typedef sequence < > Bag; typedef sequence < > List; typedef sequence < > UList;

The Type Forward Declaration Template generates a forward declaration for the and Class interfaces for a Type.

If collection kinds for the Type are used later in the module, their declarations are generated at this point.

7.3.4 Type Template The Type Template defines the rules for IDL generation for Types. The IDL generated by the Type Template is generated within the scope of the module for the Type’s containing Package and consists of two interfaces.

The Type Class interface is the interface for class proxy object for the type. It provides functionality for class-level Attributes and Operations for the Type, along with a Type factory operation and CORBA attributes holding all instances created.

The Type interface is the interface for instances of the type. It provides functionality for the Type's instance-level Attributes and Operations along with its References.

Type Template

[ANNNTATION TEMPLATE] interface Class : Reflective::RefObject // if no supertypes : Class, // if supertypes

9/1/97 Meta Object Facility 1.1 7-11 Section 7. The MOF Model to IDL Mapping

. . . // if supertypes Class // if supertypes {

// reference to ’s container readonly attribute Package enclosing_package_ref;

// get all including subtypes of readonly attribute Ulist all_of_kind_;

// if the Type is concrete (ie. It is not abstract) // get all excluding subtypes of readonly attribute Ulist all_of_type_;

// for each Constant, DataType, Exception, Constraint, Import, // class-level Attribute and class-level Operation in the Type, // generate the appropriate IDL [DATATYPE TEMPLATE] [CONSTRAINT TEMPLATE] [CONSTANT TEMPLATE] [ATTRIBUTE TEMPLATE] [OPERATION TEMPLATE] [EXCEPTION TEMPLATE]

// if the Type is concrete (ie. not is_abstract) [TYPE CREATE TEMPLATE]

}; // end of interface Class interface : Class, , // if supertypes . . . // if supertypes // if supertypes { // for each instance-level Attribute, AssociationReference, and // instance-level Operation contained in the Type, generate the // appropriate IDL [ATTRIBUTE TEMPLATE] [REFERENCE TEMPLATE] [OPERATION TEMPLATE]

}; // end of interface

Prior to the declaration of the interfaces for the Type, an Annotation for the Type will be generated as specified by the Annotation Template.

7-12 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

The Type Class interface, which has a name of the form Class, is the interface for class proxy objects for the Type. This interface inherits from either Reflective::RefObject (if the Type does not have supertypes) or the Class interfaces for each of its supertype (if the Type does have supertypes) and contains the class-wide data types, exceptions, constants, attributes and operations for Type.

A readonly attribute with the name enclosing_package_ref is included within a Type Class interface. This attribute provides a reference to the Type’s containing Package.

A readonly attribute with a name of the form all_of_kind_ is also declared within a Type Class interface. This attribute returns a list of all instances of the Type including those Types which are subtypes of the Type.

If the Type is concrete (i.e. not abstract), then another readonly attribute is included in the IDL for the Type Class interface. This attribute has a name of the form all_of_type_ and returns a list of all the instances of the Type.

Next, the relevant Templates are used to generate IDL for contents of the Type excluding instance-level Attributes and Operations, and Imports. The Data Type, Constraint, Constant, Attribute, Operation and Exception Templates are used as required. The Type's contents must be mapped in some sequence that ensures that identifiers in the IDL are declared before the constructs that need to use them.

The final operation declared within the Type Class interface is only declared if the Type in question is concrete (i.e. not abstract). If this is the case, then a Type create operation will be generated according to the mapping rules described in the Type Create Template.

Following the class proxy interface, the Type Template generates the interface. This inherit from the Class interface, along with the interfaces for each of its supertype Types.

The Attribute, Reference and Operation Templates are used generate IDL for each of the Type's instance-level Attributes, References and instance-level Operations.

7.3.5 Type Create Template The Type Create Template defines a mapping rule used when mapping Types to IDL. The Type Create Template generates a factory operation which will create a new instance of the Type's interface.

Type Create Template

create_ ( // for each non-derived direct or inherited attribute in , ) raises ( Reflective::SemanticError, // if the Type is_singleton Reflective::AlreadyCreated,

9/1/97 Meta Object Facility 1.1 7-13 Section 7. The MOF Model to IDL Mapping

// if the Type or initialised attributes are constrained Reflective::ConstraintViolation);

The IDL generated by the Type Create Template declares an operation called create_ which, when implemented, will create a new instance of that Type when provided with values for each of the Type’s non-derived direct or inherited attributes.

The operation declaration includes "raises" clause for the Reflective::SemanticError exception along with the Reflective::AlreadyCreated exception if the Type is a singleton and the Reflective::ConstraintViolation exception if the Type or an initialized Attribute is constrained.

7.3.6 Association Template The Association Template defines the rules for mapping Associations to IDL. The Association Template generates an interface for an Association which contains attributes and operations to retrieve and modify the Association’s value(s).

Association Template

// data types for Association struct Link { ; ; }; typedef sequence < Link > LinkSet;

[ANNOTATION TEMPLATE] interface // this is an implementable object : Reflective::ReflectiveAssociation { // reference to ’s container readonly attribute Package enclosing_package_ref;

// list of associated elements LinkSet all__links ();

boolean exists ( in , in );

// if associationend2 has max multiplicity 1 with_ ( in );

7-14 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

// if associationend2 has max multiplicity > 1 with_ ( in );

// if associationend1 has max multiplicity 1 with_ ( in );

// if associationend1 has max multiplicity > 1 with_ ( in )

void add ( in , in ) raises ( Reflective::StructuralError, Reflective::SemanticError);

// if associationend1 has a max multiplicity of > 1 and is_ordered void add_before ( in , in , in before) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError);

// if associationend2 has max multiplicity > 1 and is ordered void add_before_ ( in , in , in before) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError);

void modify_ ( in , in , in new_) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError);

9/1/97 Meta Object Facility 1.1 7-15 Section 7. The MOF Model to IDL Mapping

void modify_ ( in , in , in new_) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError);

void remove ( in , in ) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); };

The Association Template generates a data structure to contain the relationships for this Association as an unique list of Links (the LinkSet type). The Links are described using an IDL structure identified as Link.

Prior to the declaration of an interface for the Association, the Annotation for the Association will be generated as specified by the Annotation Template. An interface for the Association is declared following the Annotation. The name of the interface is mapped directly from the name of the Association and the interface will be declared as inheriting from the Reflective::Association interface.

The contents of an Association interface will consist of a single attribute followed by a series of operations. The operations generated at this point are dependent upon the multiplicity of the Association’s AssociationEnds.

Prior to the declaration of operations, a readonly attribute will be declared with the name enclosing_package_ref which provides a reference to the Attribute’s containing Package.

The operations generated for an Association can be categorized as follows: operations to list associated elements, an operation to test an association between two elements and operations to modify the value(s) of an Association.

The all__links() operation returns the list of associated elements. The return value for this operation is a LinkSet. The operation requires no parameters and does not raise exceptions.

The Association Template will generate with operations which return the values associated with a specific AssociationEnd. If the multiplicity of the Association’s AssociationEnds is not 1..1 or 0..1, then a with operation will return a collection kind.

7-16 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

The collection kind is dependent upon the ordering and uniqueness of the AssociationEnds. The rules for the selection of appropriate collection kind are described in the section named Generation of Collection Kinds.

If the Association’s has an upper multiplicity bound of exactly one, then a with_ operation will be including in the IDL generated for the Association. This operation requires as a parameter an value and returns the value associated with . The operation will not raise any exceptions.

If the Association’s has an upper multiplicity bound greater than one, then a with_ operation will be including in the IDL generated for the Association. This operation requires as a parameter an value and returns the values associated with . The values will be returned as a collection kind and the operation will not raise any exceptions.

If the Association’s has an upper multiplicity bound of exactly one, then a with_ operation will be including in the IDL generated for the Association. This operation requires as a parameter an value and returns the value associated with . The operation will not raise any exceptions.

If the Association’s has an upper multiplicity bound greater than one, then a with_ operation will be including in the IDL generated for the Association. This operation requires as a parameter an value and returns the values associated with . The values will be returned as a collection kind and the operation will not raise any exceptions.

The exists operation provides a mechanism to test if two AssociationEnds known within this Association. This operation returns a true if the AssociationEnds and are associated. The operation may not raise exceptions.

The operations to modify the values of an Association consist of add, modify and remove operations.

Two add operations may be included with the generated IDL for an Association. The add operation allows a new Link to be added to the Association. The operation signatures are dependent upon which AssociationEnd the operation is being generated for.

add_before operations are generated for the ordered AssociationEnd in an Association. If the operation is generated for the Association’s , then the operation will be named add_before_ and will require three parameters: the values of the two new AssociationEnds to be added to the Association and an existing value. The new AssociationEnd values will be inserted into the list of the Association’s values immediately before the existing value. This operation may raise the Reflective::StructuralError, Reflective::NotFound or Reflective::SemanticError exceptions.

9/1/97 Meta Object Facility 1.1 7-17 Section 7. The MOF Model to IDL Mapping

If the add_before operation is generated for the Association’s , then the operation will be named add_before_ and will require three parameters: the values of the two new AssociationEnds to be added to the Association and an existing value. The new AssociationEnd values will be inserted into the list of the Association’s values immediately before the existing value. This operation may raise the Reflective::StructuralError, Reflective::NotFound or Reflective::SemanticError exceptions.

Two modify operations may also be included with IDL generated for an Association. These operations allow for the modification of an existing Link in the Association. The operation signatures are dependent upon which AssociationEnd the operation is being generated for.

If the modify operation is being generated for the Association’s , the operation will be named modify_ and will require as parameters the AssociationEnds representing the Link to be modified, along with a new . The value in the existing Link will be modified to the new value. The operation may raise the Reflective::StructuralError, Reflective::NotFound or Reflective::SemanticError exceptions.

If the modify operation is being generated for the Association’s , the operation will be named modify_ and will require as parameters the AssociationEnds representing the Link to be modified, along with a new . The value in the existing Link will be modified to the new value. The operation may raise the Reflective::StructuralError, Reflective::NotFound or Reflective::SemanticError exceptions.

The final operation which may be included in the generated IDL for an Association is a remove operation. This operation removes the Link specified by the parameters from the Association. The operation may raise the Reflective::StructuralError, Reflective::NotFound or Reflective::SemanticError exceptions.

7.3.7 Attribute Template The Attribute Template defines the rules for mapping a MOF Type’s Attributes to IDL. The Attribute Template declares operations to query and modify the value of an Attribute within the scope of the Attribute’s Type interface (if the Attribute is an instance level Attribute) or Type Class interface (if the Attribute is a classifier level Attribute). The signatures of these operations are dependent upon the multiplicity, mutability, uniqueness and ordering of the Attribute.

Attribute Template

[ANNOTATION TEMPLATE]

7-18 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

// Let MULT_CONSTRAINT be (lower > 0 or upper != ‘*’ or is_unique)

// if lower = 0 and upper = 1 () raises ( Reflective::NotSet, Reflective::SemanticError);

// if lower = 1 and upper = 1 () raises (Reflective::SemanticError);

// if upper > 1 () raises (Reflective::SemanticError);

// if upper = 1 and is_changeable void set_ (in new_value) raises (Reflective::SemanticError);

// if upper > 1 and is_changeable and MULT_CONSTRAINT void set_ (in new_value) raises ( Reflective::StructuralError, Reflective::SemanticError);

// if upper > 1 and is_changeable and !MULT_CONSTRAINT void set_ (in new_value) raises (Reflective::SemanticError);

// if lower = 0 and is_changeable void unset_ () raises (Reflective::SemanticError);

// if upper > 1 and is_changeable and MULT_CONSTRAINT void add_ (in new_value) raises ( Reflective::StructuralError, Reflective::SemanticError);

// if upper > 1 and is_changeable and !MULT_CONSTRAINT void add_ (in new_value) raises (Reflective::SemanticError);

// if upper > 1 and is_changeable and is_ordered and MULT_CONSTRAINT void add__before ( in new_value, in before_value)

9/1/97 Meta Object Facility 1.1 7-19 Section 7. The MOF Model to IDL Mapping

raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError);

// if upper > 1 and is_changeable and is_ordered and !MULT_CONSTRAINT void add__before ( in new_value, in before_value) raises ( Reflective::NotFound, Reflective::SemanticError);

// if upper > 1 and is_changeable and is_ordered and MULT_CONSTRAINT void add__at ( in new_value, in unsigned long position) raises ( Reflective::StructuralError, Reflective::BadPosition, Reflective::SemanticError);

// if upper > 1 and is_changeable and is_ordered and !MULT_CONSTRAINT void add__at ( in new_value, in unsigned long position) raises ( Reflective::BadPosition, Reflective::SemanticError);

// if upper > 1 and is_changeable and is_unique void modify_ ( in old_value, in new_value) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError);

// if upper > 1 and is_changeable and !is_unique void modify_ ( in old_value, in new_value) raises ( Reflective::NotFound, Reflective::SemanticError);

// if upper > 1 and is_changeable and is_ordered and is_unique

7-20 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

void modify__at ( in new_value, in unsigned long position) raises ( Reflective::StructuralError, Reflective::BadPosition, Reflective::SemanticError);

// if upper > 1 and is_changeable and is_ordered and !is_unique void modify__at ( in new_value, in unsigned long position) raises ( Reflective::BadPosition, Reflective::SemanticError);

// if upper > 1 and is_changeable and MULT_CONSTRAINT void remove_ ( in old_value) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError);

// if upper > 1 and is_changeable and !MULT_CONSTRAINT void remove_ ( in old_value) raises ( Reflective::NotFound, Reflective::SemanticError);

// if upper > 1 and is_changeable and is_ordered and MULT_CONSTRAINT void remove__at (in unsigned long position) raises ( Reflective::StructuralError, Reflective::BadPosition, Reflective::SemanticError);

// if upper > 1 and is_changeable and is_ordered and !MULT_CONSTRAINT void remove__at (in unsigned long position) raises ( Reflective::BadPosition, Reflective::SemanticError);

Prior to the declarations of the operations for an Attribute, an Annotation for the Attribute will be generated as specified by the Annotation Template.

9/1/97 Meta Object Facility 1.1 7-21 Section 7. The MOF Model to IDL Mapping

The operations which may be included in the generated IDL for an Attribute can be categorized into operations which return its value(s) and operations which modify its value(s).

The name of an operation to return the value of an Attribute is mapped directly from the Attribute’s name. This type of operation will not require parameters (i.e. its name will be of the form ()) but its return type is dependent upon the multiplicity of the Attribute.

If the upper and lower multiplicity bounds for the Attribute are both zero or both one, then the operation will return a single value representing the value of the Attribute If the Attribute’s upper multiplicity bound is greater than one, then the operation will return the collection of the Attribute’s values.

The operations to modify the value of an Attribute may be categorized into set, unset, add, modify, and remove operations. These operations are included in the generated IDL for an Attribute depending on the Attribute’s multiplicity, mutability, uniqueness and ordering. To assist in the explanation of this area of the IDL generation process, the term Multiplicity Constraint will be used which represents the following constraints on an Attribute:

• the lower multiplicity bound is greater than zero or • the upper multiplicity bound is not unbounded or • the is_unique flag is true

If the Multiplicity Constraint is described as true, then the above constraints are true. If the Multiplicity Constraint is described as false, then the above constraints are not true.

set operations have a return type of void and a name of the form set_ and are included in the generated IDL for an Attribute in three cases.

A set_ operation is declared for an Attribute if the Attribute is_changeable and has a multiplicity upper bound of exactly one. This operation will set the value of the Attribute to the value of the parameter passed to it (new_value).

A set_ operation is declared for an Attribute if the Attribute: is_changeable, has an upper multiplicity bound greater than one and the Attribute’s Multiplicity Constraints are true. This operation will set the value of the Attribute to the value of the parameter passed to it (new_value).

The final case in which a set_ operation will be included in the IDL for an Attribute is if it is_changeable and has an upper multiplicity bound greater than one and the Attribute’s Multiplicity Constraints are not true. This operation will set the value of the Attribute to the value of the parameter passed to it (new_value).

An operation with a name unset_ will be included in the generated IDL for an Attribute if its lower multiplicity bound is exactly zero and it is_changeable. When this operation is invoked, the Attribute’s value will be set to an empty multiplicity.

add operations may also be included in the IDL generated for an Attribute. These operations may be categorized into three types: add_ operations,

7-22 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

add__before operations and add__at operations. In each case, the operation will return a void.

If an Attribute is_changeable and has a upper multiplicity bound greater than one and the Attribute’s Multiplicity Constraints are true, then an add_ operation will be included in the generated IDL for the Attribute. This operation adds the value provided by its parameter to the list of values for the Attribute.

If an Attribute is_changeable, has a upper multiplicity bound greater than one and the Attribute’s Multiplicity Constraints are not true, then an add_ operation will be included in the generated IDL for the Attribute. This operation will require a single parameter representing the value to be added to the Attribute and may raise the Reflective::SemanticError exception.

If an Attribute is_changeable and is_ordered and upper multiplicity bound greater than one the Attribute’s Multiplicity Constraints are true, then an add__before operation is included in the generated IDL for the Attribute. The operation requires two parameters: the first representing the new value to be inserted into the Attribute’s values (new_value) and the second representing a current value in the Attribute’s values immediately before which new_value will be inserted. This operation may raise the Reflective::StructuralError, Reflective::NotFound or Reflective::SemanticError exceptions.

If an Attribute is_changeable and is_ordered and upper multiplicity bound greater than one and the Attribute’s Multiplicity Constraints are not true, then an add__before operation is included in the generated IDL for the Attribute. The operation requires two parameters: the first representing the new value to be inserted into the Attribute’s values (new_value) and the second representing a current value in the Attribute’s values immediately before which new_value will be inserted. This operation may raise the Reflective::NotFound or the Reflective::SemanticError exceptions.

If an Attribute is_changeable and is_ordered and upper multiplicity bound greater than one and the Attribute’s Multiplicity Constraints are true, then an add__at operation is included in the generated IDL for the Attribute. The operation requires two parameters: the first representing the new value to be inserted into the Attribute’s values (new_value) and the second representing the ordinal position in the Attribute values where new_value will be inserted. This operation may raise the Reflective::StructuralError, Reflective::BadPosition or Reflective::SemanticError exceptions.

If an Attribute is_changeable and is_ordered and upper multiplicity bound greater than one and the Attribute’s Multiplicity Constraints are not true, then an add__at operation is included in the generated IDL for the Attribute. The operation requires two parameters: the first representing the new value to be inserted into the Attribute’s values (new_value) and the second representing the ordinal position in the Attribute values where new_value will be inserted. This operation may raise the Reflective::BadPosition or Reflective::SemanticError exceptions.

modify operations may also be included in the IDL generated for an Attribute. These operations may be categorized into modify_ operations and modify__at operations. In both cases the operation will return a void.

9/1/97 Meta Object Facility 1.1 7-23 Section 7. The MOF Model to IDL Mapping

A modify_ operation is included in the generated IDL for an Attribute if the upper multiplicity bound is greater than one and it is_changeable and it is_unique. This operation requires two parameters: the first represents a current value in the Attribute’s set of values (old_value) and the second is the new value which will replace old_value. This operation may raise the Reflective::StructuralError, Reflective::NotFound or Reflective::SemanticError exceptions.

If an Attribute is_changeable and not unique and has an upper multiplicity bound greater than one, then a modify_ operation will be included in the IDL generated for the Attribute. This operation requires two parameters: the first represents a current value in the Attribute’s set of values (old_value) and the second is the new value which will replace old_value. This operation may raise the Reflective::NotFound or Reflective::SemanticError exceptions.

If an Attribute is_changeable and is_ordered and has an upper multiplicity bound greater than one and is also unique, then a modify__at operation will be included in the generated IDL for the Attribute. The operation requires two parameters: the first representing the new value to be inserted into the Attribute’s set of values (new_value) and the second representing the ordinal position in the Attribute values at which new_value will be substituted for . This operation may raise the Reflective::StructuralError, Reflective::BadPosition or Reflective::SemanticError exceptions.

If an Attribute is_changeable and is_ordered and has an upper multiplicity bound greater than one but is not unique, then a modify__at operation will be included in the generated IDL for the Attribute. The operation requires two parameters: the first representing the new value to be inserted into the Attribute’s set of values (new_value) and the second representing the ordinal position in the Attribute values at which new_value will be substituted for . This operation may raise the Reflective::BadPosition or Reflective::SemanticError exceptions.

remove operations may also be included in the IDL generated for an Attribute. These operations may be categorized into remove_ operations and remove__at operations. In both cases the operation will return a void.

If an Attribute is_changeable, has an upper multiplicity bound greater than one and the Attribute’s Multiplicity Constraints are true, then a remove_ operation will be included in the IDL generated for the Attribute. This operation requires one parameter which represents the Attribute value which will be removed from the Attribute values. The operation may raise the Reflective::StructuralError, Reflective::NotFound or Reflective::SemanticError exceptions.

If an Attribute is_changeable, has an upper multiplicity bound greater than one and the Attribute’s Multiplicity Constraints are not true, then a remove_ operation will be included in the IDL generated for the Attribute. This operation requires one parameter which represents the Attribute value which will be removed from the Attribute values. The operation may raise the Reflective::NotFound or Reflective::SemanticError exceptions.

If an Attribute is_changeable, has an upper multiplicity bound greater than one, is_ordered and the Attribute’s Multiplicity Constraints are true, then a remove__at operation will be included in the IDL generated for the

7-24 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

Attribute. The operation requires a single parameter which represents the ordinal position of the value in the Attribute’s values which is to be removed (i.e. remove the nth value in the set of values for the Attribute where n is position). The operation may raise the Reflective::StructuralError, Reflective::BadPosition or Reflective::SemanticError exceptions.

If an Attribute is_changeable, has an upper multiplicity bound greater than one, is_ordered and the Attribute’s Multiplicity Constraints are not true, then a remove__at operation will be included in the IDL generated for the Attribute. The operation requires a single parameter which represents the ordinal position of the values for the Attribute which is to be removed (i.e. remove the nth value in the set of values for the Attribute where n is position). The operation may raise the Reflective::BadPosition or Reflective::SemanticError exceptions.

7.3.8 Reference Template The Reference Template defines the rules for IDL generation for a Reference. The IDL generated for an Reference is declared within the scope of Type Class interface definition. The IDL generated by the Reference Template provides the operations to return the value of the Reference as well as operations to modify it. The IDL generated is dependent upon the multiplicity, mutability and ordering of the specified Reference.

Reference Template

[ANNOTATION TEMPLATE]

// operations to return the Reference value // if lower = 0 and upper = 1 () raises ( Reflective::NotSet, Reflective::SemanticError);

// if lower = 1 and upper = 1 () raises (Reflective::SemanticError);

// if upper > 1 () raises (Reflective::SemanticError);

// operations to modify the Reference value // if upper = 1 and is_changeable void set_ ( in new_value) raises (Reflective::SemanticError);

// if upper > 1 and is_changeable

9/1/97 Meta Object Facility 1.1 7-25 Section 7. The MOF Model to IDL Mapping

void set_ ( in new_values) raises ( Reflective::StructuralError, Reflective::SemanticError);

// if lower = 0 and is_changeable void unset_ () raises (Reflective::SemanticError);

// if upper > 1 and is_changeable void add_ ( in new_value) raises (Reflective::StructuralError);

// if upper > 1 and is_changeable and is_ordered void add__before ( in new_value, in before) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError);

// if upper > 1 and is_changeable void modify_ ( in old_value, in new_value) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError); void remove_ ( in old_value) raises ( Reflective::StructuralError, Reflective::NotFound, Reflective::SemanticError);

Prior to the declaration of the operations for an Reference, an Annotation for the Reference will be generated (as specified by the Annotation Template).

The Reference Template generates two kinds of operations: operations to return the value of a Reference and operations to modify the value of a Reference. The operations

7-26 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

to return the value of a Reference will always be generated where as the operations to modify its value will only be generated if the Reference’s is_changeable flag is true.

The IDL operation generated to return the value of a Reference will be declared with the name while the remainder of the operation’s signature is determined by the multiplicity of the Reference.

If the Reference has a lower multiplicity constraint of zero and an upper constraint of one, the operation will be declared as returning a single Reference value and as capable of raising the Reflective::NotSet and Reflective::SemanticError exceptions.

If the upper and lower bounds of the Reference’s multiplicity are both one, the operation will be declared as returning a single Reference value and may raise the Reflective::SemanticError exception.

If the Reference’s multiplicity has an upper bound greater than one, then the operation will be declared as returning a collection of Reference values and is capable of raising the Reflective::SemanticError exception.

IDL to modify the value of an Reference will only be generated if the is_changeable flag for the Reference is set to true. Each of these modify operations will have a void return type while the rest of the operation signatures are dependent on the multiplicity of the Reference.

If the Reference has a multiplicity upper bound of one, the Reference mapping will include an operation to set the value of the Reference called set_. This operation requires as a parameter the value to which the Reference will be set and is declared as capable of raising the Reflective::SemanticError exception.

If the Reference has a multiplicity upper bound greater than one, the Reference mapping will include a set_< reference_name> operation which provides a mechanism to modify the values of the Reference. This operation requires a parameter which represents the new values of the Reference and may raise the Reflective::StructuralError and Reflective::SemanticError exceptions.

An unset_< reference_name> operation will be included if the Reference has a multiplicity lower bound is zero. This operation does not require parameters and may raise the Reflective::SemanticError exception.

An add_< reference_name> operation will be included if the Reference has a multiplicity upper bound greater than one. This operation will require a parameter which represents the new value for the Reference and may raise the Reflective::StructuralError exception.

If the Reference has a multiplicity upper bound of greater than one and the Reference’s Association is_ordered, then an add_< reference_name>_before operation will be included in the generated IDL. This operation will require two parameters: the first being the new value for the Reference (new_value) and the second being the current Reference value before which new_value will be inserted into the Association. This operation may raise the Reflective::StructuralError, Reflective::NotFound or the Reflective::SemanticError exceptions.

9/1/97 Meta Object Facility 1.1 7-27 Section 7. The MOF Model to IDL Mapping

A modify_< reference_name> operation may be included in the generated IDL for an Reference if the Reference has an upper multiplicity constraint greater than one. This operation requires two parameters: the first being the old value for the Reference (old_value) and the second being the new value for the Reference which will replace old_value. This operation may raise the Reflective::StructuralError, Reflective::NotFound or the Reflective::SemanticError exceptions.

The final operation generated by the Reference Template is a remove_< reference_name> operation which is generated if the Reference has a upper multiplicity bound greater than one. This operation requires a single value representing the Reference value to be removed and may raise the Reflective::StructuralError, Reflective::NotFound or the Reflective::SemanticError exceptions.

7.3.9 Operation Template The Operation Template describes the rules for mapping MOF Operations to IDL. This Template generates an IDL operation within the scope of a Type Class interface. The IDL generated by the Operation Template is dependent upon the return type, parameter declarations and exceptions that may be raised by the MOF Operation for which the IDL is being generated.

Operation Template

[ANNOTATION TEMPLATE]

// if no return parameter void ( , // if parameters . . . // if parameters // if parameters ) raises ( , // if user exceptions . . . // if user exceptions // if user exceptions Reflective::SemanticError);

// if return parameter is a single-element ( , // if parameters . . . // if parameters // if parameters ) raises ( , // if user exceptions . . . // if user exceptions // if user exceptions Reflective::SemanticError);

7-28 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

// if return parameter is a multi-element ( , // if parameters . . . // if parameters // if parameters ) raises ( , // if user exceptions . . . // if user exceptions , // if user exceptions Reflective::SemanticError);

The IDL generated for a MOF Operation maps the operation’s annotation to an IDL comment as specified by the Annotation Template.

The Operation Template maps MOF Operation names directly to an IDL operation of the same name. The remainder of the IDL operation’s signature is dependent upon the return type, parameters and exceptions raised by the MOF Operation

The return value of the MOF Operation will determine the return value of the generated IDL Operation. If the return type of the MOF Operation is void, the IDL operation’s return type will be declared as returning a void IDL value. If the MOF Operation returns a single value, then the IDL operation will be declared as returning a single value with an appropriate type. Finally, if the MOF Operation returns a multi-element type, the IDL operation will be declared as returning a collection kind of the appropriate type. The rules for determining the collection kind the operation will return are detailed in the section titled Generation Rules for Collection Kinds.

If the MOF Operation requires parameters, then the IDL Operation generated by the Operation Template will also include parameter declarations. The parameter’s type and name are mapped from those of the MOF Operation.

A MOF Operation may raise user defined exceptions in which case the Operation Template requires that the generated IDL Operations raise user defined exceptions of the same name. The user defied exceptions are generated by the Exception Template. The MOF generic exception Reflective::SemanticError will always be raised by an IDL Operation generated for a MOF model Operation.

7.3.10 Exception Template The Exception template describes the mapping of MOF Exceptions to IDL exception’s. The IDL generated for a MOF Exception maps the IDL exception’s name and parameters directly from the MOF Exception.

Exception Template

[ANNOTATION TEMPLATE]

9/1/97 Meta Object Facility 1.1 7-29 Section 7. The MOF Model to IDL Mapping

exception { // for each Parameter ; };

The generated IDL will include an Annotation for the Exception (as described by the Annotation Template) and will declare a IDL exception with the same name as the MOF Exception. The exception will return the parameters defined by the MOF Exception.

7.3.11 Constant Template The Constant Template generates IDL for a MOF Constant. MOF Constants map to a IDL const. The type, name and value of the Constant map directly from the MOF Constant to the IDL Constant as described below.

Constant Template

[ANNOTATION TEMPLATE] const = ;

The Constant Template will generate an Annotation for a MOF Constant (as described by the Annotation Template) followed by an IDL constant declaration whose type, name and value are defined by the MOF Constant.

7.3.12 Data Type Template The Data Type Template describes the rules for mapping MOF Data Types to IDL. The IDL generated by the Data Type Template is highly depended upon the Data Type in question and the need for the definition of collection kinds of the Data Type.

Data Type Template

[ANNOTATION TEMPLATE]

// if the Data Type is a struct struct { ; . . . };

// if the Data Type is a union union switch () { . . . };

// DataTypeTypeSpec for an enumerated type enum { , . . ., };

7-30 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

// typedef to create a new name for DataTypeTypeSpec typedef ;

// if collection kinds of the data type are required typedef sequence ;

The IDL generated for a MOF Data Type will include comments for that Data Type as described by the Annotation Template.

If the Data Type is a constructed type (i.e. a struct, union or enum), then the generated IDL will include a type specification for the constructed type followed by a type.

The Data Type Template then generates IDL to associate the Data Type with a new name through a typedef statement. Following this, collection kinds for the Data Type are generated if required. The rules for collection kind IDL generation are described in the section named Generation Rules for Collection Kinds.

7.3.13 Constraint Template This section describes the rules for mapping Constraints to IDL. The Constraint Template maps a Constraint to an IDL constant string.

Constraint Template

[ANNOTATION TEMPLATE] const string = “”;

If the MOF Constraint contains an Annotation, then IDL comments will be generated as described by the Annotation Template.

The Constraint Template generates a string constant whose name is the constraint name and whose value is the fully qualified name of the constraint.

7.3.14 Import Template The Import Template facilitates Package importation by generating IDL which ensures the elements of the imported Package are correctly scoped. The Import Template also generates IDL for collection kinds of types declared within an imported Package.

Import Template

// At the beginning of the IDL [ANNOTATION TEMPLATE]

9/1/97 Meta Object Facility 1.1 7-31 Section 7. The MOF Model to IDL Mapping

#include “”

// At the point of importation // for each Type or Data Type in the imported Package that is used // here with a multiplicity greater than [1..1] typedef sequence < > ;

The IDL generated by the Import Template consists of two parts. The first part is generated at the top of the importing Package if it is a top level Package. The IDL generated at this point includes an IDL #include statement to bring the imported Package into the scope of the importing Package. The subject of the #include statement an implementation detail beyond the scope of this submission.

The second part of the IDL generated by the Import Template is generated at the point in the importing Package where the imported Package is referenced. At this point, if the multiplicity of a Data Type or Type within the imported Package is greater than [1..1], then collection kinds for the Data Type or Type are generated. The collection kinds are only generated if referenced within the importing Package. The rules for generating collection kinds are described in the section named Generation Rules for Collection Kinds.

7.3.15 Annotation Template The Annotation Template generates IDL comments for an annotation supplied with a meta-meta-object. The comments will be generated over as many lines as are required to print the entire annotation and may conform to either IDL comment style (i.e. start and end with /* and */ or //).

Annotation Template

// Annotation comments may have the “/*…*/” style

/* . . . */

// or the “//” style

// // // . . . //

7-32 Meta Object Facility 1.1 9/1/97 Section 7. The MOF Model to IDL Mapping

7.4 Preconditions for Successful IDL mapping The IDL mapping may not produce valid CORBA IDL if any of the following preconditions on the input model is not satisfied:

• The MOF Model constraints as defined above must all be satisfied for the input model • The input model must be structurally consistent. • Types may not be nested within other Types • The names within a NameSpace must be unique after application of the Format1 and Format2 name rewriting algorithms. • The names within a NameSpace must not use suffixes or prefixes that will cause collisions with names generated by the mapping. • The TypeCodes in DataTypes must conform to the restrictions in the MOF Data Type Encoding and Translation Conventions section. • A nested Package may not be used as a subtype or supertype. • No Model Elements in the model can be cyclically dependent. The exception to this is that Types within the same Package may be cyclically dependent.

7.5 Semantics of the Generated Interfaces The IDL generated from an input model by the IDL mapping has no intrinsic semantics. An object server that implements the interfaces can in theory implement any semantics that it chooses. In practice, this approach should be avoided since it defeats the purpose of having a standard IDL mapping.

An implementation of the IDL mapped interfaces should as far as possible provide the semantics implied by the input model. Structural constraints on cardinality, uniqueness, type closure, composition and referential integrity defined in the model and based on the semantic descriptions in this document should be enforced. As far as possible, the model specific semantics constraints should also be enforced.

The intended detailed semantics of the operations for accessing and updating attributes, references and associations can be inferred from previous parts of the document.

9/1/97 Meta Object Facility 1.1 7-33 Section 7. The MOF Model to IDL Mapping

7-34 Meta Object Facility 1.1 9/1/97 Index

A aggregations semantic details, 6-7 AggregationType data type, 3-99 AnnotationType data type, 3-97 association Constraint-Constrains-ModelElement, 3-91 GeneralizableElement-Generalizes-GeneralizableElement, 3-80 Import-Aliases-Namespace, 3-90 ModelElement-DependsOn-ModelElement, 3-93 Namespace-Contains-ModelElement, 3-78 Operation-Raises-MofException, 3-88 Reference-Exposes-AssociationEnd, 3-84 Reference-RefersTo-AssociationEnd, 3-83 Tag-AttachesTo-ModelElement, 3-95 TypedElement-IsOfType-Classifier, 3-86 Association type, 3-53 AssociationEnd type, 3-56 associations semantic details, 6-1 B BehavioralFeature type, 3-47 C Class type, 3-33 attributes isSingleton, 3-34 contained elements, 3-33 interface, 3-34 OCL, 3-35 supertypes, 3-33 Classifier type, 3-32 interface, 3-33 supertypes, 3-32 Constant type, 3-73 Constraint type, 3-69 Constraint-Constrains-ModelElement association, 3-91 constraints OCL Representation, 3-100 conventions Reflective Package, 5-23 CORBA IDL for reflective interfaces, 5-14 D data type AggregationType, 3-99

9/1/97 Meta Object Facility 1.1 Index-1 Index

AnnotationType, 3-97 DependencyKind, 3-99 DepthType, 3-98 DirectionType, 3-99 EvaluationType, 3-99 MultiplicityType, 3-97 NameType, 3-97 ScopeType, 3-99 TristateType, 3-98 TypeDescriptor, 3-97 VerificationResultKind, 3-99 VisibilityType, 3-98 data types Reflective interface, 5-14 DataType type, 3-35 contained elements, 3-36 supertypes, 3-35 DependencyKind data type, 3-99 DepthType data type, 3-98 DirectionType data type, 3-99 E EvaluationType data type, 3-99 exception FormatNotSupported, 3-100 NameNotResolved, 3-100, 4-7 ObjectNotExternalizable, 3-100, 4-7 Exception type, 3-51 exceptions Reflective interface common, 5-15 reflective, 5-17 extensibility mechanisms semantic details, 6-25 F Facility Package IDL, A-24 MODL, B-15 types ModelRepository, 4-2 MofRepository, 4-4 Feature type, 3-39 FormatNotSupported exception, 3-100 G GeneralizableElement type, 3-24 attributes allSupertypes, 3-27 isAbstract, 3-26 isLeaf, 3-26 isRoot, 3-26

Index-2 Meta Object Facility 1.1 9/1/97 Index

visibility, 3-25 interface, 3-28 OCL, 3-30 operations findElementsByTypeExtended, 3-28 lookupElementExtended, 3-28 references supertypes, 3-27 supertypes, 3-25 GeneralizableElement-Generalizes-GeneralizableElement association, 3-80 Glossary, C-1 I IDL Facility Package, A-24 interpreting generation templates, 7-1 mapping to MOF Model design rational, 7-2 preconditions for successful mapping, 7-33 rules, 7-7 semantics of generated interfaces, 7-33 MOF Model, A-1 Reflection Package, A-26 Import type, 3-64 Import-Aliases-Namespace association, 3-90 interfaces generated for IDL mapping to MOF Model, 7-33 inter-repository modeling semantic details, 6-27 M Metamodel Comparison, D-3 ModelElement Class attributes qualifiedName, 3-14 constraints, 3-18 interface, 3-18 OCL, 3-20 operations copyElement, 3-18 findRequiredElements, 3-17 isFrozen, 3-16 isRequiredBecause, 3-17 isVisible, 3-17 removeElement, 3-18 setName, 3-16 verify, 3-16 references constraints, 3-15 container, 3-14 requiredElements, 3-15 ModelElement type, 3-13

9/1/97 Meta Object Facility 1.1 Index-3 Index

attributes annotation, 3-14 name, 3-14 containedElements, 3-13 supertypes, 3-13 ModelElement-DependsOn-ModelElement association, 3-93 ModelRepository type, 4-2 MODL Facility Package, B-15 MOF Model, B-1 MOF future directions evolution and versioning, F-1 interoperability with Microsoft repository, F-2 mapping between models, F-2 stream based interchange format, F-1 ternary and higher order associations, F-1 MOF Model aggregations semantics, 6-7 associations semantics, 6-1 extensibility mechanisms semantics, 6-25 IDL, A-1 IDL Summary, A-1 interpreting IDL generation templates, 7-1 inter-repository modeling semantics, 6-27 mapping to IDL, 7-1 design rationale, 7-2 preconditions for successful mapping, 7-33 rules, 7-7 semantics of generated interfaces, 7-33 MODL, B-1 OCL Representation of Constraints, 3-100 references semantics, 6-6 semantics details, 6-1 MOF submission adoption of, 1-2 key components/sections, 1-4 rationale, 1-2 MOF submission goals, 1-3 objectives, 1-3 MofAttribute type, 3-43 MofRepository type, 4-4 MultiplicityType data type, 3-97 N NameNotResolved exception, 3-100, 4-7 Namespace type, 3-21

Index-4 Meta Object Facility 1.1 9/1/97 Index

interface, 3-23 operations findElementsByType, 3-23 lookupElement, 3-22 nameIsValid, 3-23 resolveQualifiedName, 3-22 references contents, 3-22 supertypes, 3-21 Namespace-Contains-ModelElement association, 3-78 NameType data type, 3-97 O ObjectNotExternalizable exception, 3-100, 4-7 OCL Representation of MOF Model Constraints, 3-100 Operation type, 3-48 Operation-Raises-MofException association, 3-88 P Package type, 3-61 Parameter type, 3-67 R rationale design for MOF Model mapping to IDL, 7-2 rationale, MOF submission, 1-2 Reference type, 3-44 Reference-Exposes-AssociationEnd association, 3-84 Reference-RefersTo-AssociationEnd association, 3-83 references semantic details, 6-6 Reflection Package IDL, A-26 Reflective interface data types, 5-14 exceptions common, 5-15 reflective, 5-17 Reflective module, 5-2 Reflective Package CORBA IDL, 5-14 reflective module, 5-2 types, 5-1 usage conventions, 5-23 rules MOF Model mapping to IDL, 7-7 S ScopeType data type, 3-99 semantic details aggregations, 6-7

9/1/97 Meta Object Facility 1.1 Index-5 Index

associations, 6-1 extensibility mechanisms, 6-25 inter-repository modeling, 6-27 MOF Model, 6-1 references, 6-6 StructuralFeature type, 3-41 T Tag type, 3-74 Tag-AttachesTo-ModelElement association, 3-95 TristateType data type, 3-98 type Association, 3-53 AssociationEnd, 3-56 BehavioralFeature, 3-47 Class, 3-33 Classifier, 3-32 Constant, 3-73 Constraint, 3-69 Exception, 3-51 Feature, 3-39 GeneralizableElement, 3-24 Import, 3-64 ModelElement, 3-13 MofAttribute, 3-43 Namespace, 3-21 Operation, 3-48 Package, 3-61 Parameter, 3-67 Reference, 3-44 StructuralFeature, 3-41 Tag, 3-74 TypeAlias, 3-77 TypedElement, 3-30 TypeAlias type, 3-77 TypedElement type, 3-30 interface, 3-32 references type, 3-31 supertypes, 3-30 TypedElement-IsOfType-Classifier association, 3-86 TypeDescriptor data type, 3-97 types DataType, 3-35 Reflective Package, 5-1 U UML-MOF Mapping, D-4 V VerificationResultKind data type, 3-99 VisibilityType data type, 3-98

Index-6 Meta Object Facility 1.1 9/1/97 Index

9/1/97 Meta Object Facility 1.1 Index-7