Unified OMG Modeling Language Specification
March 2003 Version 1.5 formal/03-03-01
An Adopted Formal Specification of the Object Management Group, Inc.
Copyright 2000-2002 Alcatel Copyright 1997-2001 Computer Associates International Inc. Copyright 1997-2001 Electronic Data Systems Corporation Copyright 1997-2001 Hewlett-Packard Company Copyright 1997-2001 IBM Corporation Copyright 1997-2002, I-Logix Copyright 1997-2001 IntelliCorp Copyright 2000-2002 Kabira Technologies Copyright 2000-2002 Kennedy Carter Copyright 1997-2001 Microsoft Corporation Copyright 1997-2001 Object Management Group Copyright 1997-2001 Oracle Corporation Copyright 2000-2002 Project Technology Copyright 1997-2001 Ptech Inc. Copyright 1997-2001 Rational Software Corporation Copyright 1997-2001 Reich Technologies Copyright 1997-2001 Softeam Copyright 1997-2001 Taskon A/S Copyright 2000-2002 Telelogic Copyright 1997-2001 Unisys Corporation
USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice. LICENSES 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. Each of the copyright holders listed above has 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. Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control. PATENTS The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be
required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. GENERAL USE RESTRICTIONS Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein 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. DISCLAIMER OF WARRANTY WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification.
RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 250 First Avenue, Needham, MA 02494, U.S.A.
TRADEMARKS The OMG Object Management Group Logo, CORBA, CORBA Academy, The Information Brokerage, XMI and IIOP are registered trademarks of the Object Management Group. OMG, Object Management Group, CORBA logos, OMG Interface Definition Language (IDL), The Architecture of Choice for a Changing World, CORBAservices, CORBAfacilities, CORBAmed, CORBAnet, Integrate 2002, Middleware That's Everywhere, UML, Unified Modeling Language, The UML Cube logo, MOF, CWM, The CWM Logo, Model Driven Architecture, Model Driven Architecture Logos, MDA, OMG Model Driven Architecture, OMG MDA and the XMI Logo are trademarks of the Object Management Group. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners.
COMPLIANCE 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. Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites.
ISSUE REPORTING All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page http://www.omg.org, under Documents & Specifications, Report a Bug/Issue.
Contents
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v xxv
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii 1 UML Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Primary Artifacts of the UML . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 UML-defining Artifacts . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Development Project Artifacts. . . . . . . . . . . . . . . . . Motivation to Define the UML . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Why We Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Industry Trends in Software . . . . . . . . . . . . . . . . . . 1.3.3 Prior to Industry Convergence . . . . . . . . . . . . . . . . . Goals of the UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scope of the UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Outside the Scope of the UML . . . . . . . . . . . . . . . . 1.5.2 Comparing UML to Other Modeling Languages . . . 1.5.3 Features of the UML . . . . . . . . . . . . . . . . . . . . . . . . UML - Past, Present, and Future . . . . . . . . . . . . . . . . . . . . . . 1.6.1 UML 0.8 - 0.91 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2 UML Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.3 UML - Present and Future . . . . . . . . . . . . . . . . . . . .
1-1
1-1 1-2 1-2 1-2 1-3 1-3 1-3 1-4 1-4 1-6 1-7 1-8 1-9 1-11 1-11 1-12 1-13
1.3
1.4 1.5
1.6
2
UML Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 1 - Background
2-1
March 2003
OMG-Unified Modeling Language, v1.5
v
2.1
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Purpose and Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Language Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Four-layer Metamodel Architecture . . . . . . . . . . . . 2.2.2 Package Structure . . . . . . . . . . . . . . . . . . . . . . . . . .
2-2 2-2 2-3 2-4 2-4 2-6
2.2
2.3
Language Formalism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7 2.3.1 Levels of Formalism . . . . . . . . . . . . . . . . . . . . . . . . 2-8 2.3.2 Package Specification Structure . . . . . . . . . . . . . . . 2-9 2.3.3 Use of a Constraint Language . . . . . . . . . . . . . . . . . 2-10 2.3.4 Use of Natural Language. . . . . . . . . . . . . . . . . . . . . 2-10 2.3.5 Naming Conventions and Typography . . . . . . . . . . . 2-11 Foundation Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2.5.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . Extension Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2.6.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 2-12 2-12 2-51 2-64 2-73 2-73 2-75 2-80 2-82 2-83
Part 2 - Foundation
2.4 2.5
2.6
2.7
Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85 2.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85 2.7.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85 Behavioral Elements Package . . . . . . . . . . . . . . . . . . . . . . . . . 2-92 Common Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2.9.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2-93 2-93 2-94 2-103 2-109 2-111 2-111 2-113 2-119
Part 3 - Behavioral Elements
2.8 2.9
2.10 Collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . .
vi
OMG-Unified Modeling Language, v1.5
March 2003
2.10.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2-124 2.10.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-129 2.11 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2.11.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2.11.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12 State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2.12.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13 Activity Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.13.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2.13.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2.13.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 4 - General Mechanisms
2-129 2-129 2-130 2-133 2-135 2-140 2-140 2-140 2-141 2-150 2-154 2-165 2-170 2-170 2-170 2-175 2-178 2-181
2.14 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-181 2.15 Model Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2.15.4 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 5 - Actions
2-181 2-181 2-182 2-186 2-192 2-198
2.16 Action Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-199 2.17 Actions Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-200 2.17.1 Action Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . 2-200 2.17.2 Design Principles and Rationale . . . . . . . . . . . . . . . 2-201 2.17.3 The Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-204 2.18 Action Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-207 2.18.1 Chapter Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 2-207 2.18.2 Description of a Class . . . . . . . . . . . . . . . . . . . . . . . 2-208 2.19 Action Foundation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-211 2.19.1 Action Specification . . . . . . . . . . . . . . . . . . . . . . . . 2-211
March 2003
OMG-Unified Modeling Language, v1.5
vii
2.19.2 Action Execution Model . . . . . . . . . . . . . . . . . . . . . 2-214 2.19.3 Action Foundation Classes . . . . . . . . . . . . . . . . . . . 2-219 2.20 Composite Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.20.1 Composite Action Specification . . . . . . . . . . . . . . . 2.20.2 Composite Action Execution . . . . . . . . . . . . . . . . . . 2.20.3 Composite Action Classes . . . . . . . . . . . . . . . . . . . . 2-228 2-228 2-234 2-239
2.21 Read and Write Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-252 2.21.1 Object Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-253 2.21.2 Attribute Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-254 2.21.3 Association Actions. . . . . . . . . . . . . . . . . . . . . . . . . 2-255 2.21.4 Variable Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-259 2.21.5 Other Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-260 2.21.6 Additional OCL Operations for Read and Write Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-261 2.21.7 Read and Write Action Classes . . . . . . . . . . . . . . . . 2-263 2.22 Computation Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-287 2.22.1 Computation actions . . . . . . . . . . . . . . . . . . . . . . . . 2-287 2.22.2 Computation Classes . . . . . . . . . . . . . . . . . . . . . . . . 2-289 2.23 Collection Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-296 2.23.1 General Rules for Collection Actions . . . . . . . . . . . 2-297 2.23.2 Collection Action Classes . . . . . . . . . . . . . . . . . . . . 2-298 2.24 Messaging Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-311 2.24.1 Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-311 2.24.2 Asynchronous Invocation . . . . . . . . . . . . . . . . . . . . 2-312 2.24.3 Synchronous invocation. . . . . . . . . . . . . . . . . . . . . . 2-313 2.24.4 Request Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 2-314 2.24.5 Reply Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-315 2.24.6 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-315 2.24.7 Performing requests. . . . . . . . . . . . . . . . . . . . . . . . . 2-316 2.24.8 Effect Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-317 2.24.9 Operation Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 2-318 2.24.10 Transition Triggering. . . . . . . . . . . . . . . . . . . . . . . . 2-319 2.24.11 Direct Communication among Executions . . . . . . . 2-319 2.24.12 Strong Typing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-320 2.24.13 Transmitting messages . . . . . . . . . . . . . . . . . . . . . . 2-320 2.24.14 Return information . . . . . . . . . . . . . . . . . . . . . . . . . 2-320 2.24.15 Messaging Classes. . . . . . . . . . . . . . . . . . . . . . . . . . 2-321 2.24.16 Optional Profile for Resolution of Operations and Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-330 2.25 Jump Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-332
viii
OMG-Unified Modeling Language, v1.5
March 2003
2.25.1 2.25.2 2.25.3 2.25.4 2.25.5 2.25.6
Jumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-332 Break and Continue Statements. . . . . . . . . . . . . . . . 2-334 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-335 Jumps with Concurrent Executions . . . . . . . . . . . . . 2-336 Jump Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-336 Additional Jump Semantics for Actions Defined Elsewhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-340 2.25.7 Jump Value Classes . . . . . . . . . . . . . . . . . . . . . . . . . 2-342
3
UML Notation Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 1 - Background
3-1
3-5 3-6 3-7 3-7 3-8 3-8 3-8 3-8 3-8 3-9 3-9 3-9
3.1 3.2 3.3 3.4 3.5 3.6
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Graphs and Their Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . Drawing Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invisible Hyperlinks and the Role of Tools . . . . . . . . . . . . . . . Background Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . String. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.6.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 2 - Diagram Elements
3.7
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 3.7.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 3.7.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 3.7.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 3.7.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.8.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 3-10 3-10 3-11 3-11 3-11 3-11 3-12 3-12 3-12
3.8
3.9
Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
3.10 Expression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
March 2003
OMG-Unified Modeling Language, v1.5
ix
3.10.5 OCL Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 3.10.6 Selected OCL Notation . . . . . . . . . . . . . . . . . . . . . . 3-13 3.10.7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3.11 Note. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.11.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 3 - Model Management
3-13 3-13 3-13 3-13 3-14 3-14
3.12 Type-Instance Correspondence . . . . . . . . . . . . . . . . . . . . . . . . 3-14 3.13 Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.13.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14 Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.14.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.15.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 4 - General Extension Mechanisms
3-16 3-16 3-16 3-17 3-17 3-18 3-19 3-19 3-19 3-19 3-20 3-21 3-24 3-24 3-24 3-24 3-25 3-25 3-26 3-26 3-26 3-27 3-28 3-28
3.16 Constraint and Comment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.16.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.16.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.16.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.16.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17 Element Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29 3.17.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29 3.17.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
x
OMG-Unified Modeling Language, v1.5
March 2003
3.17.3 3.17.4 3.17.5 3.17.6
Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-30 3-31 3-31 3-31 3-31 3-31 3-31 3-32 3-33 3-34 3-34 3-34 3-34
3.18 Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 5 - Static Structure Diagrams
3.19 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.19.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.19.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.19.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.20 Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 3.21 Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 3.22 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.22.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.22.2 Basic Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.22.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.22.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.22.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.22.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 3-35 3-36 3-36 3-36 3-37 3-37
3.23 Name Compartment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38 3.23.1 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38 3.23.2 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38 3.24 List Compartment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.24.1 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.24.2 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.24.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.24.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.25 Attribute 3.25.1 3.25.2 3.25.3 3.25.4 3.25.5 3.25.6 ......................................... Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38 3-38 3-39 3-40 3-41 3-41 3-41 3-42 3-43 3-44 3-44 3-44
3.26 Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44
March 2003
OMG-Unified Modeling Language, v1.5
xi
3.26.1 3.26.2 3.26.3 3.26.4 3.26.5 3.26.6
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-44 3-44 3-46 3-47 3-47 3-47 3-48 3-48 3-48 3-48 3-49 3-49 3-49 3-50 3-50 3-50 3-50 3-51 3-51 3-52 3-52 3-52 3-53 3-53 3-54 3-54 3-54 3-54 3-55 3-55 3-55 3-55 3-56 3-56 3-56 3-56 3-56
3.27 Nested Class Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.27.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.27.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.27.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.28 Type and Implementation Class . . . . . . . . . . . . . . . . . . . . . . . 3.28.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.28.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.28.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.28.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.29 Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.29.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.29.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.29.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.29.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.30 Parameterized Class (Template) . . . . . . . . . . . . . . . . . . . . . . . 3.30.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.30.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.30.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.30.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.30.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.31 Bound Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.31.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.31.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.31.3 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.31.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.31.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.32 Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.32.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.32.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.32.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.32.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.33 Metaclass. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.33.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.33.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57
xii
OMG-Unified Modeling Language, v1.5
March 2003
3.33.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.34 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.34.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.34.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.34.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.35 Stereotype Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.35.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.35.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.35.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.36 Powertype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.36.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.36.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.36.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.37 Class Pathnames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.37.1 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.37.2 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.37.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.38 Accessing or Importing a Package . . . . . . . . . . . . . . . . . . . . . 3.38.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.38.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.38.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.38.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.39 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.39.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.39.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.39.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.39.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.39.5 Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.39.6 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.39.7 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.40 Composite Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.40.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.40.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.40.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.40.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3-57 3-57 3-57 3-57 3-57 3-58 3-61 3-61 3-61 3-61 3-61 3-61 3-61 3-62 3-62 3-62 3-62 3-63 3-64 3-64 3-64 3-64 3-64 3-65 3-66 3-66 3-66 3-66 3-67 3-67 3-67 3-67 3-68
3.41 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68 3.42 Binary Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68 3.42.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68 3.42.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-68
March 2003
OMG-Unified Modeling Language, v1.5
xiii
3.42.3 3.42.4 3.42.5 3.42.6 3.42.7
Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-69 3-69 3-69 3-70 3-70 3-71 3-71 3-71 3-73 3-74 3-74 3-74 3-75 3-75 3-75 3-75 3-75 3-76 3-76 3-76 3-76 3-77 3-77 3-77 3-77 3-77 3-77 3-78 3-78 3-78 3-78 3-79 3-79 3-79 3-79 3-79 3-80 3-80
3.43 Association End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.43.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.43.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.43.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.43.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.43.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.43.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.44 Multiplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.44.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.44.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.44.3 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.44.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.44.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.45 Qualifier 3.45.1 3.45.2 3.45.3 3.45.4 3.45.5 3.45.6 ......................................... Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.46 Association Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.46.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.46.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.46.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.46.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.46.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.46.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.47 N-ary Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.47.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.47.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.47.3 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.47.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.47.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.48 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81 3.48.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81
xiv
OMG-Unified Modeling Language, v1.5
March 2003
3.48.2 3.48.3 3.48.4 3.48.5
Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-81 3-82 3-83 3-84 3-84 3-84 3-84 3-85 3-85 3-86 3-86 3-86 3-87 3-88 3-89 3-90 3-90 3-90 3-91 3-92 3-93 3-93 3-93 3-93 3-93 3-93 3-93 3-93 3-93 3-94 3-94 3-94 3-95 3-95 3-96 3-96 3-96 3-96
3.49 Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.49.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.49.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.49.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.49.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.50 Generalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.50.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.50.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.50.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.50.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.50.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.51 Dependency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.51.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.51.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.51.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.51.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.51.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.52 Derived Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.52.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.52.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.52.3 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.53 InstanceOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.53.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.53.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.53.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 6 - Use Case Diagrams
3.54 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.54.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.54.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.54.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.54.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.55 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.55.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.55.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.55.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . .
March 2003
OMG-Unified Modeling Language, v1.5
xv
3.55.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96 3.55.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.56 Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.56.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.56.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.56.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3.56.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.56.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.57 Use Case Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.57.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.57.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.57.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.57.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3-97 3-97 3-97 3-97 3-97 3-97 3-97 3-98 3-99 3-99
3.58 Actor Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-99 3.58.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-99 3.58.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-99 3.58.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-100 3.58.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-100
Part 7 - Interaction Diagrams
3.59 Collaboration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-101 3.59.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-101 3.60 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-102 3.60.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-102 3.60.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-102 3.60.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-102 3.60.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-104 3.60.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-106 3.61 Object Lifeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-108 3.61.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-108 3.61.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-109 3.61.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-109 3.61.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-109 3.61.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-110 3.62 Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-110 3.62.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-110 3.62.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-110 3.62.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111 3.62.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111 3.63 Message and Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111
xvi
OMG-Unified Modeling Language, v1.5
March 2003
3.63.1 3.63.2 3.63.3 3.63.4 3.63.5
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111 Presentation options . . . . . . . . . . . . . . . . . . . . . . . . 3-111 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113
3.64 Transition Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113 3.64.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113 3.64.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113 3.64.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-114 3.64.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-114 3.64.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-114
Part 8 - Collaboration Diagrams
3.65 Collaboration Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-114 3.65.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-114 3.65.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-114 3.65.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-116 3.65.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-117 3.66 Pattern Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-117 3.66.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-117 3.66.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-118 3.66.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121 3.67 Collaboration Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121 3.67.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121 3.67.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121 3.67.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-122 3.68 Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-123 3.68.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-123 3.68.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-123 3.68.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-124 3.68.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-124 3.69 Collaboration Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-124 3.69.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-124 3.69.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-124 3.69.3 Presentation options . . . . . . . . . . . . . . . . . . . . . . . . 3-125 3.69.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-126 3.69.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-126 3.70 Multiobject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-127 3.70.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-127 3.70.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-127
March 2003
OMG-Unified Modeling Language, v1.5
xvii
3.70.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128 3.70.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128 3.71 Active object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128 3.71.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128 3.71.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128 3.71.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129 3.71.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129 3.72 Message and Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-130 3.72.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-130 3.72.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-130 3.72.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-133 3.72.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-133 3.72.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-133 3.73 Creation/Destruction Markers . . . . . . . . . . . . . . . . . . . . . . . . . 3-134 3.73.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-134 3.73.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-135 3.73.3 Presentation options . . . . . . . . . . . . . . . . . . . . . . . . 3-135 3.73.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-135 3.73.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-135
Part 9 - Statechart Diagrams
3.74 Statechart Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-136 3.74.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-136 3.74.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-136 3.74.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-137 3.75 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-137 3.75.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-137 3.75.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-138 3.75.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-139 3.75.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-139 3.76 Composite States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-140 3.76.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-140 3.76.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-140 3.76.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-141 3.76.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-142 3.77 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-142 3.77.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-142 3.77.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-143 3.77.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-144 3.77.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-144
xviii
OMG-Unified Modeling Language, v1.5
March 2003
3.78 Simple Transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-145 3.78.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-145 3.78.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-145 3.78.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-146 3.78.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-146 3.79 Transitions to and from Concurrent States . . . . . . . . . . . . . . . 3-146 3.79.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-146 3.79.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-146 3.79.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147 3.79.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147 3.80 Transitions to and from Composite States . . . . . . . . . . . . . . . . 3-147 3.80.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147 3.80.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-147 3.80.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-148 3.80.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-149 3.80.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-150 3.81 Factored Transition Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-150 3.81.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-150 3.81.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-150 3.81.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-151 3.82 Submachine States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-152 3.82.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-152 3.82.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-152 3.82.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-153 3.82.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-154 3.83 Synch States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-154 3.83.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-154 3.83.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-154 3.83.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-155 3.83.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-155
Part 10 - Activity Diagrams
3.84 Activity Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-155 3.84.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-155 3.84.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-156 3.84.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-157 3.84.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-158 3.85 Action state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-158 3.85.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-158 3.85.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-158
March 2003
OMG-Unified Modeling Language, v1.5
xix
3.85.3 Presentation options . . . . . . . . . . . . . . . . . . . . . . . . 3-158 3.85.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-158 3.85.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-158 3.86 Subactivity state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159 3.86.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159 3.86.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159 3.86.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159 3.86.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159 3.87 Decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159 3.87.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-159 3.87.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-160 3.87.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-160 3.87.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-160 3.88 Call States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-161 3.88.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-161 3.88.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-161 3.88.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-161 3.88.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-161 3.89 Swimlanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-161 3.89.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-161 3.89.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-162 3.89.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-162 3.89.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-163 3.90 Action-Object Flow Relationships . . . . . . . . . . . . . . . . . . . . . 3-163 3.90.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-163 3.90.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-163 3.90.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-164 3.90.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-164 3.91 Control Icons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-165 3.91.1 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-165 3.91.2 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-167 3.92 Synch States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-168 3.93 Dynamic Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-168 3.93.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-168 3.93.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-168 3.93.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-169 3.94 Conditional Forks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-169
Part 11 - Implementation Diagrams
3.95 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-169
xx
OMG-Unified Modeling Language, v1.5
March 2003
3.95.1 3.95.2 3.95.3 3.95.4
Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-169 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-169 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-170 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-171
3.96 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-171 3.96.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-171 3.96.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-172 3.96.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-172 3.96.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-173 3.97 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-173 3.97.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-173 3.97.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-173 3.97.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-173 3.97.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-174 3.98 Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-174 3.98.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-174 3.98.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-175 3.98.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-175 3.98.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-176
4
UML Example Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 1 - UML Profile for Software Development Processes
4-1
4-1 4-2 4-2 4-3 4-4 4-5 4-6 4-7 4-8 4-9 4-9 4-9 4-9
4.1 4.2 4.3
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary of Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stereotypes and Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Use Case Stereotypes . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Analysis Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Design Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Implementation Stereotypes . . . . . . . . . . . . . . . . . . 4.3.5 Class Stereotypes. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.6 Association Stereotypes . . . . . . . . . . . . . . . . . . . . . Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Generalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
Example 2 - UML Profile for Business Modeling
4.5 4.6 4.7
Summary of Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 Stereotypes and Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 4.7.1 Use Case Stereotypes . . . . . . . . . . . . . . . . . . . . . . . 4-11
March 2003
OMG-Unified Modeling Language, v1.5
xxi
4.7.2 4.7.3 4.7.4 4.8
Organization Stereotypes. . . . . . . . . . . . . . . . . . . . . 4-12 Class Stereotypes. . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13 Association Stereotypes . . . . . . . . . . . . . . . . . . . . . 4-15
Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15 4.8.1 Generalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
5
UML Model Interchange . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 5.2 5.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-1
5-1
Model Interchange Using XMI . . . . . . . . . . . . . . . . . . . . . . . . 5-23 Model Interchange Using CORBA IDL . . . . . . . . . . . . . . . . . 5-24
6
Object Constraint Language Specification. . . . . . . . . . . . . . .
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Why OCL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Where to Use OCL . . . . . . . . . . . . . . . . . . . . . . . . . Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Legend. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Example Class Diagram . . . . . . . . . . . . . . . . . . . . . Relation to the UML Metamodel . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Self . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Specifying the UML context . . . . . . . . . . . . . . . . . . 6.3.3 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.4 Pre- and Postconditions . . . . . . . . . . . . . . . . . . . . . . 6.3.5 Package context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.6 General Expressions . . . . . . . . . . . . . . . . . . . . . . . . Basic Values and Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Types from the UML Model . . . . . . . . . . . . . . . . . . 6.4.2 Enumeration Types . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3 Let Expressions and definition Constraints . . . . . 6.4.4 Type Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.5 Re-typing or Casting . . . . . . . . . . . . . . . . . . . . . . . . 6.4.6 Precedence Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.7 Use of Infix Operators . . . . . . . . . . . . . . . . . . . . . . . 6.4.8 Keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.9 Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.10 Undefined Values. . . . . . . . . . . . . . . . . . . . . . . . . . . Objects and Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.2 Properties: Attributes. . . . . . . . . . . . . . . . . . . . . . . . 6.5.3 Properties: Operations . . . . . . . . . . . . . . . . . . . . . . .
6-1
6-2 6-2 6-3 6-3 6-3 6-4 6-4 6-4 6-5 6-5 6-6 6-6 6-7 6-7 6-8 6-8 6-8 6-9 6-10 6-10 6-10 6-11 6-11 6-11 6-12 6-12 6-12 6-12
6.2
6.3
6.4
6.5
xxii
OMG-Unified Modeling Language, v1.5
March 2003
6.5.4 6.5.5 6.5.6 6.5.7 6.5.8 6.5.9 6.5.10 6.5.11 6.5.12 6.5.13 6.5.14
Properties: Association Ends and Navigation . . . . . Navigation to Association Classes. . . . . . . . . . . . . . Navigation from Association Classes . . . . . . . . . . . Navigation through Qualified Associations . . . . . . . Using Pathnames for Packages . . . . . . . . . . . . . . . . Accessing overridden properties of supertypes . . . . Predefined properties on All Objects. . . . . . . . . . . . Features on Classes Themselves . . . . . . . . . . . . . . . Collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collections of Collections . . . . . . . . . . . . . . . . . . . . Collection Type Hierarchy and Type Conformance Rules . . . . . . . . . . . . . . . . . . . . . 6.5.15 Previous Values in Postconditions . . . . . . . . . . . . . . 6.6 Collection Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.1 Select and Reject Operations . . . . . . . . . . . . . . . . . . 6.6.2 Collect Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.3 ForAll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.4 Exists Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.5 Iterate Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6.6 Iterators in Collection Operations . . . . . . . . . . . . . . 6.6.7 Resolving Properties . . . . . . . . . . . . . . . . . . . . . . . .
6-13 6-15 6-16 6-16 6-17 6-17 6-18 6-19 6-19 6-21 6-21 6-21 6-22 6-22 6-24 6-25 6-26 6-26 6-27 6-27
6.7 6.8
The Standard OCL Package . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28 Predefined OCL Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29 6.8.1 Basic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29 6.8.2 Collection-Related Types . . . . . . . . . . . . . . . . . . . . 6-36 Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-45
6.9
UML Standard Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Action Language Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1 B.2 B.3 B.4 B.5 B.6 The Action Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presentation of the Examples . . . . . . . . . . . . . . . . . . . . . . . . . Control Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Object Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Complete Example: The FFT . . . . . . . . . . . . . . . . . . . . . . . . . B.6.1 The Fast Fourier Transform . . . . . . . . . . . . . . . . . . . B.6.2 Illustrative Notation . . . . . . . . . . . . . . . . . . . . . . . . . B.6.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.6.4 Implementation Using Memory Writes . . . . . . . . . .
A-1 B-1
B-1 B-2 B-3 B-6 B-26 B-27 B-28 B-30 B-33
Messaging Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19
March 2003
OMG-Unified Modeling Language, v1.5
xxiii
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Glossary -1 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index -1
xxiv
OMG-Unified Modeling Language, v1.5
March 2003
Foreword
The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components. The UML represents the culmination of best practices in practical object-oriented modeling. The UML is the product of several years of hard work, in which we focused on bringing about a unification of the methods most used around the world, the adoption of good ideas from many quarters of the industry, and, above all, a concentrated effort to make things simple. We mean we in the most general sense. The three of us started the UML effort at Rational and were its original chief methodologists, but the final product was a team effort among many UML partners under the sponsorship of OMG. All partners came with their own perspectives, areas of concern, and areas of interest; this diversity of experience and viewpoints has enriched and strengthened the final result. We extend our personal thanks to everyone who was a part of making the UML a reality. We would like to thank Rational for giving us the opportunity to work freely so that we might focus on unification, and we want to recognize all the other companies representing the UML partners for seeing the importance of the UML to the industry as a whole and giving their representatives time to work on this project. We must also thank the OMG for providing the framework under which we could bring together many diverse opinions to develop a consensus result. We expect that OMGs ownership of the UML standard and the publics free access to it will ensure the widespread use and advancement of UML technology over the coming years. In an effort that involved so many companies and individuals with so many agendas, one would think that the resulting product would be the software equivalent of a camel: a most dysfunctional-looking animal that appears to have been the work product of an
March 2003
OMG-Unified Modeling Language, v1.5
xxv
ill-formed committee of misfits. The UML most decidedly is not a random collection of political compromises. If anything, because of the focus we placed upon creating a complete and formal model, the UML is coherent and has harmony of design. In this context it is also exciting to point out that the UML was developed alongside, and with the full collaboration, of the OMGs Meta-Object Facility (MOF) team. The MOF, which represents the state of the art in distributed object repository architectures, is OMGs adopted technology for modeling and representing metadata (including the UML metamodel) as CORBA objects. The UML and MOF standards are key building blocks of OMG's development environment for building and deploying distributed object systems. It is a very real sign of maturity of the industry that the UML exists as a standard. At a time when software is increasingly more complex and more central to the mission of companies and countries, the UML comes at the right time to help organizations deal with this complexity. Already, without a lot of the fanfare or hype sometimes associated with programming languages, the UML is in use in hundreds (if not thousands) of projects around the world, a sign that it is part of the mainstream of engineering software. Grady Booch Ivar Jacobson Jim Rumbaugh Rational Software Corporation
xxvi
OMG-Unified Modeling Language, v1.5
March 2003
Preface
About the Object Management Group (OMG)
The Object Management Group, Inc. (OMG) is an international organization supported by over 600 members, including information system vendors, software developers and users. Founded in 1989, the OMG promotes the theory and practice of object-oriented technology in software development. The organization's charter includes the establishment of industry guidelines and object management specifications to provide a common framework for application development. Primary goals are the reusability, portability, and interoperability of object-based software in distributed, heterogeneous environments. Conformance to these specifications will make it possible to develop a heterogeneous applications environment across all major hardware platforms and operating systems. OMG's objectives are to foster the growth of object technology and influence its direction by establishing the Object Management Architecture (OMA). The OMA provides the conceptual infrastructure upon which all OMG specifications are based.
Associated OMG Documents
The CORBA documentation set includes the following: CORBA: Common Object Request Broker Architecture and Specification contains the architecture and specifications for the Object Request Broker. CORBAservices: Common Object Services Specification contains specifications for the object services. CORBAfacilities: Common Facilities Architecture contains information about the design of Common Facilities; it provides the framework for Common Facility specifications. Object Management Architecture Guide defines the OMGs technical objectives and terminology and describes the conceptual models upon which OMG standards are based. It also provides information about the policies and procedures of OMG, such as how standards are proposed, evaluated, and accepted.
March 2003
OMG-Unified Modeling Language, v1.5
xxvii
OMG collects information for each book in the documentation set by issuing Requests for Information, Requests for Proposals, and Requests for Comment and, with its membership, evaluating the responses. Specifications are adopted as standards only when representatives of the OMG membership accept them as such by vote. To obtain books in the documentation set, or other OMG publications, refer to the enclosed subscription card or contact the Object Management Group, Inc. at:
OMG Headquarters 250 First Avenue Needham, MA 02494 Tel: [phone] Fax: [phone] [e-mail] http://www.omg.org
OMGs adoption of the UML specification reduces the degree of confusion within the industry surrounding modeling languages. It settles unproductive arguments about method notations and model interchange mechanisms and allows the industry to focus on higher leverage, more productive activities. Additionally, it enables semantic interchange between visual modeling tools.
Introduction to OMG Modeling
The OMG Modeling documents describe the OMG standards for modeling distributed software architectures and systems along with their CORBA Interfaces. There are two complementary specifications:
Unified Modeling Language Specification Meta-Object Facility Specification
The Unified Modeling Language (UML) Specification defines a graphical language for visualizing, specifying, constructing, and documenting the artifacts of distributed object systems. The specification includes the formal definition of a common Object Analysis and Design (OA&D) metamodel, a graphic notation, and a CORBA IDL facility that supports model interchange between OA&D tools and metadata repositories. The UML provides the foundation for specifying and sharing CORBAbased distributed object models. The Meta-Object Facility (MOF) Specification defines a set of CORBA IDL interfaces that can be used to define and manipulate a set of interoperable metamodels and their corresponding models. These interoperable metamodels include the UML metamodel, the MOF meta-metamodel, as well as future OMG adopted technologies that will be specified using metamodels. The MOF provides the infrastructure for implementing CORBA-based design and reuse repositories. The MOF specifies precise mapping rules that enable the CORBA interfaces for metamodels to be automatically generated, thus encouraging consistency in manipulating metadata in all phases of the distributed application development cycle.
xxviii
OMG-Unified Modeling Language, v1.5
March 2003
Since the UML and MOF are based on a four-layer metamodel architecture it is essential that the metamodels for each facility are architecturally aligned. For a description of the four layer metamodel architecture, please refer to Section 2.2, Meta-data Architectures, on page 2-1 in the MOF Specification. In order to achieve architectural alignment considerable effort has been expended so that the UML and MOF share the same core semantics. This alignment allows the MOF to reuse the UML notation for visualizing metamodels. In those areas where semantic differences are required, well-defined mapping rules are provided between the metamodels. The OMG distributed repository architecture, which integrates UML and MOF with CORBA is described in Resolution of Technical Criteria in the Preface of the MOF Specification. As the first adopted technologies specified using a metamodeling approach, the UML and MOF establish a rigorous foundation for OMGs metamodel architectures. Future metamodel standards should reuse their core semantics and emulate their systematic approach to architecture alignment.
Architectural Alignment of UML, MOF, and CORBA
Introduction
This section explains the architectural alignment of the OA&D Facility (OA&DF) metamodel and the MOF meta-metamodel, and their relationships to the OMA and CORBA object models. When discussing specific models, MOF corresponds to the MOF meta-metamodel also referred to as the MOF Model. The UML is used to refer to the proposed OA&DF metamodel. As yet, there is not an MOF meta-metamodel standard or an OA&D metamodel standard. However, since each of these specifications has been unified, a proactive approach has been taken towards architectural alignment. Considerable structure sharing between the two specifications has been accomplished. As the OA&DF and MOF technologies evolve, additional alignment work will be addressed by standard OMG processes such as those for Revision Task Forces and subsequent RFPs. The MOF and OA&DF alignment work has focused on aligning the metamodels and applying the MOF IDL Mapping for generating the CORBA IDL for both the MOF and UML models. This was accomplished by defining the MOF and UML models using the MOF and by generating the IDL interfaces based on the MOF specification. Note that both the MOF and OADF specifications use the UML notation for graphically defining the models. In terms of abstraction levels and the kinds of meta-metaobjects used, the UML and MOF meta-metamodels are well aligned. There are significant advantages in aligning the OA&DF meta-metamodel with the MOF meta-metamodel. In the case of the MOF, meta-metamodel alignment facilitates interoperability between the OA&DF and the MOF. An example of OA&DF-MOF interoperability is the use of an MOF-compliant repository to store an OA&DF object model.
March 2003
OMG-Unified Modeling Language, v1.5
xxix
Alignment of the UML, MOF, and CORBA paves the way for future extensibility of CORBA in key areas such as richer semantics, relationships, and constraints. Likewise the longer-term benefits to UML and MOF include better recognition and addressing of distributed computing issues in developing CORBA-compliant systems.
Motivation
The primary reason for aligning the OA&DF metamodel with the MOF metametamodel is to facilitate interoperability between the two facilities using CORBA IDL. When considering interoperability between the OA&DF and the MOF, it is important to consider the difference in scope between the facilities. The MOF goal is to allow interoperability across the application development cycle by supporting the definition of multiple metamodels, whereas the OA&DF focuses on supporting the definition of a single OA&D metamodel. An example of OA&DF-MOF interoperability is the use of an MOF-compliant repository to store and interchange OA&DF object models. The key motivation to align the MOF and OA&DF with CORBA is to address the requirement of aligning with CORBA and between the two facilities. In addition, the MOF and OA&DF (especially the UML) specifications signify years of modeling and metamodeling experience that are being integrated. As such, some of the key concepts in the UML and MOF are potential candidates to evolve the OMG Core object model and CORBA IDL in the future.
Approach
The UML and MOF are based on a four-layer metamodel architecture, where the MOF meta-metamodel is the meta-metamodel for the UML metamodel. As a result, the UML metamodel may be considered an instance-of the MOF meta-metamodel. This is sometimes referred to as loose metamodeling, where an Mn level model is an instance of an Mn+1 level model. Since the MOF and OA&DF have different scopes, and diverge in the area of relationships, we have not been able to apply strict metamodeling. In strict metamodeling, every element of an Mn level model is an instance of exactly one element of Mn+1 level model. Consequently, there is not a strict isomorphic mapping between all the MOF meta-metamodel elements and the UML meta-metamodel elements. In principle strict metamodeling is difficult (or sometimes impossible to accomplish) as the complexity of new concepts (for example patterns and frameworks) continues to increase. In any case, using a small set of primitive concepts such as those defined in the MOF it is possible to define arbitrarily complex metamodels. In spite of this, since the two models were designed to be interoperable, the two metamodels are structurally quite similar. The following sections compare the core MOF and UML modeling concepts, and contrast them with the OMA and CORBA/IDL core object models. The issues related to mapping metaclasses that are not isomorphic; for example, Association classes are also discussed.
xxx
OMG-Unified Modeling Language, v1.5
March 2003
The following tables are comparison tables that summarize the mappings of similar concepts across the meta-metamodeling layers. Where there is no analog for a concept, it will be identified and discussed in Issues Related to UML-MOF Mapping on page xxxii..
Metamodel Comparison
Most of the metaobjects for the UML core metamodel and the MOF core metametamodel can be mapped to each other in a straightforward manner. Similarly, these metaobjects can also be mapped to the OMA and CORBA core object models in a direct way. The following tables compare the core modeling concepts and the data types for these models. UML Metamodel Association (n-ary) AssociationClass AssociationEnd Attribute BehavioralFeature Class Classifier Constraint DataType Dependency (class) Exception Feature GeneralizableElement Generalization (class) Interface ModelElement NA NA Namespace Operation Package MOF Meta-metamodel Association (binary) NA AssociationEnd Attribute BehavioralFeature Class Classifier Constraint DataType /dependsOn (association) Exception Feature GeneralizableElement generalizes (association) Class (as Interface) ModelElement Reference Constant Namespace Operation Package Operation Constant ~ IR Containers Operation Module Generalization Interface Generalization Interface Exception Data type Data type Class Interface (as Class) Attribute Attribute OMA Core Object Model CORBA Object Model CORBA IDL
March 2003
OMG-Unified Modeling Language, v1.5
xxxi
UML Metamodel Parameter StructuralFeature Type (stereotype)
MOF Meta-metamodel Parameter StructuralFeature Class (as Type)
OMA Core Object Model CORBA Object Model Parameter
CORBA IDL Parameter
Type
Interface (as Type)
UML Metamodel AggregationKind Boolean Enumeration Expression Integer Multiplicity Name ParameterDirectionKind ScopeKind String VisibilityKind
MOF Meta-metamodel AggregationKind CORBA Boolean CORBA Enum NameType CORBA Short, Long, Unsigned Short, Unsigned Long, Double, Octet, Float MultiplicityType NameType DirectionKind ScopeKind CORBA String, Char VisibilityKind
CORBA Object Model and IDL
Boolean Enum
Short, Long, Unsigned Short, Unsigned Long, Double, Octet, Float
Name
String, Char
The MOF supports the full range of CORBA data types as well as additional data types defined using the MOF primitive types. UML supports a subset of CORBA data types in its semantic model but mapping to a subset of specific CORBA types is clearly possible. The following sections discuss issues related to areas where the mapping between metamodels is not direct.
Issues Related to UML-MOF Mapping
In general, the mapping from the UML meta-metamodel to the MOF meta-metamodel is straightforward. A review of the previous comparison tables indicates that in most cases the mapping from the UML meta-metamodel to the MOF meta-metamodel is direct. In fact, for most of the core constructs there is a structural equivalency in the mapping. The key differences are due to different usage scenarios of MOF and UML. The MOF needs to be simpler, directly implementable, and provide a set of CORBA interfaces for manipulating meta objects. The UML is used as a general-purpose modeling
xxxii
OMG-Unified Modeling Language, v1.5
March 2003
language, with potentially many implementation targets. These differences are commonly observed in repository, meta-CASE, and modeling-tool implementations. The key differences are:
The MOF only supports binary associations while UML supports higher-order (also referred to as 'N-ary') associations. This tradeoff was made because N-ary relationships are rarely used in metamodeling and the design goal was to keep the MOF interfaces simpler. We have anticipated extending the MOF to support higher order associations in future. Associations in the MOF are limited to simple associations and cannot contain features. Association Classes in UML can contain features (such as attributes). The MOF has been defined to be structurally extensible to full-blown association classes in the future by relaxing this constraint. UML Association Classes are modeled as MOF Classes with well-defined multiplicity constraints to ensure shared lifetime of features owned by the association. The MOF supports the concept of a Reference which allows direct navigation from one Classifier to another. The UML metamodel uses the Target AssociationEnds 'name' property as a pseudo-attribute for the same purpose, but navigates to another classifier through an Association. The concept of reference is widely used in object repositories, as well as object and object-relational databases and optimizes navigation across a metamodel. Some concepts such as Generalization, Dependency, and Refinement are reified as classes in UML, but implemented as Associations in the MOF. The MOF does not require the richness of UML in these areas. The MOF supports the full set of CORBA data types, whereas the UML metamodel does not define data types to this depth. A CORBA-specific implementation of UML is clearly possible by either creating the additional data types needed or by providing appropriate mappings. The UML has clearly defined the similarities of the key concepts of Class, Interface, and Type. The MOF and UML both use the Class concept as the most general of these in their respective models. The MOF specification is focused only on specification of metamodels and generation of CORBA interfaces; therefore, it does not deal with implementation concepts such as 'Methods.' UML clearly needs to support these concepts because UML can be used to model conceptual, logical, and implementation models. In this sense, the MOF uses the Class concept to define Types, since MOF Classes do not have any methods, just operations. This is consistent with the definition of UML Type as a stereotype of Class with a constraint that Types cannot contain methods. The MOF Class concept is rich enough to define Interfaces, and in fact the MOF specification itself clearly shows that an MOF Class can be mapped to multiple CORBA Interfaces. The previous table shows that the mapping of metadatatypes between the metametamodels is also straightforward. Here also there are more MOF metametaobjects than there are UML meta-metaobjects. The MOF supports the full range of CORBA data types as well as additional data types defined using the MOF primitive types. UML supports a subset of CORBA data types in its semantic model but maps to specific CORBA types in its corresponding interface model.
March 2003
OMG-Unified Modeling Language, v1.5
xxxiii
Relationship to Other Models
Secondary emphasis was placed on the architectural alignment with CASE Data Interchange Format (CDIF) and ITU-T Recommendations X.901-904 | ISO/IEC 10746, the Reference Model of Open Distributed Processing (RM-ODP), both of which have influenced the metamodel architectures. CDIF provided many useful concepts for specifying robust stream-based interchange formats. Similarly, ODP furnished many useful ideas for specifying model viewpoints. The document entitled Relationship of the UML to the RM-ODP (ormsc/2001-01-01) satisfies the OMG policy regarding compatibility of submitted technology with the architecture for system distribution defined in RM-ODP.
Document Summary
This document is intended primarily as a precise and self-consistent definition of the UMLs semantics and notation. The primary audience of this document consists of the Object Management Group, standards organizations, book authors, trainers, and tool builders. The authors assume familiarity with object-oriented analysis and design methods. The document is not written as an introductory text on building object models for complex systems, although it could be used in conjunction with other materials or instruction. The document will become more approachable to a broader audience as additional books, training courses, and tools that apply to UML become available. The Unified Modeling Language specification defines compliance to the UML, covers the architectural alignment with other technologies, and is comprised of the following topics: UML Summary (Chapter 1) - provides an introduction to the UML, discussing motivation and history. UML Semantics (Chapter 2) - defines the semantics of the Unified Modeling Language. The UML is layered architecturally and organized by packages. Within each package, the model elements are defined in the following terms: 1. Abstract syntax UML class diagrams are used to present the UML metamodel, its concepts (metaclasses), relationships, and constraints. Definitions of the concepts are included. The rules and constraints on valid models are defined. The rules are expressed in English prose and in a precise Object Constraint Language (OCL). OCL is a specification language that uses logic for specifying invariant properties of systems comprising sets and relationships between sets. The semantics of model usage are described in English prose.
2. Well-formedness rules
3. Semantics
xxxiv
OMG-Unified Modeling Language, v1.5
March 2003
UML Notation Guide (Chapter 3) - specifies the graphic syntax for expressing the semantics described by the UML metamodel. Consequently, the UML Notation Guides chapter should be read in conjunction with the UML Semantics chapter. UML Example Profiles (Chapter 4) - shows two example profiles, the UML Profile for Software Development Processes and the UML Profile for Business Modeling. UML Model Interchange (Chapter 5) - specifies the how UML models can be interchanged using XML Metadata Interchange (XMI) and CORBA IDL. Object Constraint Language Specification (Chapter 6) - defines the Object Constraint Language (OCL) syntax, semantics, and grammar. All OCL features are described in terms of concepts defined in the UML Semantics. In addition, there is an appendix of Standard Elements that defines standard stereotypes, constraints, and tagged values for UML, and a glossary of terms.
Dependencies between chapters
UML Semantics (Chapter 2) can stand on its own, relative to the others, with the exception of the OCL Specification. The semantics depends upon OCL for the specification of its well-formedness rules. The UML Notation Guide and UML Model Interchange both depend on the UML Semantics. Specifying these separately permits their evolution in the most flexible way, even though they are not completely independent. The specifications in the UML Extensions chapter depend on both the notation and semantics chapters.
Compliance to the UML
The UML and corresponding facility interface definition are comprehensive. However, these specifications are packaged so that subsets of the UML and facility can be implemented without breaking the integrity of the language. The UML Semantics is packaged as shown in the following figure.
March 2003
OMG-Unified Modeling Language, v1.5
xxxv
Behavioral Elem ents
Activity Graphs
Collaborations
Use Cases
State Machines
Actions
Common Behavior
Model Management
Foundation
Core
Extension Mec hanism s
Data Types
UML Class Diagram Showing Package Structure
This packaging shows the semantic dependencies between the UML model elements in the different packages. The IDL in the facility is packaged almost identically. The notation is also packaged along the lines of diagram type. Compliance of the UML is thus defined along the lines of semantics, notation, and IDL. Even if the compliance points are decomposed into more fundamental units, vendors implementing UML may choose not to fully implement this packaging of definitions, while still faithfully implementing some of the UML definitions. However, vendors who want to precisely declare their compliance to UML should refer to the precise language defined herein, and not loosely say they are UML compliant.
Compliance to the UML Semantics
The basic units of compliance are the packages defined in the UML metamodel. The full metamodel includes the corresponding semantic rigor defined in the UML Semantics chapter of this specification.
xxxvi
OMG-Unified Modeling Language, v1.5
March 2003
The class diagram illustrates the package dependencies, which are also summarized in the table below. Package DataTypes Core Extension Mechanisms Common Behavior State Machines Activity Graphs Collaborations Use Cases Model Management Actions DataTypes, Extension Mechanisms Core, DataTypes Foundation Common Behavior, Foundation State Machines, Foundation Common Behavior, Foundation Common Behavior, Foundation Foundation Common Behavior, Foundation Prerequisite Packages
Complying with a package requires complying with the prerequisite package. The semantics are defined in an implementation language-independent way. An implementation of the semantics, without consistent interface and implementation choices, does not guarantee tool interoperability. See Chapter 5, UML Model Interchange. In addition to the above packages, compliance to a given metamodel package must load or know about the predefined UML standard elements (i.e., values for all predefined stereotypes, tags, and constraints). These are defined throughout the semantics and notation documents and summarized in the UML Standard Elements appendix. The predefined constraint values must be enforced consistent with their definitions. Having tools know about the standard elements is necessary for the full language and to avoid the definition of user-defined elements that conflict with the standard UML elements. Compliance to the UML Standard Elements and UML Standard Profiles is distinct from the UML Semantics, so not all tools need to know about the UML Standard Elements and UML Standard Profiles. For any implementation of UML, it is optional that the tool implements the Object Constraint Language. A vendor conforming to OCL support must support the following:
Validate and store syntactically correct OCL expressions as values for UML data types. Be able to perform a full type check on the object constraint expression. This check will test whether all features used in the expression are actually defined in the UML model and used correctly.
All tools conforming to the UML semantics are expected to conform to the following aspects of the semantics:
March 2003
OMG-Unified Modeling Language, v1.5
xxxvii
abstract syntax; that is, the concepts, valid relationships, and constraints expressed in the corresponding class diagrams, well-formedness rules, and semantics of model usage.
However, vendors are expected to apply some discretion on how strictly the wellformedness rules are enforced. Tools should be able to report on well-formedness violations, but not necessarily force all models to be well formed. Incomplete models are common during certain phases of the development lifecycle, so they should be permitted.
Compliance to the UML Notation
The UML notation is an essential element of the UML to enable communication between team members. Compliance to the notation is optional, but the semantics are not very meaningful without a consistent way of expressing them. Notation compliance is defined along the lines of the UML Diagrams types: use case, class, statechart, activity graph, sequence, collaboration, component, and deployment diagrams. If the notation is implemented, a tool must enforce the underlying semantics and maintain consistency between diagrams if the diagrams share the same underlying model. By this definition, a simple drawing tool cannot be compliant to the UML notation. There are many optional notation adornments. For example, a richly adorned class icon may include an embedded stereotype icon, a list of properties (tagged values and metamodel attributes), constraint expressions, attributes with visibilities indicated, and operations with full signatures. Complying with class diagram support implies the ability to support all of the associated adornments. Compliance to the notation in the UML Standard Profiles is described separately.
Compliance to Model Interchange Using XMI
The UML XMI DTD (document number ad/01-02-16) supports all packages of the UML Interchange Metamodel, which is a MOF translation of the UML Semantics Metamodel. See Model Interchange Using XMI (section 5.2). Each package of the Interchange Metamodel defines a separate compliance option.
Compliance to Model Interchange Using CORBA IDL
A UML CORBAfacility must support the MOF Reflective interfaces. Supporting the reflective interfaces for the Core package is the most basic level of compliance.Support for each additional package is a separate compliance option. In addition, support for each package's specific IDL module defined in UML_1.4_CORBA_IDL.zip (document number ad/01-02-17) constitutes a separate compliance option.
xxxviii
OMG-Unified Modeling Language, v1.5
March 2003
Summary of Compliance Points
Compliance Point Foundation Common Behavior State Machines Activity Graphs Collaboration Use Cases Model Management UML Profiles Use Case diagram Class diagram Statechart diagram Activity Graph diagram Sequence diagram Collaboration diagram Component diagram Deployment diagram Model Interchange Using XMI Model Interchange Using CORBA IDL OCL Valid Options no/incomplete, complete, complete including IDL and/or XMI DTD no/incomplete, complete, complete including IDL and/or XMI DTD no/incomplete, complete, complete including IDL and/or XMI DTD no/incomplete, complete, complete including IDL and/or XMI DTD no/incomplete, complete, complete including IDL and/or XMI DTD no/incomplete, complete, complete including IDL and/or XMI DTD no/incomplete, complete, complete including IDL and/or XMI DTD no/incomplete, complete no/incomplete, complete no/incomplete, complete no/incomplete, complete no/incomplete, complete no/incomplete, complete no/incomplete, complete no/incomplete, complete no/incomplete, complete no/incomplete, complete no/incomplete, complete, reflective interfaces, package-based interfaces no/incomplete, complete
Acknowledgements
The UML was crafted through the dedicated efforts of individuals and companies who find UML strategic to their future. This section acknowledges the efforts of these individuals who contributed to defining UML.
March 2003
OMG-Unified Modeling Language, v1.5
xxxix
UML Core Team
The following persons were members of the core development team for the UML proposal or served on the first or second UML Revision Task Force: Colorado State University: Robert France Computer Associates: John Clark Concept 5 Technologies: Ed Seidewitz Data Access Corporation: Tom Digre Enea Data: Karin Palmkvist Hewlett-Packard Company: Martin Griss IBM Corporation: Steve Brodsky, Steve Cook I-Logix: Eran Gery, David Harel ICON Computing: Desmond DSouza IntelliCorp and James Martin & Co.: James Odell Kabira Technologies: Conrad Bock Klasse Objecten: Jos Warmer MCI Systemhouse: Joaquin Miller OAO Technology Solutions: Ed Seidewitz ObjecTime Limited: John Hogg, Bran Selic Oracle Corporation: Guus Ramackers PLATINUM Technology Inc.: Dilhar DeSilva Rational Software: Grady Booch, Ed Eykholt, Ivar Jacobson, Gunnar Overgaard, Jim Rumbaugh SAP: Oliver Wiegert SOFTEAM: Philippe Desfray Sterling Software: John Cheesman, Keith Short Sun Microsystems: Peter Walker Telelogic: Cris Kobryn, Morgan Bjrkander Taskon: Trygve Reenskaug Unisys Corporation: Sridhar Iyengar, GK Khalsa, Don Baisley
UML 1.1 Semantics Task Force
During the final submission phase for UML 1.1, a team was formed to focus on improving the formality of the UML 1.0 semantics, as well as incorporating additional ideas from the partners. Under the leadership of Cris Kobryn, this team was very instrumental in reconciling diverse viewpoints into a consistent set of semantics, as expressed in the revised UML Semantics. Other members of this team were Dilhar DeSilva, Martin Griss, Sridhar Iyengar, Eran Gery, James Odell, Gunnar Overgaard, Karin Palmkvist, Guus Ramackers, Bran Selic, and Jos Warmer. Grady Booch, Ivar Jacobson, and Jim Rumbaugh also provided their expertise to the team.
xl
OMG-Unified Modeling Language, v1.5
March 2003
UML Revision Task Force
After the adoption of the UML 1.1 proposal by the OMG membership in November, 1997, the OMG chartered a revision task force (RTF) to deal with bugs, inconsistencies, and other problems that could be handled without greatly expanding the scope of the original proposal. The RTF accepted public comments submitted to the OMG after adoption of the proposal. This document containing UML version 1.3 is the result of the work of the UML RTF. The results have been issued in several preliminary versions with minor changes expected in the final version. If you have a preliminary version of the specification, you can obtain an updated version from the OMG web site at www.omg.org.
Contributors and Supporters
We also acknowledge the contributions, influence, and support of the following individuals. Jim Amsden, Hernan Astudillo, Colin Atkinson, Dave Bernstein, Philip A. Bernstein, Michael Blaha, Mike Bradley, Ray Buhr, Gary Cernosek, James Cerrato, Brian Cook, Magnus Christerson, Dai Clegg, Peter Coad, Derek Coleman, Ward Cunningham, Raj Datta, Mike Devlin, Philippe Desfray, Bruce Douglass, Nathan Dykman, Staffan Ehnebom, Maria Ericsson, Johannes Ernst, Don Firesmith, Martin Fowler, Adam Frankl, Eric Gamma, Dipayan Gangopadhyay, Garth Gullekson, Rick Hargrove, Tim Harrison, Richard Helm, Brian Henderson-Sellers, Michael Hirsch, Bob Hodges, Glenn Hollowell, Yves Holvoet, Jon Hopkins, John Hsia, Anders Ivner, Ralph Johnson, Stuart Kent, Anneke Kleppe, Philippe Kruchten, Paul Kyzivat, Martin Lang, Grant Larsen, Reed Letsinger, Mary Loomis, Jeff MacKay, Bev Macmaster, Robert Martin, Terrie McDaniel, Jim McGee, Bertrand Meyer, Mike Meier, Randy Messer, Greg Meyers, Fred Mol, Birger Moller-Pedersen, Luis Montero, Paul Moskowitz, Andy Moss, Jan Pachl, Paul Patrick, Woody Pidcock, Bill Premerlani, Jeff Price, Jerri Pries, Terry Quatrani, Mats Rahm, George Reich, Rich Reitman, Rudolf M. Riess, Erick Rivas, Kenny Rubin, Bernhard Rumpe, Jim Rye, Danny Sabbah, Tom Schultz, Gregson Siu, Jeff Sutherland, Dan Tasker, Dave Tropeano, Andy Trice, Dan Uhlar, John Vlissides, Larry Wall, Paul Ward, Diane White, Oliver Wiegert, Alan Wills, Rebecca Wirfs-Brock, Bryan Wood, Ed Yourdon, and Steve Zeigler.
March 2003
OMG-Unified Modeling Language, v1.5
xli
References
[Bock/Odell 94] [Booch et al. 99] [Cook 94] C. Bock and J. Odell, A Foundation For Composition, Journal of Object-Oriented Programming, October 1994. Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Addison Wesley, 1999. S. Cook and J. Daniels, Designing Object Systems: Objectoriented Modeling with Syntropy, Prentice-Hall Object-Oriented Series, 1994. D. DSouza and A. Wills, Objects, Components and Frameworks with UML: The Catalysis Approach, Addison-Wesley, 1999. M. Fowler with K. Scott, UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, 1997. M. Griss, Domain Engineering And Variability In The ReuseDriven Software Engineering Business, Object Magazine. December 1996. D. Harel, Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming 8, (1987), pp. 231-274. D. Harel and E. Gery, Executable Object Modeling with Statecharts, Proc. 18th Int. Conf. Soft. Eng., Berlin, IEEE Press, March, 1996, pp. 246-257. D. Harel and A. Naamad, The STATEMATE Semantics of Statecharts, ACM Trans. Soft. Eng. Method 5:4, October 1996. Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process, Addison Wesley, 1999. R. Malan, D. Coleman, R. Letsinger et al, The Next Generation of Fusion, Fusion Newsletter, October 1996. J. Martin and J. Odell, Object-Oriented Methods, A Foundation, Prentice Hall, 1995 Ramackers, G. and Clegg, D., Object Business Modelling, requirements and approach in Sutherland, J. and Patel, D. (eds.), Proceedings of the OOPSLA95 Workshop on Business Object Design and Implementation, Springer Verlag, publication pending. Ramackers, G. and Clegg, D., Extended Use Cases and Business Objects for BPR, ObjectWorld UK 96, London, June 18-21, 1996. Jim Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Addison Wesley, 1999.
[DSouza 99] [Fowler 97] [Griss 96]
[Harel 87]
[Harel 96a]
[Harel 96b] [Jacobson et al. 99] [Malan 96] [Martin/Odell 95] [Ramackers 95]
[Ramackers 96]
[Rumbaugh et al. 99]
xlii
OMG-Unified Modeling Language, v1.5
March 2003
[Selic et al. 94] [Warmer et al. 99] [UML Web Sites]
B. Selic, G. Gullekson, and P. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, 1994. J. Warmer and A. Kleppe, The Object Constraint Language: Precise Modeling with UML, Addison-Wesley, 1999. OMG UML Resource Page: www.omg.org/uml OMG UML RTF: www.celigent.com/omg/umlrtf
March 2003
OMG-Unified Modeling Language, v1.5
xliii
xliv
OMG-Unified Modeling Language, v1.5
March 2003
UML Summary
1
The UML Summary provides an introduction to the UML, discussing its motivation and history.
Contents
This chapter contains the following topics.
Topic
Overview Primary Artifacts of the UML Motivation to Define the UML Goals of the UML Scope of the UML UML - Past, Present, and Future
Page
1-1 1-2 1-3 1-4 1-6 1-11
1.1 Overview
The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems.
March 2003
OMG-Unified Modeling Language, v1.5
1-1
1 UML Summary 1.2 Primary Artifacts of the UML
What are the primary artifacts of the UML? This can be answered from two different perspectives: the UML definition itself and how it is used to produce project artifacts.
1.2.1 UML-defining Artifacts
To aid the understanding of the artifacts that constitute the Unified Modeling Language itself, this document consists of chapters describing UML Semantics, UML Notation Guide, and UML Standard Profiles.
1.2.2 Development Project Artifacts
The choice of what models and diagrams one creates has a profound influence upon how a problem is attacked and how a corresponding solution is shaped. Abstraction, the focus on relevant details while ignoring others, is a key to learning and communicating. Because of this:
Every complex system is best approached through a small set of nearly independent views of a model. No single view is sufficient. Every model may be expressed at different levels of fidelity. The best models are connected to reality.
In terms of the views of a model, the UML defines the following graphical diagrams: use case diagram class diagram behavior diagrams: statechart diagram activity diagram interaction diagrams: sequence diagram collaboration diagram implementation diagrams: component diagram deployment diagram
Although other names are sometimes given to these diagrams, this list constitutes the canonical diagram names. These diagrams provide multiple perspectives of the system under analysis or development. The underlying model integrates these perspectives so that a selfconsistent system can be analyzed and built. These diagrams, along with supporting documentation, are the primary artifacts that a modeler sees, although the UML and supporting tools will provide for a number of derivative views. These diagrams are further described in the UML Notation Guide (Chapter 3 of this specification).
1-2
OMG-Unified Modeling Language, v1.5
March 2003
1 UML Summary
A frequently asked question has been: Why doesnt UML support data-flow diagrams? Simply put, data-flow and other diagram types that were not included in the UML do not fit as cleanly into a consistent object-oriented paradigm. Activity diagrams and collaboration diagrams accomplish much of what people want from DFDs, and then some. Activity diagrams are also useful for modeling workflow.
1.3 Motivation to Define the UML
This section describes several factors motivating the UML and includes why modeling is essential. It highlights a few key trends in the software industry and describes the issues caused by divergence of modeling approaches.
1.3.1 Why We Model
Developing a model for an industrial-strength software system prior to its construction or renovation is as essential as having a blueprint for large building. Good models are essential for communication among project teams and to assure architectural soundness. We build models of complex systems because we cannot comprehend any such system in its entirety. As the complexity of systems increase, so does the importance of good modeling techniques. There are many additional factors of a projects success, but having a rigorous modeling language standard is one essential factor. A modeling language must include:
Model elements fundamental modeling concepts and semantics Notation visual rendering of model elements Guidelines idioms of usage within the trade
In the face of increasingly complex systems, visualization and modeling become essential. The UML is a well-defined and widely accepted response to that need. It is the visual modeling language of choice for building object-oriented and componentbased systems.
1.3.2 Industry Trends in Software
As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software. We look for techniques to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns, and frameworks. We also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, we recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing, and fault tolerance. Development for the worldwide web makes some things simpler, but exacerbates these architectural problems. Complexity will vary by application domain and process phase. One of the key motivations in the minds of the UML developers was to create a set of semantics and notation that adequately addresses all scales of architectural complexity, across all domains.
March 2003
OMG-Unified Modeling Language, v1.5
1-3
1 UML Summary
1.3.3 Prior to Industry Convergence
Prior to the UML, there was no clear leading modeling language. Users had to choose from among many similar modeling languages with minor differences in overall expressive power. Most of the modeling languages shared a set of commonly accepted concepts that are expressed slightly differently in various languages. This lack of agreement discouraged new users from entering the object technology market and from doing object modeling, without greatly expanding the power of modeling. Users longed for the industry to adopt one, or a very few, broadly supported modeling languages suitable for general-purpose usage. Some vendors were discouraged from entering the object modeling area because of the need to support many similar, but slightly different, modeling languages. In particular, the supply of add-on tools has been depressed because small vendors cannot afford to support many different formats from many different front-end modeling tools. It is important to the entire object industry to encourage broadly based tools and vendors, as well as niche products that cater to the needs of specialized groups. The perpetual cost of using and supporting many modeling languages motivated many companies producing or using object technology to endorse and support the development of the UML. While the UML does not guarantee project success, it does improve many things. For example, it significantly lowers the perpetual cost of training and retooling when changing between projects or organizations. It provides the opportunity for new integration between tools, processes, and domains. But most importantly, it enables developers to focus on delivering business value and gives them a paradigm to accomplish this.
1.4 Goals of the UML
The primary design goals of the UML are as follows:
Provide users with a ready-to-use, expressive visual modeling language to develop and exchange meaningful models. Furnish extensibility and specialization mechanisms to extend the core concepts. Support specifications that are independent of particular programming languages and development processes. Provide a formal basis for understanding the modeling language. Encourage the growth of the object tools market. Support higher-level development concepts such as components, collaborations, frameworks and patterns. Integrate best practices.
These goals are discussed in detail below.
1-4
OMG-Unified Modeling Language, v1.5
March 2003
1 UML Summary
Provide users with a ready-to-use, expressive visual modeling language to develop and exchange meaningful models
It is important that the Object Analysis and Design (OA&D) standard supports a modeling language that can be used out of the box to do normal general-purpose modeling tasks. If the standard merely provides a meta-meta-description that requires tailoring to a particular set of modeling concepts, then it will not achieve the purpose of allowing users to exchange models without losing information or without imposing excessive work to map their models to a very abstract form. The UML consolidates a set of core modeling concepts that are generally accepted across many current methods and modeling tools. These concepts are needed in many or most large applications, although not every concept is needed in every part of every application. Specifying a meta-meta-level format for the concepts is not sufficient for model users, because the concepts must be made concrete for real modeling to occur. If the concepts in different application areas were substantially different, then such an approach might work, but the core concepts needed by most application areas are similar and should be supported directly by the standard without the need for another layer.
Furnish extensibility and specialization mechanisms to extend the core concepts
OMG expects that the UML will be tailored as new needs are discovered and for specific domains. At the same time, we do not want to force the common core concepts to be redefined or re-implemented for each tailored area. Therefore, we believe that the extension mechanisms should support deviations from the common case, rather than being required to implement the core modeling concepts themselves. The core concepts should not be changed more than necessary. Users need to be able to
build models using core concepts without using extension mechanisms for most normal applications, add new concepts and notations for issues not covered by the core, choose among variant interpretations of existing concepts, when there is no clear consensus, and specialize the concepts, notations, and constraints for particular application domains.
Support specifications that are independent of particular programming languages and development processes
The UML must and can support all reasonable programming languages. It also must and can support various methods and processes of building models. The UML can support multiple programming languages and development methods without excessive difficulty.
Provide a formal basis for understanding the modeling language
Because users will use formality to help understand the language, it must be both precise and approachable; a lack of either dimension damages its usefulness. The formalisms must not require excessive levels of indirection or layering, use of lowlevel mathematical notations distant from the modeling domain, such as set-theoretic notation, or operational definitions that are equivalent to programming an
March 2003
OMG-Unified Modeling Language, v1.5
1-5
1 UML Summary
implementation. The UML provides a formal definition of the static format of the model using a metamodel expressed in UML class diagrams. This is a popular and widely accepted formal approach for specifying the format of a model and directly leads to the implementation of interchange formats. UML expresses well-formedness constraints in precise natural language plus Object Constraint Language expressions. UML expresses the operational meaning of most constructs in precise natural language. The fully formal approach taken to specify languages such as Algol-68 was not approachable enough for most practical usage.
Encourage the growth of the object tools market
By enabling vendors to support a standard modeling language used by most users and tools, the industry benefits. While vendors still can add value in their tool implementations, enabling interoperability is essential. Interoperability requires that models can be exchanged among users and tools without loss of information. This can only occur if the tools agree on the format and meaning of all of the relevant concepts. Using a higher meta-level is no solution unless the mapping to the user-level concepts is included in the standard.
Support higher-level development concepts such as components, collaborations, frameworks, and patterns
Clearly defined semantics of these concepts is essential to reap the full benefit of object-orientation and reuse. Defining these within the holistic context of a modeling language is a unique contribution of the UML.
Integrate best practices
A key motivation behind the development of the UML has been to integrate the best practices in the industry, encompassing widely varying views based on levels of abstraction, domains, architectures, life cycle stages, implementation technologies, etc. The UML is indeed such an integration of best practices.
1.5 Scope of the UML
The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system. First and foremost, the Unified Modeling Language fuses the concepts of Booch, OMT, and OOSE. The result is a single, common, and widely usable modeling language for users of these and other methods. Second, the Unified Modeling Language pushes the envelope of what can be done with existing methods. As an example, the UML authors targeted the modeling of concurrent, distributed systems to assure the UML adequately addresses these domains. Third, the Unified Modeling Language focuses on a standard modeling language, not a standard process. Although the UML must be applied in the context of a process, it is our experience that different organizations and problem domains require different processes. (For example, the development process for shrink-wrapped software is an interesting one, but building shrink-wrapped software is vastly different from building
1-6
OMG-Unified Modeling Language, v1.5
March 2003
1 UML Summary
hard-real-time avionics systems upon which lives depend.) Therefore, the efforts concentrated first on a common metamodel (which unifies semantics) and second on a common notation (which provides a human rendering of these semantics). The UML authors promote a development process that is use-case driven, architecture centric, and iterative and incremental. The UML specifies a modeling language that incorporates the object-oriented communitys consensus on core modeling concepts. It allows deviations to be expressed in terms of its extension mechanisms. The Unified Modeling Language provides the following:
Semantics and notation to address a wide variety of contemporary modeling issues in a direct and economical fashion. Semantics to address certain expected future modeling issues, specifically related to component technology, distributed computing, frameworks, and executability. Extensibility mechanisms so individual projects can extend the metamodel for their application at low cost. We dont want users to directly change the UML metamodel. Extensibility mechanisms so that future modeling approaches could be grown on top of the UML. Semantics to facilitate model interchange among a variety of tools. Semantics to specify the interface to repositories for the sharing and storage of model artifacts.
1.5.1 Outside the Scope of the UML
1.5.1.1 Programming Languages
The UML, a visual modeling language, is not intended to be a visual programming language, in the sense of having all the necessary visual and semantic support to replace programming languages. The UML is a language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system, but it does draw the line as you move toward code. For example, complex branches and joins are better expressed in a textual programming language. The UML does have a tight mapping to a family of object languages so that you can get the best of both worlds.
1.5.1.2 Tools
Standardizing a language is necessarily the foundation for tools and process. Tools and their interoperability are very dependent on a solid semantic and notation definition, such as the UML provides. The UML defines a semantic metamodel, not a tool interface, storage, or run-time model, although these should be fairly close to one another.
March 2003
OMG-Unified Modeling Language, v1.5
1-7
1 UML Summary
The UML documents do include some tips to tool vendors on implementation choices, but do not address everything needed. For example, they dont address topics like diagram coloring, user navigation, animation, storage/implementation models, or other features.
1.5.1.3 Process
Many organizations will use the UML as a common language for its project artifacts, but will use the same UML diagram types in the context of different processes. The UML is intentionally process independent, and defining a standard process was not a goal of the UML or OMGs RFP. The UML authors do recognize the importance of process. The presence of a welldefined and well-managed process is often a key discriminator between hyperproductive projects and unsuccessful ones. The reliance upon heroic programming is not a sustainable business practice. A process
provides guidance as to the order of a teams activities, specifies what artifacts should be developed, directs the tasks of individual developers and the team as a whole, and offers criteria for monitoring and measuring a projects products and activities.
Processes by their very nature must be tailored to the organization, culture, and problem domain at hand. What works in one context (shrink-wrapped software development, for example) would be a disaster in another (hard-real-time, human-rated systems, for example). The selection of a particular process will vary greatly, depending on such things as problem domain, implementation technology, and skills of the team. Booch, OMT, OOSE, and many other methods have well-defined processes, and the UML can support most methods. There has been some convergence on development process practices, but there is not yet consensus for standardization. What will likely result is general agreement on best practices and potentially the embracing of a process framework, within which individual processes can be instantiated. Although the UML does not mandate a process, its developers have recognized the value of a use-case driven, architecture-centric, iterative, and incremental process, so were careful to enable (but not require) this with the UML.
1.5.2 Comparing UML to Other Modeling Languages
It should be made clear that the Unified Modeling Language is not a radical departure from Booch, OMT, or OOSE, but rather the legitimate successor to all three. This means that if you are a Booch, OMT, or OOSE user today, your training, experience, and tools will be preserved, because the Unified Modeling Language is a natural evolutionary step. The UML will be equally easy to adopt for users of many other methods, but their authors must decide for themselves whether to embrace the UML concepts and notation underneath their methods.
1-8
OMG-Unified Modeling Language, v1.5
March 2003
1 UML Summary
The Unified Modeling Language is more expressive yet cleaner and more uniform than Booch, OMT, OOSE, and other methods. This means that there is value in moving to the Unified Modeling Language, because it will allow projects to model things they could not have done before. Users of most other methods and modeling languages will gain value by moving to the UML, since it removes the unnecessary differences in notation and terminology that obscure the underlying similarities of most of these approaches. With respect to other visual modeling languages, including entity-relationship modeling, BPR flow charts, and state-driven languages, the UML should provide improved expressiveness and holistic integrity. Users of existing methods will experience slight changes in notation, but this should not take much relearning and will bring a clarification of the underlying semantics. If the unification goals have been achieved, UML will be an obvious choice when beginning new projects, especially as the availability of tools, books, and training becomes widespread. Many visual modeling tools support existing notations, such as Booch, OMT, OOSE, or others, as views of an underlying model; when these tools add support for UML (as some already have) users will enjoy the benefit of switching their current models to the UML notation without loss of information. Existing users of any object method can expect a fairly quick learning curve to achieve the same expressiveness as they previously knew. One can quickly learn and use the basics productively. More advanced techniques, such as the use of stereotypes and properties, will require some study since they enable very expressive and precise models needed only when the problem at hand requires them.
1.5.3 Features of the UML
The goals of the unification efforts were to keep it simple, to cast away elements of existing Booch, OMT, and OOSE that didnt work in practice, to add elements from other methods that were more effective, and to invent new only when an existing solution was not available. Because the UML authors were in effect designing a language (albeit a graphical one), they had to strike a proper balance between minimalism (everything is text and boxes) and over-engineering (having an icon for every conceivable modeling element). To that end, they were very careful about adding new things, because they didnt want to make the UML unnecessarily complex. Along the way, however, some things were found that were advantageous to add because they have proven useful in practice in other modeling. There are several new concepts that are included in UML, including
extensibility mechanisms (stereotypes, tagged values, and constraints), threads and processes, distribution and concurrency (e.g., for modeling ActiveX/DCOM and CORBA), patterns/collaborations, activity diagrams (for business process modeling), refinement (to handle relationships between levels of abstraction),
March 2003
OMG-Unified Modeling Language, v1.5
1-9
1 UML Summary
interfaces and components, and a constraint language.
Many of these ideas were present in various individual methods and theories but UML brings them together into a coherent whole. In addition to these major changes, there are many other localized improvements over the Booch, OMT, and OOSE semantics and notation. The UML is an evolution from Booch, OMT, OOSE, other object-oriented methods, and many other sources. These various sources incorporated many different elements from many authors, including non-OO influences. The UML notation is a melding of graphical syntax from various sources, with a number of symbols removed (because they were confusing, superfluous, or little used) and with a few new symbols added. The ideas in the UML come from the community of ideas developed by many different people in the object-oriented field. The UML developers did not invent most of these ideas; rather, their role was to select and integrate the best ideas from object modeling and computer-science practices. The actual genealogy of the notation and underlying detailed semantics is complicated, so it is discussed here only to provide context, not to represent precise history. Use-case diagrams are similar in appearance to those in OOSE. Class diagrams are a melding of OMT, Booch, class diagrams of most other object methods. Stereotypes and their corresponding icons can be defined for various diagrams to support other modeling styles. Stereotypes, constraints, and taggedValues are concepts added in UML that did not previously exist in the major modeling languages. Statechart diagrams are substantially based on the statecharts of David Harel with minor modifications. Activity graph diagrams, which share much of the same underlying semantics, are similar to the work flow diagrams developed by many sources including many pre-object sources. Sequence diagrams were found in a variety of object methods under a variety of names (interaction, message trace, and event trace) and date to pre-object days. Collaboration diagrams were adapted from Booch (object diagram), Fusion (object interaction graph), and a number of other sources. Collaborations are now first-class modeling entities, and often form the basis of patterns. The implementation diagrams (component and deployment diagrams) are derived from Boochs module and process diagrams, but they are now component-centered, rather than module-centered and are far better interconnected. Stereotypes are one of the extension mechanisms and extend the semantics of the metamodel. User-defined icons can be associated with given stereotypes for tailoring the UML to specific processes.
1-10
OMG-Unified Modeling Language, v1.5
March 2003
1 UML Summary
Object Constraint Language is used by UML to specify the semantics and is provided as a language for expressions during modeling. OCL is an expression language having its root in the Syntropy method and has been influenced by expression languages in other methods like Catalysis. The informal navigation from OMT has the same intent, where OCL is formalized and more extensive. Each of these concepts has further predecessors and many other influences. We realize that any brief list of influences is incomplete and we recognize that the UML is the product of a long history of ideas in the computer science and software engineering area.
1.6 UML - Past, Present, and Future
The UML was developed by Rational Software and its partners. Many companies are incorporating the UML as a standard into their development process and products, which cover disciplines such as business modeling, requirements management, analysis & design, programming, and testing.
1.6.1 UML 0.8 - 0.91
1.6.1.1 Precursors to UML
Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as various methodologists experimented with different approaches to object-oriented analysis and design. Several other techniques influenced these languages, including Entity-Relationship modeling, the Specification & Description Language (SDL, circa 1976, CCITT), and other techniques. The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Many users of object methods had trouble finding complete satisfaction in any one modeling language, fueling the method wars. By the mid1990s, new iterations of these methods began to appear, most notably Booch93, the continued evolution of OMT, and Fusion. These methods began to incorporate each others techniques, and a few clearly prominent methods emerged, including the OOSE, OMT-2, and Booch93 methods. Each of these was a complete method, and was recognized as having certain strengths. In simple terms, OOSE was a use-case oriented approach that provided excellent support business engineering and requirements analysis. OMT-2 was especially expressive for analysis and data-intensive information systems. Booch93 was particularly expressive during design and construction phases of projects and popular for engineering-intensive applications.
1.6.1.2 Booch, Rumbaugh, and Jacobson Join Forces
The development of UML began in October of 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. Given that the Booch and OMT methods were already independently growing together and were collectively recognized as leading object-oriented methods worldwide, Booch and Rumbaugh joined forces to forge a complete unification of their work. A draft version 0.8 of the
March 2003
OMG-Unified Modeling Language, v1.5
1-11
1 UML Summary
Unified Method, as it was then called, was released in October of 1995. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method. The Objectory name is now used within Rational primarily to describe its UML-compliant process, the Rational Unified Process. As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. First, these methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well. As they began their unification, they established four goals to focus their efforts: 1. Enable the modeling of systems (and not just software) using object-oriented concepts. 2. Establish an explicit coupling to conceptual as well as executable artifacts. 3. Address the issues of scale inherent in complex, mission-critical systems. 4. Create a modeling language usable by both humans and machines. Devising a notation for use in object-oriented analysis and design is not unlike designing a programming language. There are tradeoffs. First, one must bound the problem: Should the notation encompass requirement specification? (Yes, partially.) Should the notation extend to the level of a visual programming language? (No.) Second, one must strike a balance between expressiveness and simplicity: Too simple a notation will limit the breadth of problems that can be solved; too complex a notation will overwhelm the mortal developer. In the case of unifying existing methods, one must also be sensitive to the installed base: Make too many changes, and you will confuse existing users. Resist advancing the notation, and you will miss the opportunity of engaging a much broader set of users. The UML definition strives to make the best tradeoffs in each of these areas. The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and 0.91 documents in June and October of 1996. During 1996, the UML authors invited and received feedback from the general community. They incorporated this feedback, but it was clear that additional focused attention was still required.
1.6.2 UML Partners
During 1996, it became clear that several organizations saw UML as strategic to their business. A Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a
1-12
OMG-Unified Modeling Language, v1.5
March 2003
1 UML Summary
joint RFP response. Rational established the UML Partners consortium with several organizations willing to dedicate resources to work toward a strong UML definition. Those contributing most to the UML definition included: Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, and Unisys. This collaboration produced UML, a modeling language that was well defined, expressive, powerful, and generally applicable. In January 1997 IBM & ObjecTime; Platinum Technology; Ptech; Taskon & Reich Technologies; and Softeam also submitted separate RFP responses to the OMG. These companies joined the UML partners to contribute their ideas, and together the partners produced the revised UML 1.1 response. The focus of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. This document is based on the UML 1.1 release and is the result of a collaborative team effort. The UML Partners have worked hard as a team to define UML. While each partner came in with their own perspective and areas of interest, the result has benefited from each of them and from the diversity of their experiences. The UML Partners contributed a variety of expert perspectives, including, but not limited to, the following: OMG and RM-ODP technology perspectives, business modeling, constraint language, state machine semantics, types, interfaces, components, collaborations, refinement, frameworks, distribution, and metamodel.
1.6.3 UML - Present and Future
The UML is nonproprietary and open to all. It addresses the needs of user and scientific communities, as established by experience with the underlying methods on which it is based. Many methodologists, organizations, and tool vendors have committed to use it. Since the UML builds upon similar semantics and notation from Booch, OMT, OOSE, and other leading methods and has incorporated input from the UML partners and feedback from the general public, widespread adoption of the UML should be straightforward. There are two aspects of unified that the UML achieves: First, it effectively ends many of the differences, often inconsequential, between the modeling languages of previous methods. Secondly, and perhaps more importantly, it unifies the perspectives among many different kinds of systems (business versus software), development phases (requirements analysis, design, and implementation), and internal concepts.
1.6.3.1 Standardization of the UML
Many organizations have already endorsed the UML as their organizations standard, since it is based on the modeling languages of leading object methods. The UML is ready for widespread use. This document is suitable as the primary source for authors writing books and training materials, as well as developers implementing visual modeling tools. Additional collateral, such as articles, training courses, examples, and books, will soon make the UML very approachable for a wide audience.
March 2003
OMG-Unified Modeling Language, v1.5
1-13
1 UML Summary
The Unified Modeling Language v. 1.1 specification which was added to the list of OMG Adopted Technologies in November 1997. Since then the OMG has assumed responsibility for the further development of the UML standard.
1.6.3.2 Revision of the UML
After adoption of the UML 1.1 specification by the OMG membership in November 1997, the OMG chartered a revision task force (RTF) to accept comments from the general public and to make revisions to the specifications to handle bugs, inconsistencies, ambiguities, and minor omissions that could be handled without a major change in scope from the original specification. The members of the RTF were drawn from the original proposers with a few additional persons. The RTF issued several preliminary reports with the final report containing UML 1.3 scheduled for the second quarter of 1999. It contained a number of changes to the UML metamodel, semantics, and notation, but in the big picture this version should be considered a minor upgrade to the original specification. More substantive changes and expansion in scope requires the full OMG specification and adoption process.
1.6.3.3 Industrialization
Many organizations and vendors worldwide have already embraced the UML. The number of endorsing organizations is expected to grow significantly over time. These organizations will continue to encourage the use of the Unified Modeling Language by making the definition readily available and by encouraging other methodologists, tool vendors, training organizations, and authors to adopt the UML. The real measure of the UMLs success is its use on successful projects and the increasing demand for supporting tools, books, training, and mentoring.
1.6.3.4 Future UML Evolution
Although the UML defines a precise language, it is not a barrier to future improvements in modeling concepts. We have addressed many leading-edge techniques, but expect additional techniques to influence future versions of the UML. Many advanced techniques can be defined using UML as a base. The UML can be extended without redefining the UML core. The UML, in its current form, is expected to be the basis for many tools, including those for visual modeling, simulation, and development environments. As interesting tool integrations are developed, implementation standards based on the UML will become increasingly available. The UML has integrated many disparate ideas, so this integration will accelerate the use of object-orientation. Component-based development is an approach worth mentioning. It is synergistic with traditional object-oriented techniques. While reuse based on components is becoming increasingly widespread, this does not mean that component-based techniques will replace object-oriented techniques. There are only subtle differences between the semantics of components and classes.
1-14
OMG-Unified Modeling Language, v1.5
March 2003
UML Semantics
2
Note Change bars mark the differences between UML 1.4 and UML 1.5. Changes based on the ISO version of UML 1.4.1 (formal/03-02-04) are in this font.
Contents
This chapter contains the following sections. Section Title Part 1 - Background Introduction Language Architecture Language Formalism Part 2 - Foundation Foundation Package Core Extension Mechanisms Data Types Part 3 - Behavioral Elements Behavioral Elements Package Common Behavior Collaborations Use Cases 2-92 2-93 2-111 2-129 2-11 2-12 2-73 2-85 2-2 2-4 2-7 Page
March 2003
OMG-Unified Modeling Language, v1.5
2-1
2 UML Semantics
Section Title State Machines Activity Graphs Actions Part 4 - General Mechanisms Model Management Part 5- Actions Action Package Actions Overview Action Conventions Action Foundation Composite Actions Read and Write Actions Computation Actions Collection Actions Messaging Actions Jump Actions
Page 2-140 2-170 2-181
2-181
2-199 2-200 2-207 2-211 2-228 2-252 2-287 2-296 2-311 2-332
Part 1 - Background
2.1 Introduction
2.1.1 Purpose and Scope
The primary audience for this detailed description consists of the OMG, other standards organizations, tool builders, metamodelers, methodologists, and expert modelers. The authors assume familiarity with metamodeling and advanced object mod...
03-03-01