DOCSLIB.ORG

The Feasibility of Measuring the Stability of Data Models

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Feasibility of Measuring the Stability of Data Models MODELS OF INFORMATION: THE FEASIBILITY OF MEASURING THE STABILITY OF DATA MODELS Myron Murray Marche London School of Economics and Political Science Submitted in fulfilment of the requirements for the award of the degree of Doctor of Philosophy of the University of London LONDON, ENGLAND SUMMER, 1991 UMI Number: U061829 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. Dissertation Publishing UMI U061829 Published by ProQuest LLC 2014. Copyright in the Dissertation held by the Author. Microform Edition © ProQuest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code. ProQuest LLC 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106-1346 ABSTRACT The theory of data modelling makes a variety of claims about schema stability. This research determined the current state of data modelling practice, and tested hypotheses related to measuring model stability. The research developed a method whereby the major elements of a data model can be consistently represented whatever process was originally used for modelling. This was achieved through a construction of a logical relational schema from the record design. The construction/reconstruction process attempted to identify the primary meaning primitives of a data model in order to track changes to them in different iterations of the application. The stability data collection process was applied to a case study followed by a series of models to generate further data. The early evidence indicated that data model instability has it roots in errors in modelling, errors in the semantic analysis whether done consciously or intuitively, and in changes to the requirements brought on by changes to the "reality". This research suggested that some of the elements of a data model are significantly more important than others. The research documented problems associated with the transformation of natural language into the constraints of data dictionaries. This exploration into the potential application of linguistic research into systems theory and practice identified a number of theoretically interesting problems, such as variable semantic determination. The discussion outlined some specific techniques an analyst can use to improve the process of semantic analysis. The work suggested that there should be greater concentration on the question of data model evolvability, and the appropriate preservation of meaning across model versions, and not necessarily on data model stability. To Michael, Stephen, and Janet ACKNOWLEDGEMENTS While there is only one name on the title page of this work, there can be no question that it exists only due to the effort of many people. I must first acknowledge the original support of Professor Ronald Stamper, who encouraged me to begin studies at the London School of Economics, and who was willing to let his students think in very broadest of terms. While beginnings are very important, endings are just as important, and often substantially more difficult. Coming to the end of the research was in no small measure due to the efforts of Dr Jonathan Liebenau who provided effective supervision over most of the life of this research, and this he did with sensitivity, unfailing good humour, and good grace. All systems professionals appreciate the importance of strong project management. I must thank the project manager for the data collection phase of this work, Mr. Ian Cameron, who in his typical fashion did not take no for an answer. The encouragement and confidence of many friends, clients, and business associates is also gratefully acknowledged. I have invariably learned more from them than they have from me. My colleagues and friends at the London School of Economics have always made it a place for the best kind of open intellectual exploration. Thanks especially to Dr Jim Backhouse, and Professor Ian Angell. Finally, the love and support of my wife Janet, as well as the patience of my children, Michael and Stephen were instrumental in reaching this goal. Graduate schools should really award research degrees to families, not to individuals. TABLE OF CONTENTS PART I THE THEORY AND PRACTICE OF DATA MODELLING P reface....................................................................................................................... viii Chapter 1 - INTRODUCTION ................................................................................. 1 Chapter 2- THE INTELLECTUAL FOUNDATIONS OF DATA MODELLING....................................................................................... 5 A. The Roots of Data Modelling Theory ............................................... 6 B. T h e Philosophical Foundations of Data M odelling ............................................................................................ 12 1. Is Reality Subjective or is it Objective? .............................. 12 2. Semantics .................................................................................. 20 3. Schemas and Databases as Forms of Communication . 34 C. Data Modelling - Theory Into Practice ............................................ 39 Chapter 3 - A SURVEY OF DATA MODELLING PRACTICES IN CANADA ......................................................................................... 51 PART II - DEVELOPING AND APPLYING A TOOL FOR STABILITY MEASUREMENT Chapter 4 - DEVELOPING THE STABILITY MEASUREMENT TOOL . 62 A. What Do We Mean By Measurement? ............................................ 62 B. The Characteristic of Stability in a Data Model ................. •............................................................................. 64 1. The Literature is Not Specific in its References to Stability .................................................................................. 64 2. The Consequences of Instability .......................................... 69 C. The Data Model and Its Important Elements .................................. 71 1. Physical Database Design ................................................... 71 2. The Conceptual Data Model ................................................. 71 3. The Logical Data Model . ................................................. 73 4. Elements to a Data Model Which Might Be Important to Stability Measurement .................................................... 75 D. Creating the Data Collection Sheets for Model Changes 77 1. Creating the Attribute Data Collection Sheet .................... 78 2. Creating the Entity Data Collection Sheet ......................... 80 3. Creating the Relationship Data Sheet .................................. 81 4. Creating the Background and Model Summary Data Collection Sheet ................................................................... 82 TABLE OF CONTENTS (continued) Chapter 5 - A CASE STUDY OF THE TOOL IN U S E ...................................... 85 A. Introduction to the Case Study ............................................... 85 B. The Distribution of Office Space System ....................................... 86 C. The Space Recording and Control System (1) - October 1988 . 92 D. The Space Recording and Control System (2) - August, 1989 . 99 E. Analysis of the Case Study Results ........................................ 104 Chapter 6 - THE RESULTS OF THE SUMMARISED CASES ....................... 107 A. A Quantitative Assessment of the Models and Their Changes . 108 B. Qualitative C om m ents .............................................................. 115 C. Judging And Assessing the Performance of the Measurement Process ............................................................................................ 117 1. Summarising the Stability Measurement Process 117 2. Applying the Criteria of Measurement Effectiveness .. 119 PART III - TOWARDS A CRITICAL THEORY OF DATA MODELLING Chapter 7 - DATA MODELLING STABILITY, INSTABILITY, AND EVOLV ABILITY ............................................................... 123 A. General Observations From Applying the Measurement P rotocol ................................................................................ 124 B. Why Do Models Appear Stable at All? ...................................... 127 C. Stability Versus Evolvability in Data M odels ................. 131 Chapter 8- DATA MODELLING THEORY, PRACTICE, AND PROSPECTS .................................................................................. 135 A. Data Modelling - An Example of How It Is Practised .............. 135 1. An Initial Definition of Building Was Prepared ............ 139 2. Testing the Idea of Building, and Its Attributes 141 B. Learning From The Problems Of Data Modelling ......... 145 C. Hermeneutics And Semantic Analysis - Coming to the Meaning of T h in g s .............................................................................. 150 1. Hermeneutics - The Process of Interpretation ................. 151 2. The Prospects for Extending Semantic Analysis and Data Modelling ................................................................... 155 TABLE OF CONTENTS (continued) Chapter 9 - CONCLUSIONS AND FURTHER RESEARCH CONSIDERATIONS......................................................................... 165 A. General Summary of the Research ...................................... 165 B. Other Research
Load more

