DOCSLIB.ORG

UML Profile for CIM

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

1 2 Document Number: DSP0219 3 Date: 2009-08-11 4 Version: 1.0.0 5 6 7 8 9 10 11 12 13 UML Profile for CIM 14 Document Type: Specification 15 Document Status: DMTF Standard 16 Document Language: E UML Profile for CIM DSP0219 17 18 Copyright Notice 19 Copyright © 2009 Distributed Management Task Force, Inc. (DMTF). All rights reserved. 20 DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems 21 management and interoperability. Members and non-members may reproduce DMTF specifications and 22 documents, provided that correct attribution is given. As DMTF specifications may be revised from time to 23 time, the particular version and release date should always be noted. 24 Implementation of certain elements of this standard or proposed standard may be subject to third party 25 patent rights, including provisional patent rights (herein "patent rights"). DMTF makes no representations 26 to users of the standard as to the existence of such rights, and is not responsible to recognize, disclose, 27 or identify any or all such third party patent right, owners or claimants, nor for any incomplete or 28 inaccurate identification or disclosure of such rights, owners or claimants. DMTF shall have no liability to 29 any party, in any manner or circumstance, under any legal theory whatsoever, for failure to recognize, 30 disclose, or identify any such third party patent rights, or for such party’s reliance on the standard or 31 incorporation thereof in its product, protocols or testing procedures. DMTF shall have no liability to any 32 party implementing such standard, whether such implementation is foreseeable or not, nor to any patent 33 owner or claimant, and shall have no liability or responsibility for costs or losses incurred if a standard is 34 withdrawn or modified after publication, and shall be indemnified and held harmless by any party 35 implementing the standard from any and all claims of infringement by a patent owner for such 36 implementations. 37 For information about patents held by third-parties which have notified the DMTF that, in their opinion, 38 such patent may relate to or impact implementations of DMTF standards, visit 39 http://www.dmtf.org/about/policies/disclosures.php. 40 2 DMTF Standard Version 1.0.0 DSP0219 UML Profile for CIM 41 Contents 42 Foreword ....................................................................................................................................................... 6 43 Introduction ................................................................................................................................................... 7 44 1 Scope .................................................................................................................................................... 9 45 2 Normative References........................................................................................................................... 9 46 2.1 Approved References ................................................................................................................. 9 47 2.2 Other References........................................................................................................................ 9 48 3 Terms and Definitions ......................................................................................................................... 10 49 3.1 General Rules ........................................................................................................................... 10 50 3.2 Definitions Related to CIM Qualifier Values ............................................................................. 10 51 3.3 Other Terms and Definitions..................................................................................................... 10 52 3.4 Usage of ABNF......................................................................................................................... 11 53 4 General Definition of a UML Profile..................................................................................................... 11 54 5 Definition of the UML Profile for CIM................................................................................................... 12 55 5.1 UML Elements Used................................................................................................................. 12 56 5.2 Mapping of CIM Elements ........................................................................................................ 14 57 5.3 Mapping to UML Packages....................................................................................................... 15 58 5.4 Mapping of CIM Classes........................................................................................................... 17 59 5.5 Mapping of CIM Indications ...................................................................................................... 19 60 5.6 Mapping of CIM Associations ................................................................................................... 19 61 5.7 Mapping of CIM Properties ....................................................................................................... 20 62 5.8 Mapping of CIM References ..................................................................................................... 21 63 5.9 Mapping of CIM Methods.......................................................................................................... 22 64 5.10 Mapping of CIM Parameters and CIM Return Values .............................................................. 23 65 5.11 Mapping of CIM Datatypes ....................................................................................................... 25 66 5.12 Mapping of CIM Instances ........................................................................................................ 26 67 5.13 Mapping of CIM Qualifiers ........................................................................................................ 27 68 5.13.1 Overview ...................................................................................................................... 27 69 5.13.2 Mapping of Qualifier Types.......................................................................................... 29 70 5.13.3 Generic Mapping of Qualifier Values........................................................................... 33 71 5.13.4 Direct Mapping of Qualifier Values .............................................................................. 34 72 5.13.5 Definition of Marker Stereotypes ................................................................................. 47 73 5.13.6 Typical Use Cases for Qualifier Inheritance Mapping ................................................. 49 74 5.14 Mapping MOF File Information ................................................................................................. 50 75 5.14.1 Stereotypes Used for Mapping MOF File Information ................................................. 51 76 5.15 Stereotypes for the CIM Meta Elements................................................................................... 57 77 5.16 Other UML Metaclasses Used in the Mapping ......................................................................... 59 78 5.16.1 UML LiteralBoolean Metaclass .................................................................................... 59 79 5.16.2 UML LiteralString Metaclass........................................................................................ 59 80 5.16.3 UML LiteralInteger Metaclass ...................................................................................... 60 81 5.16.4 UML LiteralUnlimitedNatural Metaclass....................................................................... 61 82 5.16.5 UML LiteralNull Metaclass ........................................................................................... 61 83 5.16.6 UML Generalization Metaclass.................................................................................... 62 84 5.16.7 UML DataType Metaclass ........................................................................................... 63 85 5.17 Constraints................................................................................................................................63 86 5.17.1 Additional OCL Functions ............................................................................................ 64 87 5.17.2 OCL Constraints on Classes, Associations, Indications and their Instances .............. 67 88 5.17.3 OCL Constraints on Properties and References ......................................................... 70 89 5.17.4 OCL Constraints on Methods and Parameters............................................................ 75 90 5.17.5 OCL Constraints on Qualifiers..................................................................................... 77 91 5.17.6 OCL Constraints on Datatypes.................................................................................. 103 92 5.17.7 OCL Constraints for Values of Directly Mapped Qualifiers ....................................... 105 93 5.17.8 Other OCL Constraints .............................................................................................. 111 Version 1.0.0 DMTF Standard 3 UML Profile for CIM DSP0219 94 5.17.9 Other Constraints....................................................................................................... 116 95 5.17.10 Constraints Covered by UML....................................................................................
Recommended publications
  • An Optimal Control Approach for Determiniation of the Heat Loss Coefficient in an Ics Solar Domesticater W Heating System

    An Optimal Control Approach for Determiniation of the Heat Loss Coefficient in an Ics Solar Domesticater W Heating System

    University of Central Florida STARS Electronic Theses and Dissertations, 2004-2019 2010 An Optimal Control Approach For Determiniation Of The Heat Loss Coefficient In An Ics Solar Domesticater W Heating System Camilo Gil University of Central Florida Part of the Electrical and Electronics Commons Find similar works at: https://stars.library.ucf.edu/etd University of Central Florida Libraries http://library.ucf.edu This Doctoral Dissertation (Open Access) is brought to you for free and open access by STARS. It has been accepted for inclusion in Electronic Theses and Dissertations, 2004-2019 by an authorized administrator of STARS. For more information, please contact [email protected]. STARS Citation Gil, Camilo, "An Optimal Control Approach For Determiniation Of The Heat Loss Coefficient In An Ics Solar Domestic Water Heating System" (2010). Electronic Theses and Dissertations, 2004-2019. 4297. https://stars.library.ucf.edu/etd/4297 AN OPTIMAL CONTROL APPROACH FOR DETERMINATION OF THE HEAT LOSS COEFFICIENT IN AN ICS SOLAR DOMESTIC WATER HEATING SYSTEM by CAMILO GIL B.S. Pontificia Universidad Javeriana, 2001 M.S. University of New Mexico, 2005 A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Electrical and Computer Engineering in the College of Engineering and Computer Science at the University of Central Florida Orlando, Florida Summer Term 2010 Major Professor: Marwan Simaan ©2010 Camilo Gil ii ABSTRACT Water heating in a typical home in the U.S. accounts for a significant portion (between 14% and 25%) of the total home’s annual energy consumption. The objective of considerably reducing the home’s energy consumption from the utilities calls for the use of onsite renewable energy systems.
  • Objects and Classes in Python Documentation Release 0.1

    Objects and Classes in Python Documentation Release 0.1

    Objects and classes in Python Documentation Release 0.1 Jonathan Fine Sep 27, 2017 Contents 1 Decorators 2 1.1 The decorator syntax.........................................2 1.2 Bound methods............................................3 1.3 staticmethod() .........................................3 1.4 classmethod() ..........................................3 1.5 The call() decorator.......................................4 1.6 Nesting decorators..........................................4 1.7 Class decorators before Python 2.6.................................5 2 Constructing classes 6 2.1 The empty class...........................................6 3 dict_from_class() 8 3.1 The __dict__ of the empty class...................................8 3.2 Is the doc-string part of the body?..................................9 3.3 Definition of dict_from_class() ...............................9 4 property_from_class() 10 4.1 About properties........................................... 10 4.2 Definition of property_from_class() ............................ 11 4.3 Using property_from_class() ................................ 11 4.4 Unwanted keys............................................ 11 5 Deconstructing classes 13 6 type(name, bases, dict) 14 6.1 Constructing the empty class..................................... 14 6.2 Constructing any class........................................ 15 6.3 Specifying __doc__, __name__ and __module__.......................... 15 7 Subclassing int 16 7.1 Mutable and immutable types.................................... 16 7.2
  • Bi-Directional Transformation Between Normalized Systems Elements and Domain Ontologies in OWL

    Bi-Directional Transformation Between Normalized Systems Elements and Domain Ontologies in OWL

    Bi-directional Transformation between Normalized Systems Elements and Domain Ontologies in OWL Marek Suchanek´ 1 a, Herwig Mannaert2, Peter Uhnak´ 3 b and Robert Pergl1 c 1Faculty of Information Technology, Czech Technical University in Prague, Thakurova´ 9, Prague, Czech Republic 2Normalized Systems Institute, University of Antwerp, Prinsstraat 13, Antwerp, Belgium 3NSX bvba, Wetenschapspark Universiteit Antwerpen, Galileilaan 15, 2845 Niel, Belgium Keywords: Ontology, Normalized Systems, Transformation, Model-driven Development, Ontology Engineering, Software Modelling. Abstract: Knowledge representation in OWL ontologies gained a lot of popularity with the development of Big Data, Artificial Intelligence, Semantic Web, and Linked Open Data. OWL ontologies are very versatile, and there are many tools for analysis, design, documentation, and mapping. They can capture concepts and categories, their properties and relations. Normalized Systems (NS) provide a way of code generation from a model of so-called NS Elements resulting in an information system with proven evolvability. The model used in NS contains domain-specific knowledge that can be represented in an OWL ontology. This work clarifies the potential advantages of having OWL representation of the NS model, discusses the design of a bi-directional transformation between NS models and domain ontologies in OWL, and describes its implementation. It shows how the resulting ontology enables further work on the analytical level and leverages the system design. Moreover, due to the fact that NS metamodel is metacircular, the transformation can generate ontology of NS metamodel itself. It is expected that the results of this work will help with the design of larger real-world applications as well as the metamodel and that the transformation tool will be further extended with additional features which we proposed.
  • Neuron C Reference Guide Iii • Introduction to the LONWORKS Platform (078-0391-01A)

    Neuron C Reference Guide Iii • Introduction to the LONWORKS Platform (078-0391-01A)

    Neuron C Provides reference info for writing programs using the Reference Guide Neuron C programming language. 078-0140-01G Echelon, LONWORKS, LONMARK, NodeBuilder, LonTalk, Neuron, 3120, 3150, ShortStack, LonMaker, and the Echelon logo are trademarks of Echelon Corporation that may be registered in the United States and other countries. Other brand and product names are trademarks or registered trademarks of their respective holders. Neuron Chips and other OEM Products were not designed for use in equipment or systems, which involve danger to human health or safety, or a risk of property damage and Echelon assumes no responsibility or liability for use of the Neuron Chips in such applications. Parts manufactured by vendors other than Echelon and referenced in this document have been described for illustrative purposes only, and may not have been tested by Echelon. It is the responsibility of the customer to determine the suitability of these parts for each application. ECHELON MAKES AND YOU RECEIVE NO WARRANTIES OR CONDITIONS, EXPRESS, IMPLIED, STATUTORY OR IN ANY COMMUNICATION WITH YOU, AND ECHELON SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Echelon Corporation. Printed in the United States of America. Copyright © 2006, 2014 Echelon Corporation. Echelon Corporation www.echelon.com Welcome This manual describes the Neuron® C Version 2.3 programming language. It is a companion piece to the Neuron C Programmer's Guide.
  • Unified Modeling Language 2.0 Part 1 - Introduction

    Unified Modeling Language 2.0 Part 1 - Introduction

    UML 2.0 – Tutorial (v4) 1 Unified Modeling Language 2.0 Part 1 - Introduction Prof. Dr. Harald Störrle Dr. Alexander Knapp University of Innsbruck University of Munich mgm technology partners (c) 2005-2006, Dr. H. Störrle, Dr. A. Knapp UML 2.0 – Tutorial (v4) 2 1 - Introduction History and Predecessors • The UML is the “lingua franca” of software engineering. • It subsumes, integrates and consolidates most predecessors. • Through the network effect, UML has a much broader spread and much better support (tools, books, trainings etc.) than other notations. • The transition from UML 1.x to UML 2.0 has – resolved a great number of issues; – introduced many new concepts and notations (often feebly defined); – overhauled and improved the internal structure completely. • While UML 2.0 still has many problems, current version (“the standard”) it is much better than what we ever had formal/05-07-04 of August ‘05 before. (c) 2005-2006, Dr. H. Störrle, Dr. A. Knapp UML 2.0 – Tutorial (v4) 3 1 - Introduction Usage Scenarios • UML has not been designed for specific, limited usages. • There is currently no consensus on the role of the UML: – Some see UML only as tool for sketching class diagrams representing Java programs. – Some believe that UML is “the prototype of the next generation of programming languages”. • UML is a really a system of languages (“notations”, “diagram types”) each of which may be used in a number of different situations. • UML is applicable for a multitude of purposes, during all phases of the software lifecycle, and for all sizes of systems - to varying degrees.
  • Csci 658-01: Software Language Engineering Python 3 Reflexive

    Csci 658-01: Software Language Engineering Python 3 Reflexive

    CSci 658-01: Software Language Engineering Python 3 Reflexive Metaprogramming Chapter 3 H. Conrad Cunningham 4 May 2018 Contents 3 Decorators and Metaclasses 2 3.1 Basic Function-Level Debugging . .2 3.1.1 Motivating example . .2 3.1.2 Abstraction Principle, staying DRY . .3 3.1.3 Function decorators . .3 3.1.4 Constructing a debug decorator . .4 3.1.5 Using the debug decorator . .6 3.1.6 Case study review . .7 3.1.7 Variations . .7 3.1.7.1 Logging . .7 3.1.7.2 Optional disable . .8 3.2 Extended Function-Level Debugging . .8 3.2.1 Motivating example . .8 3.2.2 Decorators with arguments . .9 3.2.3 Prefix decorator . .9 3.2.4 Reformulated prefix decorator . 10 3.3 Class-Level Debugging . 12 3.3.1 Motivating example . 12 3.3.2 Class-level debugger . 12 3.3.3 Variation: Attribute access debugging . 14 3.4 Class Hierarchy Debugging . 16 3.4.1 Motivating example . 16 3.4.2 Review of objects and types . 17 3.4.3 Class definition process . 18 3.4.4 Changing the metaclass . 20 3.4.5 Debugging using a metaclass . 21 3.4.6 Why metaclasses? . 22 3.5 Chapter Summary . 23 1 3.6 Exercises . 23 3.7 Acknowledgements . 23 3.8 References . 24 3.9 Terms and Concepts . 24 Copyright (C) 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Note: This chapter adapts David Beazley’s debugly example presentation from his Python 3 Metaprogramming tutorial at PyCon’2013 [Beazley 2013a].
  • The Use of UML for Software Requirements Expression and Management

    The Use of UML for Software Requirements Expression and Management

    The Use of UML for Software Requirements Expression and Management Alex Murray Ken Clark Jet Propulsion Laboratory Jet Propulsion Laboratory California Institute of Technology California Institute of Technology Pasadena, CA 91109 Pasadena, CA 91109 818-354-0111 818-393-6258 [email protected] [email protected] Abstract— It is common practice to write English-language 1. INTRODUCTION ”shall” statements to embody detailed software requirements in aerospace software applications. This paper explores the This work is being performed as part of the engineering of use of the UML language as a replacement for the English the flight software for the Laser Ranging Interferometer (LRI) language for this purpose. Among the advantages offered by the of the Gravity Recovery and Climate Experiment (GRACE) Unified Modeling Language (UML) is a high degree of clarity Follow-On (F-O) mission. However, rather than use the real and precision in the expression of domain concepts as well as project’s model to illustrate our approach in this paper, we architecture and design. Can this quality of UML be exploited have developed a separate, ”toy” model for use here, because for the definition of software requirements? this makes it easier to avoid getting bogged down in project details, and instead to focus on the technical approach to While expressing logical behavior, interface characteristics, requirements expression and management that is the subject timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achiev- of this paper. ing the additional aspects of the expression and management of software requirements that stakeholders expect, especially There is one exception to this choice: we will describe our traceability, is far less so.
  • Metaclasses: Generative C++

    Metaclasses: Generative C++

    Metaclasses: Generative C++ Document Number: P0707 R3 Date: 2018-02-11 Reply-to: Herb Sutter ([email protected]) Audience: SG7, EWG Contents 1 Overview .............................................................................................................................................................2 2 Language: Metaclasses .......................................................................................................................................7 3 Library: Example metaclasses .......................................................................................................................... 18 4 Applying metaclasses: Qt moc and C++/WinRT .............................................................................................. 35 5 Alternatives for sourcedefinition transform syntax .................................................................................... 41 6 Alternatives for applying the transform .......................................................................................................... 43 7 FAQs ................................................................................................................................................................. 46 8 Revision history ............................................................................................................................................... 51 Major changes in R3: Switched to function-style declaration syntax per SG7 direction in Albuquerque (old: $class M new: constexpr void M(meta::type target,
  • Meta-Class Features for Large-Scale Object Categorization on a Budget

    Meta-Class Features for Large-Scale Object Categorization on a Budget

    Meta-Class Features for Large-Scale Object Categorization on a Budget Alessandro Bergamo Lorenzo Torresani Dartmouth College Hanover, NH, U.S.A. faleb, [email protected] Abstract cation accuracy over a predefined set of classes, and without consideration of the computational costs of the recognition. In this paper we introduce a novel image descriptor en- We believe that these two assumptions do not meet the abling accurate object categorization even with linear mod- requirements of modern applications of large-scale object els. Akin to the popular attribute descriptors, our feature categorization. For example, test-recognition efficiency is a vector comprises the outputs of a set of classifiers evaluated fundamental requirement to be able to scale object classi- on the image. However, unlike traditional attributes which fication to Web photo repositories, such as Flickr, which represent hand-selected object classes and predefined vi- are growing at rates of several millions new photos per sual properties, our features are learned automatically and day. Furthermore, while a fixed set of object classifiers can correspond to “abstract” categories, which we name meta- be used to annotate pictures with a set of predefined tags, classes. Each meta-class is a super-category obtained by the interactive nature of searching and browsing large im- grouping a set of object classes such that, collectively, they age collections calls for the ability to allow users to define are easy to distinguish from other sets of categories. By us- their own personal query categories to be recognized and ing “learnability” of the meta-classes as criterion for fea- retrieved from the database, ideally in real-time.
  • Navigation Techniques in Augmented and Mixed Reality: Crossing the Virtuality Continuum

    Navigation Techniques in Augmented and Mixed Reality: Crossing the Virtuality Continuum

    Chapter 20 NAVIGATION TECHNIQUES IN AUGMENTED AND MIXED REALITY: CROSSING THE VIRTUALITY CONTINUUM Raphael Grasset 1,2, Alessandro Mulloni 2, Mark Billinghurst 1 and Dieter Schmalstieg 2 1 HIT Lab NZ University of Canterbury, New Zealand 2 Institute for Computer Graphics and Vision Graz University of Technology, Austria 1. Introduction Exploring and surveying the world has been an important goal of humankind for thousands of years. Entering the 21st century, the Earth has almost been fully digitally mapped. Widespread deployment of GIS (Geographic Information Systems) technology and a tremendous increase of both satellite and street-level mapping over the last decade enables the public to view large portions of the 1 2 world using computer applications such as Bing Maps or Google Earth . Mobile context-aware applications further enhance the exploration of spatial information, as users have now access to it while on the move. These applications can present a view of the spatial information that is personalised to the user’s current context (context-aware), such as their physical location and personal interests. For example, a person visiting an unknown city can open a map application on her smartphone to instantly obtain a view of the surrounding points of interest. Augmented Reality (AR) is one increasingly popular technology that supports the exploration of spatial information. AR merges virtual and real spaces and offers new tools for exploring and navigating through space [1]. AR navigation aims to enhance navigation in the real world or to provide techniques for viewpoint control for other tasks within an AR system. AR navigation can be naively thought to have a high degree of similarity with real world navigation.
  • Sysml Distilled: a Brief Guide to the Systems Modeling Language

    Sysml Distilled: a Brief Guide to the Systems Modeling Language

    ptg11539604 Praise for SysML Distilled “In keeping with the outstanding tradition of Addison-Wesley’s techni- cal publications, Lenny Delligatti’s SysML Distilled does not disappoint. Lenny has done a masterful job of capturing the spirit of OMG SysML as a practical, standards-based modeling language to help systems engi- neers address growing system complexity. This book is loaded with matter-of-fact insights, starting with basic MBSE concepts to distin- guishing the subtle differences between use cases and scenarios to illu- mination on namespaces and SysML packages, and even speaks to some of the more esoteric SysML semantics such as token flows.” — Jeff Estefan, Principal Engineer, NASA’s Jet Propulsion Laboratory “The power of a modeling language, such as SysML, is that it facilitates communication not only within systems engineering but across disci- plines and across the development life cycle. Many languages have the ptg11539604 potential to increase communication, but without an effective guide, they can fall short of that objective. In SysML Distilled, Lenny Delligatti combines just the right amount of technology with a common-sense approach to utilizing SysML toward achieving that communication. Having worked in systems and software engineering across many do- mains for the last 30 years, and having taught computer languages, UML, and SysML to many organizations and within the college setting, I find Lenny’s book an invaluable resource. He presents the concepts clearly and provides useful and pragmatic examples to get you off the ground quickly and enables you to be an effective modeler.” — Thomas W. Fargnoli, Lead Member of the Engineering Staff, Lockheed Martin “This book provides an excellent introduction to SysML.
  • Ontojit: Parsing Native OWL DL Into Executable Ontologies in an Object Oriented Paradigm

    Ontojit: Parsing Native OWL DL Into Executable Ontologies in an Object Oriented Paradigm

    OntoJIT: Parsing Native OWL DL into Executable Ontologies in an Object Oriented Paradigm Sohaila Baset and Kilian Stoffel Information Management Institute University of Neuchatel, Neuchatel, Switzerland [email protected], [email protected] Abstract. Despite meriting the growing consensus between researchers and practitioners of ontology modeling, the Web Ontology Language OWL still has a modest presence in the communities of "traditional" web developers and software engineers. This resulted in hoarding the se- mantic web field in a rather small circle of people with a certain profile of expertise. In this paper we present OntoJIT, our novel approach to- ward a democratized semantic web where we bring OWL ontologies into the comfort-zone of end-application developers. We focus particularly on parsing OWL source files into executable ontologies in an object oriented programming paradigm. We finally demonstrate the dynamic code-base created as the result of parsing some reference OWL DL ontologies. Keywords: Ontologies, OWL, Semantic Web, Meta Programming,Dynamic Compilation 1 Background and Motivation With a stack full of recognized standards and specifications, the Web Ontology Language OWL has made long strides to allocate itself a distinctive spot in the landscape of knowledge representation and semantic web. Obviously, OWL is not the only player in the scene; over the couple of last decades many other languages have also emerged in the ontology modeling paradigm. Most of these languages are logic-based formalisms with underlying constructs in first order logic [5][7][8][11] or in one of the description logic fragments like OWL itself [3][4] and its predecessor DAML+OIL [10].