Recommended publications
  • PML, an Object Oriented Process Modelling Language
    PML, an Object Oriented Process Modeling Language Prof. Dr.-Ing. Reiner Anderl 1, and Dipl.-Ing. Jochen Raßler 2 1 Prof. Dr.-Ing. Reiner Anderl, Germany, [email protected] 2 Dipl.-Ing. Jochen Raßler, Germany, [email protected] Abstract: Processes are very important for the success within many business fields. They define the proper application of methods, technologies, tools and company structures in order to reach business goals. Important processes to be defined are manufacturing processes or product development processes for example to guarantee the company’s success. Over the last decades many process modeling languages have been developed to cover the needs of process modeling. Those modeling languages have several limitations, mainly they are still procedural and didn’t follow the paradigm change to object oriented modeling and thus often lead to process models, which are difficult to maintain. In previous papers we have introduced PML, Process Modeling Language, and shown it’s usage in process modeling. PML is derived from UML and hence fully object oriented and uses modern modeling techniques. It is based on process class diagrams that describe methods and resources for process modeling. In this paper the modeling language is described in more detail and new language elements will be introduced to develop the language to a generic usable process modeling language. Keywords: process modeling language, PML, UML 1. Introduction As the tendency of enterprises to collaborate growths steadily, industry faces new challenges managing business processes, product development processes, manufacturing processes and much more. Furthermore, discipline spanning product development processes are increasing, e.
    [Show full text]
  • Extending and Evaluating the Model-Based Product Definition
    NIST GCR 18-015 Extending and Evaluating the Model-based Product Definition Nathan W. Hartman Jesse Zahner Purdue University This publication is available free of charge from: https://doi.org/10.6028/NIST.GCR.18-015 NIST GCR 18-015 Extending and Evaluating the Model-based Product Definition Prepared for Thomas D. Hedberg, Jr. Allison Barnard Feeney U.S. Department of Commerce Engineering Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8260 By Nathan W. Hartman Jesse Zahner PLM Center of Excellence Purdue University This publication is available free of charge from: https://doi.org/10.6028/NIST.GCR.18-015 December 2017 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Undersecretary of Commerce for Standards and Technology Disclaimer Any opinions, findings, conclusions, or recommendations expressed in this publication do not necessarily reflect the views of the National Institute of Standards and Technology (NIST). Additionally, neither NIST nor any of its employees make any warranty, expressed or implied, nor assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process included in this publication. The report was prepared under cooperative agreement 70NANB15H311 between the National Institute of Standards and Technology and Purdue University. The statements and conclusions contained in this report are those of the authors and do not imply recommendations or endorsements by the National Institute of Standards and Technology. Certain commercial systems are identified in this report. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology.
    [Show full text]
  • DCSA Information Model 3.0
    DCSA Information Model 3.0 December 2020 Table of contents Version history __________________________________________________ 8 1 Introduction __________________________________________________ 9 1.1 Preface ______________________________________________________ 9 1.2 Purpose ______________________________________________________ 9 1.3 Overview _____________________________________________________ 10 1.4 Conformance __________________________________________________ 10 1.5 Supporting publications ___________________________________________ 10 2 DCSA Information Model 3.0 ________________________________________ 13 2.1 Introduction ___________________________________________________ 13 2.2 Selected data modelling terms defined _________________________________ 14 2.3 The DCSA Information Model data types and formats ________________________ 15 2.3.1 Attribute naming conventions ____________________________________ 16 3 Logical Data Model ____________________________________________ 18 4 Logical Data Model usage ________________________________________ 20 4.1 Track and trace (T&T) ____________________________________________ 20 4.2 Operational vessel schedules (OVS) ___________________________________ 21 4.3 eDocumentation _______________________________________________ 23 5 Subject areas in the Logical Data Model _______________________________ 25 5.1 Shipment ____________________________________________________ 26 5.1.1 Shipment reference data _______________________________________ 31 5.2 Transport Document _____________________________________________
    [Show full text]
  • Metamodelling for MDA
    Metamodelling for MDA First International Workshop York, UK, November 2003 Proceedings Edited by Andy Evans Paul Sammut James S. Willans Table of Contents Preface ........................................................ 4 Principles Calling a Spade a Spade in the MDA Infrastructure ................... 9 Colin Atkinson and Thomas K¨uhne Do MDA Transformations Preserve Meaning? An investigation into preservingsemantics ........................................... 13 Anneke Kleppe and Jos Warmer MDA components: Challenges and Opportunities ..................... 23 Jean B´ezivin, S´ebastien G´erard, Pierre-Alain Muller and Laurent Rioux SafetyChallengesforModelDrivenDevelopment ..................... 42 N. Audsley, P. M. Conmy, S. K. Crook-Dawkins and R. Hawkins Invited talk: UML2 - a language for MDA (putting the U, M and L intoUML)?................................................... 61 Alan Moore Languages and Applications Using an MDA approach to model traceability within a modelling framework .................................................... 62 John Dalton, Peter W Norman, Steve Whittle, and T Eshan Rajabally Services integration by models annotation and transformation .......... 77 Olivier Nano and Mireille Blay-Fornarino 1 A Metamodel of Prototypical Instances .............................. 93 Andy Evans, Girish Maskeri, Alan Moore Paul Sammut and James S. Willans Metamodelling of Transaction Configurations ......................... 106 StenLoecherandHeinrichHussmann Invitedtalk:MarketingtheMDAToolChain......................... 109 Stephen
    [Show full text]
  • Patterns: Model-Driven Development Using IBM Rational Software Architect
    Front cover Patterns: Model-Driven Development Using IBM Rational Software Architect Learn how to automate pattern-driven development Build a model-driven development framework Follow a service-oriented architecture case study Peter Swithinbank Mandy Chessell Tracy Gardner Catherine Griffin Jessica Man Helen Wylie Larry Yusuf ibm.com/redbooks International Technical Support Organization Patterns: Model-Driven Development Using IBM Rational Software Architect December 2005 SG24-7105-00 Note: Before using this information and the product it supports, read the information in “Notices” on page ix. First Edition (December 2005) This edition applies to Version 6.0.0.1 of Rational Software Architect (product number 5724-I70). © Copyright International Business Machines Corporation 2005. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . ix Trademarks . x Preface . xi For solution architects . xi For project planners or project managers . xii For those working on a project that uses model-driven development . xii How this book is organized . xiii The team that wrote this redbook. xiv Become a published author . xv Comments welcome. xvi Part 1. Approach . 1 Chapter 1. Overview and concepts of model-driven development. 3 1.1 Current business environment and drivers . 4 1.2 A model-driven approach to software development . 5 1.2.1 Models as sketches and blueprints . 6 1.2.2 Precise models enable automation . 6 1.2.3 The role of patterns in model-driven development . 7 1.2.4 Not just code . 7 1.3 Benefits of model-driven development .
    [Show full text]
  • Aircraft Systems Modeling
    Aircraft Systems Modeling Model Based Systems Engineering in Avionics Design and Aircraft Simulation ii Linköping Studies in Science and Technology Thesis No. 1394 Aircraft Systems Modeling Model Based Systems Engineering in Avionics Design and Aircraft Simulation Henric Andersson Department of Management and Engineering Division of Machine Design Linköpings universitet SE-581 83 Linköping, Sweden Linköping 2009 iii Aircraft Systems Modeling Model Based Systems Engineering in Avionics Design and Aircraft Simulation LIU-TEK-LIC-2009:2 ISBN 978-91-7393-692-7 ISSN 0280-7971 Copyright © March 2009 by Henric Andersson [email protected] www.iei.liu.se/machine Division of Machine Design Department of Management and Engineering Linköpings universitet SE-581 83 Linköping, Sweden Printed in Sweden by LiU-Tryck, Linköping, 2009 iv Abstract AIRCRAFT DEVELOPERS, like other development and manufacturing companies, are experiencing increasing complexity in their products and growing competition in the global market. One way to confront the challenges is to make the development process more efficient and to shorten time to market for new products/variants by using design and development methods based on models. Model Based Systems Engineering (MBSE) is introduced to, in a structured way, support engineers with aids and rules in order to engineer systems in a new way. In this thesis, model based strategies for aircraft and avionics development are stud- ied. A background to avionics architectures and in particular Integrated Modular Avion- ics is described. The integrating discipline Systems Engineering, MBSE and applicable standards are also described. A survey on available and emerging modeling techniques and tools, such as Hosted Simulation, is presented and Modeling Domains are defined in order to analyze the engineering environment with all its vital parts to support an MBSE approach.
    [Show full text]
  • Information Models, Data Models, and YANG
    Information Models, Data Models, and YANG J¨urgenSch¨onw¨alder IETF 86, Orlando, 2013-03-14 1 / 12 Information Models (RFC 3444) B Information Models are used to model managed objects at a conceptual level, independent of any specific protocols used to transport the data (protocol agnostic). B The degree of specificity (or detail) of the abstractions defined in the information model depends on the modeling needs of its designers. B In order to make the overall design as clear as possible, information models should hide protocol and implementation details. B Information models focus on relationships between managed objects. B Information models are often represented in Unified Modeling Language (class) diagrams, but there are also informal information models written in plain English language. 2 / 12 Data Models (RFC 3444) B Data Models are defined at a lower level of abstraction and include many details (compared to information models). B They are intended for implementors and include implementation- and protocol-specific constructs. B Data models are often represented in formal data definition languages that are specific to the management protocol being used. 3 / 12 Information Models vs. Data Models IM conceptual/abstract model for designers and operators DM DM DM concrete/detailed model for implementors B Since conceptual models can be implemented in different ways, multiple data models can be derived from a single Information Model. B Although information models and data models serve different purposes, it is not always easy to decide which detail belongs to an information model and which belongs to a data model. B Similarily, it is sometimes difficult to determine whether an abstraction belongs to an information model or a data model.
    [Show full text]
  • A Comparative Analysis of Entity-Relationship Diagrams1
    Journal of Computer and Software Engineering, Vol. 3, No.4 (1995), pp. 427-459 A Comparative Analysis of Entity-Relationship Diagrams1 Il-Yeol Song Drexel University Mary Evans USConnect E.K. Park U.S. Naval Academy The purpose of this article is to collect widely used entity-relationship diagram (ERD) notations and so their features can be easily compared, understood, and converted from one notation to another. We collected ten different ERD notations from text books and CASE tools. Each notation is depicted using a common problem and includes a discussion of each characteristic and notation. According to our investigation, we have found that ERD features and notations are different in seven features: whether they allow n-ary relationships, whether they allow attributes in a relationship, how they represent cardinality and participation constraints, the place where they specify constraints, whether they depict overlapping and disjoint subclass entity-types, whether they show total/partial specialization, and whether they model the foreign key at the ERD level. We conclude that many of the ER diagrams we studied are different in how they depict the criteria listed above. In order to convert one diagram to another, some notations must be extended and carefully converted from one notation into another. We also discuss the limitations of existing CASE tools in terms of modeling capabilities and supporting diagrams. Keywords: Entity-Relationship Diagrams, ERD, design, modeling, CASE 1Correspondence should be addressed to Il-Yeol Song, College of Information Science and Technology, Drexel University, 32nd and Chestnut Streets, Philadelphia, PA 19104. Email: [email protected] 1 Journal of Computer and Software Engineering, Vol.
    [Show full text]
  • An Overview of UML 2.0 (And MDA)
    ® IBM Software Group An Overview of UML 2.0 (and MDA) Bran Selic [email protected] IMPORTANT DISCLAIMER! The technical material described here is still under development and is subject to modification prior to full adoption by the Object Management Group 2 IBM Software Group | 1 Tutorial Objectives 1. To introduce the major new features of UML 2.0 2. To explain the design intent and rationale behind UML 2.0 3. To describe the essence of model-driven development (as realized with UML 2.0) 3 IBM Software Group | Tutorial Overview Introduction: Modeling and Dynamic Semantics Software Interaction Modeling Model-Driven Development Capabilities A Critique of UML 1.x Activities and Actions Requirements for UML 2.0 State Machine Innovations Foundations of UML 2.0 Other New Features Architectural Modeling Summary and Conclusion Capabilities 4 IBM Software Group | 2 A Skeptic’s View of Software Models… PH reached X start Monitor Control ble Current PH PH ena PH ble stop disa Raise PH Input valve control “…bubbles and arrows, as opposed to programs, …never crash” -- B. Meyer “UML: The Positive Spin” American Programmer, 1997 5 IBM Software Group | The Problem with Bubbles… PH reached X start Monitor Control ble Current PH PH ena PH ble stop disa Raise PH Input valve control ? main () { BitVector typeFlags (maxBits); char buf [1024]; cout << msg; while (cin >> buf) { if ... 6 IBM Software Group | 3 Models in Traditional Engineering As old as engineering (e.g., Vitruvius) Traditional means of reducing engineering risk 7 IBM Software Group | What Engineers Do Before they build the real thing..
    [Show full text]
  • PLM Industry Summary Jillian Hayes, Editor Vol
    PLM Industry Summary Jillian Hayes, Editor Vol. 15 No 23 Friday 7 June 2013 Contents CIMdata News _____________________________________________________________________ 2 CIMdata Publishes “Focus on Innovation”____________________________________________________2 Optimizing Data Migration and PLM Consolidation: a CIMdata Commentary________________________3 Company News _____________________________________________________________________ 8 Advanced Solutions Awarded Bronze Technical Certification in Autodesk Simulation CFD ____________8 Altair Finalizes Global Partnership with Fujitsu _______________________________________________8 Bentley Issues 2013 Be Inspired Awards Call for Submissions ___________________________________10 Ideate, Inc. Earns Autodesk Civil Infrastructure Specialization ___________________________________11 ITC Infotech Successfully Completes Campus Connect Initiative for PLM Practice __________________12 Lectra Signs a Partnership Contract with Italian Fashion School Polimoda _________________________13 MathWorks to Sponsor RoboCup 2013 _____________________________________________________13 ModernTech Partners with Altium to Provide Electronics Design Software _________________________15 TracePartsOnline.net 3D CAD Library Reaches Out 1.5 Million Users ____________________________15 Events News ______________________________________________________________________ 16 Autodesk to Webcast Its Annual Meeting of Stockholders ______________________________________16 AVEVA and Capgemini Present at Ventyx World 2013 ________________________________________16
    [Show full text]
  • Oracle® SQL Developer Data Modeler User's Guide
    Oracle® SQL Developer Data Modeler User's Guide Release 17.3 E90546-01 September 2017 Oracle SQL Developer Data Modeler User's Guide, Release 17.3 E90546-01 Copyright © 2008, 2017, Oracle and/or its affiliates. All rights reserved. Primary Author: Celin Cherian Contributing Authors: Chuck Murray Contributors: Philip Stoyanov This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency- specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
    [Show full text]
  • Systems Modeling Language (Sysml) Specification
    Date: 03 April 2006 Systems Modeling Language (SysML) Specification OMG document: ad/2006-03-01 version 1.0 DRAFT SysML Merge Team American Systems Corporation ARTISAN Software Tools* BAE SYSTEMS The Boeing Company Deere & Company EADS Astrium GmbH EmbeddedPlus Engineering Eurostep Group AB Gentleware AG Georgia Institute of Technology I-Logix* International Business Machines* Lockheed Martin Corporation Mentor Graphics* Motorola, Inc.* National Insitute of Standards and Technology Northrop Grumman Corporation oose Innovative Informatik GmbH PivotPoint Technology Corporation Raytheon Company Sparx Systems Telelogic AB* THALES* Vitech Corporation * Submitter to OMG UML for Systems Engineering RFP SysML Specification v1.0 Draft 1 COPYRIGHT NOTICE © 2003-2006 American Systems Corporation © 2003-2006 ARTISAN Software Tools © 2003-2006 BAE SYSTEMS © 2003-2006 The Boeing Company © 2003-2006 Ceira Technologies © 2003-2006 Deere & Company © 2003-2006 EADS Astrium GmbH © 2003-2006 EmbeddedPlus Engineering © 2003-2006 Eurostep Group AB © 2003-2006 Gentleware AG © 2003-2006 I-Logix, Inc. © 2003-2006 International Business Machines © 2003-2006 International Council on Systems Engineering © 2003-2006 Israel Aircraft Industries © 2003-2006 Lockheed Martin Corporation © 2003-2006 Mentor Graphics © 2003-2006 Motorola, Inc. © 2003-2006 National Insitute of Standards and Technology © 2003-2006 Northrop Grumman © 2003-2006 oose Innovative Informatik GmbH © 2003-2006 PivotPoint Technology Corporation © 2003-2006 Raytheon Company © 2003-2006 Sparx Systems © 2003-2006 Telelogic AB © 2003-2006 THALES USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES This document describes a proposed language specification developed by an informal partnership of vendors and users, with input from additional reviewers and contributors. This document does not represent a commitment to implement any portion of this specification in any company’s products.
    [Show full text]