OMG Unified Modeling Language Specification


OMG Unified 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. March 2003 OMG-Unified Modeling Language, v1.5 v Contents Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii 1 UML Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 1.2 Primary Artifacts of the UML . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 1.2.1 UML-defining Artifacts. . . . . . . . . . . . . . . . . . . . . . 1-2 1.2.2 Development Project Artifacts. . . . . . . . . . . . . . . . . 1-2 1.3 Motivation to Define the UML . . . . . . . . . . . . . . . . . . . . . . . . 1-3 1.3.1 Why We Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 1.3.2 Industry Trends in Software . . . . . . . . . . . . . . . . . . 1-3 1.3.3 Prior to Industry Convergence . . . . . . . . . . . . . . . . . 1-4 1.4 Goals of the UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 1.5 Scope of the UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6 1.5.1 Outside the Scope of the UML . . . . . . . . . . . . . . . . 1-7 1.5.2 Comparing UML to Other Modeling Languages. . . 1-8 1.5.3 Features of the UML . . . . . . . . . . . . . . . . . . . . . . . . 1-9 1.6 UML - Past, Present, and Future . . . . . . . . . . . . . . . . . . . . . . 1-11 1.6.1 UML 0.8 - 0.91 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11 1.6.2 UML Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12 1.6.3 UML - Present and Future . . . . . . . . . . . . . . . . . . . . 1-13 2 UML Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Part 1 - Background vi OMG-Unified Modeling Language, v1.5 March 2003 2.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 2.1.1 Purpose and Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 2.1.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 2.2 Language Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 2.2.1 Four-layer Metamodel Architecture . . . . . . . . . . . . 2-4 2.2.2 Package Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 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 Part 2 - Foundation 2.4 Foundation Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 2.5 Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 2.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 2.5.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 2.5.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2-51 2.5.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2-64 2.6 Extension Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-73 2.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-73 2.6.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-75 2.6.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2-80 2.6.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2-82 2.6.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-83 2.7 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85 2.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85 2.7.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-85 Part 3 - Behavioral Elements 2.8 Behavioral Elements Package . . . . . . . . . . . . . . . . . . . . . . . . . 2-92 2.9 Common Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-93 2.9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-93 2.9.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-94 2.9.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2-103 2.9.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2-109 2.10 Collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-111 2.10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-111 2.10.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-113 2.10.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2-119 March 2003 OMG-Unified Modeling Language, v1.5 vii 2.10.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2-124 2.10.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-129 2.11 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-129 2.11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-129 2.11.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-130 2.11.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2-133 2.11.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2-135 2.11.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-140 2.12 State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-140 2.12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-140 2.12.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-141 2.12.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2-150 2.12.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2-154 2.12.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-165 2.13 Activity Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-170 2.13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-170 2.13.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-170 2.13.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2-175 2.13.4 Detailed Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 2-178 2.13.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-181 2.14 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-181 Part 4 - General Mechanisms 2.15 Model Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-181 2.15.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-181 2.15.2 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-182 2.15.3 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . 2-186 2.15.4 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-192 2.15.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-198 Part 5 - Actions 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 viii OMG-Unified Modeling Language, v1.5 March 2003 2.19.2 Action Execution Model . . . . . . . . . . . . . . . . . . . . . 2-214 2.19.3 Action Foundation Classes . . . . . . . . . . . . . . . . . . . 2-219 2.20 Composite Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-228 2.20.1 Composite Action Specification . . . . . . . . . . . . . . . 2-228 2.20.2 Composite Action Execution. . . . . . . . . . . . . . . . . . 2-234 2.20.3 Composite Action Classes. . . . . . . . . . . . . . . . . . . . 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 March 2003 OMG-Unified Modeling Language, v1.5 ix 2.25.1 Jumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-332 2.25.2 Break and Continue Statements. . . . . . . . . . . . . . . . 2-334 2.25.3 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-335 2.25.4 Jumps with Concurrent Executions . . . . . . . . . . . . . 2-336 2.25.5 Jump Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-336 2.25.6 Additional Jump Semantics for Actions Defined Elsewhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-340 2.25.7 Jump Value Classes . . . . . . . . . . . . . . . . . . . . . . . . . 2-342 3 UML Notation Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 Part 1 - Background 3.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5 Part 2 - Diagram Elements 3.2 Graphs and Their Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 3.3 Drawing Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 3.4 Invisible Hyperlinks and the Role of Tools . . . . . . . . . . . . . . . 3-7 3.5 Background Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 3.5.1 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-8 3.6 String. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 3.6.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 3.6.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 3.6.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-9 3.6.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 3.6.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 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 3.8 Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 3.8.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 3.8.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 3.8.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-11 3.8.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 3.9 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 3.10 Expression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 3.10.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 3.10.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 3.10.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 3.10.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 x OMG-Unified Modeling Language, v1.5 March 2003 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-13 3.11.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3.11.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3.11.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3.11.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 3.11.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 3.12 Type-Instance Correspondence . . . . . . . . . . . . . . . . . . . . . . . . 3-14 Part 3 - Model Management 3.13 Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16 3.13.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16 3.13.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16 3.13.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-17 3.13.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 3.13.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 3.13.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19 3.14 Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19 3.14.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19 3.14.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19 3.14.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-20 3.14.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21 3.14.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24 3.15 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24 3.15.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24 3.15.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24 3.15.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-25 3.15.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25 3.15.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26 Part 4 - General Extension Mechanisms 3.16 Constraint and Comment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26 3.16.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26 3.16.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27 3.16.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28 3.16.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28 3.17 Element Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29 3.17.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29 3.17.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29 March 2003 OMG-Unified Modeling Language, v1.5 xi 3.17.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-30 3.17.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31 3.17.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31 3.17.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31 3.18 Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31 3.18.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31 3.18.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-31 3.18.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32 3.18.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33 Part 5 - Static Structure Diagrams 3.19 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 3.19.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 3.19.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 3.19.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34 3.20 Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 3.21 Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 3.22 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 3.22.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-35 3.22.2 Basic Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36 3.22.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-36 3.22.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36 3.22.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37 3.22.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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-38 3.24.1 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38 3.24.2 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-39 3.24.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40 3.24.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41 3.25 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41 3.25.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41 3.25.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42 3.25.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-43 3.25.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44 3.25.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44 3.25.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44 3.26 Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44 xii OMG-Unified Modeling Language, v1.5 March 2003 3.26.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44 3.26.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44 3.26.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-46 3.26.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47 3.26.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47 3.26.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47 3.27 Nested Class Declarations. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48 3.27.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48 3.27.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48 3.27.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48 3.28 Type and Implementation Class . . . . . . . . . . . . . . . . . . . . . . . 3-49 3.28.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49 3.28.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49 3.28.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50 3.28.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50 3.29 Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50 3.29.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50 3.29.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51 3.29.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51 3.29.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52 3.30 Parameterized Class (Template) . . . . . . . . . . . . . . . . . . . . . . . 3-52 3.30.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52 3.30.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53 3.30.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-53 3.30.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54 3.30.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54 3.31 Bound Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54 3.31.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54 3.31.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55 3.31.3 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55 3.31.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55 3.31.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55 3.32 Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56 3.32.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56 3.32.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56 3.32.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56 3.32.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56 3.33 Metaclass. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.33.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.33.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 March 2003 OMG-Unified Modeling Language, v1.5 xiii 3.33.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.34 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.34.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.34.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.34.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.35 Stereotype Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.35.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57 3.35.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58 3.35.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61 3.36 Powertype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61 3.36.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61 3.36.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61 3.36.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61 3.37 Class Pathnames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61 3.37.1 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61 3.37.2 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62 3.37.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62 3.38 Accessing or Importing a Package . . . . . . . . . . . . . . . . . . . . . 3-62 3.38.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62 3.38.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63 3.38.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64 3.38.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64 3.39 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64 3.39.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64 3.39.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64 3.39.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-65 3.39.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66 3.39.5 Variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66 3.39.6 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66 3.39.7 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-66 3.40 Composite Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67 3.40.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67 3.40.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67 3.40.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67 3.40.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 xiv OMG-Unified Modeling Language, v1.5 March 2003 3.42.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-69 3.42.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69 3.42.5 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69 3.42.6 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70 3.42.7 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-70 3.43 Association End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71 3.43.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71 3.43.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71 3.43.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-73 3.43.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-74 3.43.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-74 3.43.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-74 3.44 Multiplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75 3.44.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75 3.44.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75 3.44.3 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75 3.44.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75 3.44.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76 3.45 Qualifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76 3.45.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76 3.45.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76 3.45.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-77 3.45.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77 3.45.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77 3.45.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77 3.46 Association Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77 3.46.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77 3.46.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-78 3.46.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-78 3.46.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-78 3.46.5 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-78 3.46.6 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79 3.47 N-ary Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79 3.47.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79 3.47.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79 3.47.3 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79 3.47.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-80 3.47.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-80 3.48 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81 3.48.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81 March 2003 OMG-Unified Modeling Language, v1.5 xv 3.48.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81 3.48.3 Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 3-82 3.48.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83 3.48.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-84 3.49 Link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-84 3.49.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-84 3.49.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-84 3.49.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-85 3.49.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-85 3.50 Generalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86 3.50.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86 3.50.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86 3.50.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-87 3.50.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-88 3.50.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-89 3.51 Dependency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-90 3.51.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-90 3.51.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-90 3.51.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-91 3.51.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-92 3.51.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93 3.52 Derived Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93 3.52.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93 3.52.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93 3.52.3 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93 3.53 InstanceOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93 3.53.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93 3.53.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93 3.53.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93 Part 6 - Use Case Diagrams 3.54 Use Case Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-94 3.54.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-94 3.54.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-94 3.54.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-95 3.54.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-95 3.55 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96 3.55.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96 3.55.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96 3.55.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-96 xvi OMG-Unified Modeling Language, v1.5 March 2003 3.55.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96 3.55.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.56 Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.56.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.56.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.56.3 Presentation Options . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.56.4 Style Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.56.5 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.57 Use Case Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.57.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-97 3.57.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-98 3.57.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-99 3.57.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 March 2003 OMG-Unified Modeling Language, v1.5 xvii 3.63.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111 3.63.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111 3.63.3 Presentation options . . . . . . . . . . . . . . . . . . . . . . . . 3-111 3.63.4 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-113 3.63.5 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 xviii OMG-Unified Modeling Language, v1.5 March 2003 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 March 2003 OMG-Unified Modeling Language, v1.5 xix 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 xx OMG-Unified Modeling Language, v1.5 March 2003 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 March 2003 OMG-Unified Modeling Language, v1.5 xxi 3.95.1 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-169 3.95.2 Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-169 3.95.3 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-170 3.95.4 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Example 1 - UML Profile for Software Development Processes 4.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 4.2 Summary of Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 4.3 Stereotypes and Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2 4.3.1 Use Case Stereotypes . . . . . . . . . . . . . . . . . . . . . . . 4-3 4.3.2 Analysis Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . 4-4 4.3.3 Design Stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . 4-5 4.3.4 Implementation Stereotypes . . . . . . . . . . . . . . . . . . 4-6 4.3.5 Class Stereotypes. . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7 4.3.6 Association Stereotypes . . . . . . . . . . . . . . . . . . . . . 4-8 4.4 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 4.4.1 Generalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 4.4.2 Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 Example 2 - UML Profile for Business Modeling 4.5 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 4.6 Summary of Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 4.7 Stereotypes and Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 4.7.1 Use Case Stereotypes . . . . . . . . . . . . . . . . . . . . . . . 4-11 xxii OMG-Unified Modeling Language, v1.5 March 2003 4.7.2 Organization Stereotypes. . . . . . . . . . . . . . . . . . . . . 4-12 4.7.3 Class Stereotypes. . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13 4.7.4 Association Stereotypes . . . . . . . . . . . . . . . . . . . . . 4-15 4.8 Well-formedness Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15 4.8.1 Generalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15 5 UML Model Interchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 5.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 5.2 Model Interchange Using XMI . . . . . . . . . . . . . . . . . . . . . . . . 5-23 5.3 Model Interchange Using CORBA IDL . . . . . . . . . . . . . . . . . 5-24 6 Object Constraint Language Specification. . . . . . . . . . . . . . . 6-1 6.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 6.1.1 Why OCL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 6.1.2 Where to Use OCL . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 6.2 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 6.2.1 Legend. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 6.2.2 Example Class Diagram . . . . . . . . . . . . . . . . . . . . . 6-4 6.3 Relation to the UML Metamodel . . . . . . . . . . . . . . . . . . . . . . 6-4 6.3.1 Self . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4 6.3.2 Specifying the UML context . . . . . . . . . . . . . . . . . . 6-5 6.3.3 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 6.3.4 Pre- and Postconditions . . . . . . . . . . . . . . . . . . . . . . 6-6 6.3.5 Package context. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6 6.3.6 General Expressions . . . . . . . . . . . . . . . . . . . . . . . . 6-7 6.4 Basic Values and Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7 6.4.1 Types from the UML Model . . . . . . . . . . . . . . . . . . 6-8 6.4.2 Enumeration Types . . . . . . . . . . . . . . . . . . . . . . . . . 6-8 6.4.3 Let Expressions and «definition» Constraints . . . . . 6-8 6.4.4 Type Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 6-9 6.4.5 Re-typing or Casting . . . . . . . . . . . . . . . . . . . . . . . . 6-10 6.4.6 Precedence Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10 6.4.7 Use of Infix Operators . . . . . . . . . . . . . . . . . . . . . . . 6-10 6.4.8 Keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11 6.4.9 Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11 6.4.10 Undefined Values. . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11 6.5 Objects and Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12 6.5.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12 6.5.2 Properties: Attributes. . . . . . . . . . . . . . . . . . . . . . . . 6-12 6.5.3 Properties: Operations . . . . . . . . . . . . . . . . . . . . . . . 6-12 March 2003 OMG-Unified Modeling Language, v1.5 xxiii 6.5.4 Properties: Association Ends and Navigation. . . . . 6-13 6.5.5 Navigation to Association Classes. . . . . . . . . . . . . . 6-15 6.5.6 Navigation from Association Classes . . . . . . . . . . . 6-16 6.5.7 Navigation through Qualified Associations . . . . . . . 6-16 6.5.8 Using Pathnames for Packages . . . . . . . . . . . . . . . . 6-17 6.5.9 Accessing overridden properties of supertypes . . . . 6-17 6.5.10 Predefined properties on All Objects. . . . . . . . . . . . 6-18 6.5.11 Features on Classes Themselves . . . . . . . . . . . . . . . 6-19 6.5.12 Collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19 6.5.13 Collections of Collections . . . . . . . . . . . . . . . . . . . . 6-21 6.5.14 Collection Type Hierarchy and Type Conformance Rules . . . . . . . . . . . . . . . . . . . . . 6-21 6.5.15 Previous Values in Postconditions . . . . . . . . . . . . . . 6-21 6.6 Collection Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22 6.6.1 Select and Reject Operations. . . . . . . . . . . . . . . . . . 6-22 6.6.2 Collect Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24 6.6.3 ForAll Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25 6.6.4 Exists Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26 6.6.5 Iterate Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26 6.6.6 Iterators in Collection Operations . . . . . . . . . . . . . . 6-27 6.6.7 Resolving Properties . . . . . . . . . . . . . . . . . . . . . . . . 6-27 6.7 The Standard OCL Package . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28 6.8 Predefined OCL Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29 6.8.1 Basic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29 6.8.2 Collection-Related Types . . . . . . . . . . . . . . . . . . . . 6-36 6.9 Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-45 UML Standard Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 Action Language Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1 B.1 The Action Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1 B.2 Presentation of the Examples . . . . . . . . . . . . . . . . . . . . . . . . . B-2 B.3 Control Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3 B.4 Object Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6 B.5 Messaging Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19 B.6 Complete Example: The FFT . . . . . . . . . . . . . . . . . . . . . . . . . B-26 B.6.1 The Fast Fourier Transform. . . . . . . . . . . . . . . . . . . B-27 B.6.2 Illustrative Notation. . . . . . . . . . . . . . . . . . . . . . . . . B-28 B.6.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-30 B.6.4 Implementation Using Memory Writes . . . . . . . . . . B-33 xxiv OMG-Unified Modeling Language, v1.5 March 2003 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Glossary -1 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index -1 March 2003 OMG-Unified Modeling Language, v1.5 xxv 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 OMG’s ownership of the UML standard and the public’s 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 xxvi OMG-Unified Modeling Language, v1.5 March 2003 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 OMG’s Meta-Object Facility (MOF) team. The MOF, which represents the state of the art in distributed object repository architectures, is OMG’s 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 March 2003 OMG-Unified Modeling Language, v1.5 xxvii 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 OMG’s 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. xxviii OMG-Unified Modeling Language, v1.5 March 2003 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: +1-781-444-0404 Fax: +1-781-444-0320 pubs@omg.org http://www.omg.org OMG’s 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 CORBA- based 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. March 2003 OMG-Unified Modeling Language, v1.5 xxix 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 OMG’s 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. xxx OMG-Unified Modeling Language, v1.5 March 2003 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 meta- metamodel 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. March 2003 OMG-Unified Modeling Language, v1.5 xxxi 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 meta- metamodel 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 MOF Meta-metamodel OMA Core Object Model CORBA Object Model CORBA IDL Association (n-ary) Association (binary) AssociationClass NA AssociationEnd AssociationEnd Attribute Attribute Attribute Attribute BehavioralFeature BehavioralFeature Class Class Class Interface (as Class) Classifier Classifier Constraint Constraint DataType DataType Data type Data type Dependency (class) /dependsOn (association) Exception Exception Exception Feature Feature GeneralizableElement GeneralizableElement Generalization (class) generalizes (association) Generalization Generalization Interface Class (as Interface) Interface Interface ModelElement ModelElement NA Reference NA Constant Constant Namespace Namespace ~ IR Containers Operation Operation Operation Operation Package Package Module xxxii OMG-Unified Modeling Language, v1.5 March 2003 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 Parameter Parameter Parameter Parameter StructuralFeature StructuralFeature Type (stereotype) Class (as Type) Type Interface (as Type) UML Metamodel MOF Meta-metamodel CORBA Object Model and IDL AggregationKind AggregationKind Boolean CORBA Boolean Boolean Enumeration CORBA Enum Enum Expression NameType Integer CORBA Short, Long, Unsigned Short, Unsigned Long, Double, Octet, Float Short, Long, Unsigned Short, Unsigned Long, Double, Octet, Float Multiplicity MultiplicityType Name NameType Name ParameterDirectionKind DirectionKind ScopeKind ScopeKind String CORBA String, Char String, Char VisibilityKind VisibilityKind UML Metamodel MOF Meta-metamodel OMA Core Object Model CORBA Object Model CORBA IDL March 2003 OMG-Unified Modeling Language, v1.5 xxxiii 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 AssociationEnd’s '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 meta- metamodels is also straightforward. Here also there are more MOF meta- metaobjects 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. xxxiv OMG-Unified Modeling Language, v1.5 March 2003 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 UML’s 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. 2. Well-formedness rules 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. 3. Semantics The semantics of model usage are described in English prose. March 2003 OMG-Unified Modeling Language, v1.5 xxxv UML Notation Guide (Chapter 3) - specifies the graphic syntax for expressing the semantics described by the UML metamodel. Consequently, the UML Notation Guide’s 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. xxxvi OMG-Unified Modeling Language, v1.5 March 2003 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. Foundation Behavioral Elements Model Management Use Cases State MachinesCollaborations Common Behavior Activity Graphs Core Data Types Extension Mec hanisms Actions March 2003 OMG-Unified Modeling Language, v1.5 xxxvii The class diagram illustrates the package dependencies, which are also summarized in the table below. 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: Package Prerequisite Packages DataTypes Core DataTypes, Extension Mechanisms Extension Mechanisms Core, DataTypes Common Behavior Foundation State Machines Common Behavior, Foundation Activity Graphs State Machines, Foundation Collaborations Common Behavior, Foundation Use Cases Common Behavior, Foundation Model Management Foundation Actions Common Behavior, Foundation xxxviii OMG-Unified Modeling Language, v1.5 March 2003 • 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 well- formedness 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. March 2003 OMG-Unified Modeling Language, v1.5 xxxix Summary of Compliance Points 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. Compliance Point Valid Options Foundation no/incomplete, complete, complete including IDL and/or XMI DTD Common Behavior no/incomplete, complete, complete including IDL and/or XMI DTD State Machines no/incomplete, complete, complete including IDL and/or XMI DTD Activity Graphs no/incomplete, complete, complete including IDL and/or XMI DTD Collaboration no/incomplete, complete, complete including IDL and/or XMI DTD Use Cases no/incomplete, complete, complete including IDL and/or XMI DTD Model Management no/incomplete, complete, complete including IDL and/or XMI DTD UML Profiles no/incomplete, complete Use Case diagram no/incomplete, complete Class diagram no/incomplete, complete Statechart diagram no/incomplete, complete Activity Graph diagram no/incomplete, complete Sequence diagram no/incomplete, complete Collaboration diagram no/incomplete, complete Component diagram no/incomplete, complete Deployment diagram no/incomplete, complete Model Interchange Using XMI no/incomplete, complete Model Interchange Using CORBA IDL no/incomplete, complete, reflective interfaces, package-based interfaces OCL no/incomplete, complete xl OMG-Unified Modeling Language, v1.5 March 2003 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 D’Souza • 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 Björkander • 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. March 2003 OMG-Unified Modeling Language, v1.5 xli 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. xlii OMG-Unified Modeling Language, v1.5 March 2003 References [Bock/Odell 94] C. Bock and J. Odell, “A Foundation For Composition,” Journal of Object-Oriented Programming, October 1994. [Booch et al. 99] Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Addison Wesley, 1999. [Cook 94] S. Cook and J. Daniels, Designing Object Systems: Object- oriented Modeling with Syntropy, Prentice-Hall Object-Oriented Series, 1994. [D’Souza 99] D. D’Souza and A. Wills, Objects, Components and Frameworks with UML: The Catalysis Approach, Addison-Wesley, 1999. [Fowler 97] M. Fowler with K. Scott, UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, 1997. [Griss 96] M. Griss, “Domain Engineering And Variability In The Reuse- Driven Software Engineering Business,” Object Magazine. December 1996. [Harel 87] D. Harel, “Statecharts: A Visual Formalism for Complex Systems,” Science of Computer Programming 8, (1987), pp. 231-274. [Harel 96a] D. Harel and E. Gery, “Executable Object Modeling with Statecharts,” Proc. 18th Int. Conf. Soft. Eng., Berlin, IEEE Press, March, 1996, pp. 246-257. [Harel 96b] D. Harel and A. Naamad, “The STATEMATE Semantics of Statecharts,” ACM Trans. Soft. Eng. Method 5:4, October 1996. [Jacobson et al. 99] Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process, Addison Wesley, 1999. [Malan 96] R. Malan, D. Coleman, R. Letsinger et al, “The Next Generation of Fusion,” Fusion Newsletter, October 1996. [Martin/Odell 95] J. Martin and J. Odell, Object-Oriented Methods, A Foundation, Prentice Hall, 1995 [Ramackers 95] 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 96] Ramackers, G. and Clegg, D., “Extended Use Cases and Business Objects for BPR,” ObjectWorld UK ‘96, London, June 18-21, 1996. [Rumbaugh et al. 99] Jim Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language Reference Manual, Addison Wesley, 1999. March 2003 OMG-Unified Modeling Language, v1.5 xliii [Selic et al. 94] B. Selic, G. Gullekson, and P. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, 1994. [Warmer et al. 99] J. Warmer and A. Kleppe, The Object Constraint Language: Precise Modeling with UML, Addison-Wesley, 1999. [UML Web Sites] OMG UML Resource Page: www.omg.org/uml OMG UML RTF: www.celigent.com/omg/umlrtf xliv OMG-Unified Modeling Language, v1.5 March 2003 March 2003 OMG-Unified Modeling Language, v1.5 1-1 UML Summary 1 The UML Summary provides an introduction to the UML, discussing its motivation and history. Contents This chapter contains the following topics. 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. Topic Page “Overview” 1-1 “Primary Artifacts of the UML” 1-2 “Motivation to Define the UML” 1-3 “Goals of the UML” 1-4 “Scope of the UML” 1-6 “UML - Past, Present, and Future” 1-11 1-2 OMG-Unified Modeling Language, v1.5 March 2003 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 self- consistent 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). March 2003 OMG-Unified Modeling Language, v1.5 1-3 1 UML Summary A frequently asked question has been: Why doesn’t 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 project’s 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 component- based 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. 1-4 OMG-Unified Modeling Language, v1.5 March 2003 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. March 2003 OMG-Unified Modeling Language, v1.5 1-5 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 low- level mathematical notations distant from the modeling domain, such as set-theoretic notation, or operational definitions that are equivalent to programming an 1-6 OMG-Unified Modeling Language, v1.5 March 2003 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 March 2003 OMG-Unified Modeling Language, v1.5 1-7 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 community’s 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 don’t 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. 1-8 OMG-Unified Modeling Language, v1.5 March 2003 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 don’t 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 OMG’s RFP. The UML authors do recognize the importance of process. The presence of a well- defined 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 team’s 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 project’s 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. March 2003 OMG-Unified Modeling Language, v1.5 1-9 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 didn’t 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 didn’t 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), 1-10 OMG-Unified Modeling Language, v1.5 March 2003 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 Booch’s 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. March 2003 OMG-Unified Modeling Language, v1.5 1-11 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 mid- 1990s, new iterations of these methods began to appear, most notably Booch’93, the continued evolution of OMT, and Fusion. These methods began to incorporate each other’s techniques, and a few clearly prominent methods emerged, including the OOSE, OMT-2, and Booch’93 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. Booch’93 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 1-12 OMG-Unified Modeling Language, v1.5 March 2003 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 March 2003 OMG-Unified Modeling Language, v1.5 1-13 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 organization’s 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. 1-14 OMG-Unified Modeling Language, v1.5 March 2003 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 UML’s 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. March 2003 OMG-Unified Modeling Language, v1.5 2-1 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 Page Part 1 - Background “Introduction” 2-2 “Language Architecture” 2-4 “Language Formalism” 2-7 Part 2 - Foundation “Foundation Package” 2-11 “Core” 2-12 “Extension Mechanisms” 2-73 “Data Types” 2-85 Part 3 - Behavioral Elements “Behavioral Elements Package” 2-92 “Common Behavior” 2-93 “Collaborations” 2-111 “Use Cases” 2-129 2-2 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 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 modeling. Readers looking for an introduction to the UML or object modeling should consider another source. Although the document is meant for advanced readers, it is also meant to be easily understood by its intended audience. Consequently, it is structured and written to increase readability. The structure of the document, like the language, builds on previous concepts to refine and extend the semantics. In addition, the document is written in a ‘semi-formal’ style that combines natural and formal languages in a complementary manner. “State Machines” 2-140 “Activity Graphs” 2-170 “Actions” 2-181 Part 4 - General Mechanisms “Model Management” 2-181 Part 5- Actions “Action Package” 2-199 “Actions Overview” 2-200 “Action Conventions” 2-207 “Action Foundation” 2-211 “Composite Actions” 2-228 “Read and Write Actions” 2-252 “Computation Actions” 2-287 “Collection Actions” 2-296 “Messaging Actions” 2-311 “Jump Actions” 2-332 Section Title Page March 2003 OMG-Unified Modeling Language, v1.5 2-3 2 UML Semantics This section specifies semantics for structural and behavioral object models. Structural models (also known as static models) emphasize the structure of objects in a system, including their classes, interfaces, attributes and relations. Behavioral models (also known as dynamic models) emphasize the behavior of objects in a system, including their methods, interactions, collaborations, and state histories. This section provides complete semantics for all modeling notations described in the UML Notation Guide (Chapter 3). This includes support for a wide range of diagram techniques: class diagram, object diagram, use case diagram, sequence diagram, collaboration diagram, state diagram, activity diagram, and deployment diagram. The UML Notation Guide includes a summary of the semantics sections that are relevant to each diagram technique. 2.1.2 Approach This section emphasizes language architecture and formal rigor. The architecture of the UML is based on a four-layer metamodel structure, which consists of the following layers: user objects, model, metamodel, and meta-metamodel. This document is primarily concerned with the metamodel layer, which is an instance of the meta- metamodel layer. For example, Class in the metamodel is an instance of MetaClass in the meta-metamodel. The metamodel architecture of UML is discussed further in Section 2.2, “Language Architecture,” on page 2-4. The UML metamodel is a logical model and not a physical (or implementation) model. The advantage of a logical metamodel is that it emphasizes declarative semantics, and suppresses implementation details. Implementations that use the logical metamodel must conform to its semantics, and must be able to import and export full as well as partial models. However, tool vendors may construct the logical metamodel in various ways, so they can tune their implementations for reliability and performance. The disadvantage of a logical model is that it lacks the imperative semantics required for accurate and efficient implementation. Consequently, the metamodel is accompanied with implementation notes for tool builders. UML is also structured within the metamodel layer. The language is decomposed into several logical packages: Foundation, Behavioral Elements, and Model Management. These packages in turn are decomposed into subpackages. For example, the Foundation package consists of the Core, Extension Mechanisms, and Data Types subpackages. The structure of the language is fully described in Section 2.2, “Language Architecture,” on page 2-4. The metamodel is described in a semi-formal manner using these views: • Abstract syntax • Well-formedness rules • Semantics The abstract syntax is provided as a model described in a subset of UML, consisting of a UML class diagram and a supporting natural language description. (In this way the UML bootstraps itself in a manner similar to how a compiler is used to compile itself.) The well-formedness rules are provided using a formal language (Object Constraint 2-4 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Language) and natural language (English). Finally, the semantics are described primarily in natural language, but may include some additional notation, depending on the part of the model being described. The adaptation of formal techniques to specify the language is fully described in Section 2.3, “Language Formalism,” on page 2-7. In summary, the UML metamodel is described in a combination of graphic notation, natural language, and formal language. We recognize that there are theoretical limits to what one can express about a metamodel using the metamodel itself. However, our experience suggests that this combination strikes a reasonable balance between expressiveness and readability. 2.2 Language Architecture 2.2.1 Four-layer Metamodel Architecture The UML metamodel is defined as one of the layers of a four-layer metamodeling architecture. This architecture is a proven infrastructure for defining the precise semantics required by complex models. There are several other advantages associated with this approach: • It refines semantic constructs by recursively applying them to successive metalayers. • It provides an architectural basis for defining future UML metamodel extensions. • It furnishes an architectural basis for aligning the UML metamodel with other standards based on a four-layer metamodeling architecture, in particular the OMG Meta-Object Facility (MOF). The generally accepted framework for metamodeling is based on an architecture with four layers: • meta-metamodel • metamodel • model • user objects The functions of these layers are summarized in the following table. March 2003 OMG-Unified Modeling Language, v1.5 2-5 2 UML Semantics . The meta-metamodeling layer forms the foundation for the metamodeling architecture. The primary responsibility of this layer is to define the language for specifying a metamodel. A meta-metamodel defines a model at a higher level of abstraction than a metamodel, and is typically more compact than the metamodel that it describes. A meta-metamodel can define multiple metamodels, and there can be multiple meta- metamodels associated with each metamodel. While it is generally desirable that related metamodels and meta-metamodels share common design philosophies and constructs, this is not a strict rule. Each layer needs to maintain its own design integrity. Examples of meta-metaobjects in the meta- metamodeling layer are: MetaClass, MetaAttribute, and MetaOperation. A metamodel is an instance of a meta-metamodel. The primary responsibility of the metamodel layer is to define a language for specifying models. Metamodels are typically more elaborate than the meta-metamodels that describe them, especially when they define dynamic semantics. Examples of metaobjects in the metamodeling layer are: Class, Attribute, Operation, and Component. A model is an instance of a metamodel. The primary responsibility of the model layer is to define a language that describes an information domain. Examples of objects in the modeling layer are: StockShare, askPrice, sellLimitOrder, and StockQuoteServer. User objects (a.k.a. user data) are an instance of a model. The primary responsibility of the user objects layer is to describe a specific information domain. Examples of objects in the user objects layer are: , 654.56, sell_limit_order, and . 2.2.1.1 Architectural Alignment with the MOF Meta-Metamodel Both the UML and the MOF are based on a four-layer metamodel architecture, where the MOF meta-metamodel is the meta-metamodel for the UML metamodel. Since the MOF and UML have different scopes and differ in their abstraction levels (the UML Layer Description Example meta-metamodel The infrastructure for a metamodeling architecture. Defines the language for specifying metamodels. MetaClass, MetaAttribute, MetaOperation metamodel An instance of a meta-metamodel. Defines the language for specifying a model. Class, Attribute, Operation, Component model An instance of a metamodel. Defines a language to describe an information domain. StockShare, askPrice, sellLimitOrder, StockQuoteServer user objects (user data) An instance of a model. Defines a specific information domain. , 654.56, sell_limit_order, 2-6 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics metamodel tends to be more of a logical model than the MOF meta-metamodel), they are related by loose metamodeling rather than strict metamodeling.1 As a result, the UML metamodel is an instance of the MOF meta-metamodel. Consequently, there is not a strict isomorphic instance-of mapping between all the MOF meta-metamodel elements and the UML metamodel elements. In spite of this, since the two models were designed to be interoperable, the UML Core package metamodel and the MOF meta-metamodel are structurally quite similar. 2.2.2 Package Structure The complexity of the UML metamodel is managed by organizing it into logical packages. These packages group metaclasses that show strong cohesion with each other and loose coupling with metaclasses in other packages. The metamodel is decomposed into the top-level packages shown in Figure 2-1. Figure 2-1 Top-Level Packages The Foundation and Behavioral Elements packages are further decomposed as shown in Figure 2-2 and Figure 2-3. 1.In loose (or “non-strict”) metamodeling a Mn level model is an instance of a Mn+1 level model. In strict metamodeling, every element of a Mn level model is an instance of exactly one element of Mn+1 level model. March 2003 OMG-Unified Modeling Language, v1.5 2-7 2 UML Semantics Figure 2-2 Foundation Packages Figure 2-3 Behavioral Elements Packages The functions and contents of these packages are described in “Part 3 - Behavioral Elements” on page 2-92. 2.3 Language Formalism This section contains a description of the techniques used to describe UML. The specification adapts formal techniques to improve precision while maintaining readability. The technique describes the UML metamodel in three views using both text and graphic presentations. The benefits of adapting formal techniques include: Core Data Types Extension Mechanisms Use Cases (from Behavioral Elements) State Machines (from Behavioral Elements) Collaborations (from Behavioral Elements) Common Behavior (from Behavioral Elements) Activity Graphs (from Behavioral Elements) Actions (from Behavioral Elements) 2-8 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics • the correctness of the description is improved, • ambiguities and inconsistencies are reduced, • the architecture of the metamodel is validated by a complementary technique, and • the readability of the description is increased. It is important to note that the current description is not a completely formal specification of the language because to do so would have added significant complexity without clear benefit. In addition, the state of the practice in formal specifications does not yet address some of the more difficult language issues that UML introduces. The structure of the language is nevertheless given a precise specification, which is required for tool interoperability. The dynamic semantics are described using natural language, although in a precise way so they can easily be understood. Currently, the dynamic semantics are not considered essential for the development of tools; however, this will probably change in the future. 2.3.1 Levels of Formalism A common technique for specification of languages is to first define the syntax of the language and then to describe its static and dynamic semantics. The syntax defines what constructs exist in the language and how the constructs are built up in terms of other constructs. Sometimes, especially if the language has a graphic syntax, it is important to define the syntax in a notation independent way, that is, to define the abstract syntax of the language. The concrete syntax is then defined by mapping the notation onto the abstract syntax. The syntax is described in the Abstract Syntax sections. The static semantics of a language define how an instance of a construct should be connected to other instances to be meaningful, and the dynamic semantics define the meaning of a well formed construct. The meaning of a description written in the language is defined only if the description is well formed, that is, if it fulfills the rules defined in the static semantics. The static semantics are found in sections headed Well- formedness Rules. The dynamic semantics are described under the heading Semantics. In some cases, parts of the static semantics are also explained in the Semantics section for completeness. The specification uses a combination of languages - a subset of UML, an object constraint language, and precise natural language to describe the abstract syntax and semantics of the full UML. The description is self-contained; no other sources of information are needed to read the document2. Although this is a metacircular description3, understanding this document is practical since only a small subset of UML constructs are needed to describe its semantics. 2. Although a comprehension of the UML’s four-layer metamodel architecture and its underlying meta-metamodel is helpful, it is not essential to understand the UML semantics. March 2003 OMG-Unified Modeling Language, v1.5 2-9 2 UML Semantics In constructing the UML metamodel different techniques have been used to specify language constructs, using some of the capabilities of UML. The main language constructs are reified into metaclasses in the metamodel. Other constructs, in essence being variants of other ones, are defined as stereotypes of metaclasses in the metamodel. This mechanism allows the semantics of the variant construct to be significantly different from the base metaclass. Another more “lightweight” way of defining variants is to use metaattributes. As an example, the aggregation construct is specified by an attribute of the metaclass AssociationEnd, which is used to indicate if an association is an ordinary aggregate, a composite aggregate, or a common association. 2.3.2 Package Specification Structure This section provides information for each package in the UML metamodel. Each package has one or more of the following subsections. 2.3.2.1 Abstract Syntax The abstract syntax is presented in a UML class diagram showing the metaclasses defining the constructs and their relationships. The diagram also presents some of the well-formedness rules, mainly the multiplicity requirements of the relationships, and whether or not the instances of a particular sub-construct must be ordered. Finally, a short informal description in natural language describing each construct is supplied. The first paragraph of each of these descriptions is a general presentation of the construct that sets the context, while the following paragraphs give the informal definition of the metaclass specifying the construct in UML. For each metaclass, its attributes are enumerated together with a short explanation. Furthermore, the opposite role names of associations connected to the metaclass are also listed in the same way. 2.3.2.2 Well-formedness Rules The static semantics of UML metaclasses, except for multiplicity and ordering constraints, are defined as a set of invariants of an instance of the metaclass. (Note that a metaclass is not required to have any invariants.) These invariants have to be satisfied for the construct to be meaningful. The rules thus specify constraints over attributes and associations defined in the metamodel. Each invariant is defined by an OCL expression together with an informal explanation of the expression. In many cases, additional operations on the metaclasses are needed for the OCL expressions. These are then defined in a separate subsection after the well-formedness rules for the construct, using the same approach as the abstract syntax: an informal explanation followed by the OCL expression defining the operation. 3. In order to understand the description of the UML semantics, you must understand some UML semantics. 2-10 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics The statement ‘No extra well-formedness rules’ means that all current static semantics are expressed in the superclasses together with the multiplicity and type information expressed in the diagrams. 2.3.2.3 Semantics The meanings of the constructs are defined using natural language. The constructs are grouped into logical chunks that are defined together. Since only concrete metaclasses have a true meaning in the language, only these are described in this section. 2.3.2.4 Standard Elements Stereotypes of the metaclasses defined previously in the section are listed, with an informal definition in natural language. Well-formedness rules, if any, for the stereotypes are also defined in the same manner as in the Well-formedness Rules subsection. Other kinds of standard elements (constraints and tagged-values) are listed, and are defined in the Standard Elements appendix. 2.3.2.5 Notes This subsection may contain rationales for metamodeling decisions, pragmatics for the use of the constructs, and examples all written in natural language. 2.3.3 Use of a Constraint Language The specification uses the Object Constraint Language (OCL), as defined in Chapter 6, “Object Constraint Language Specification” for expressing well-formedness rules. The following conventions are used to promote readability: • Self - which can be omitted as a reference to the metaclass defining the context of the invariant, has been kept for clarity. • In expressions where a collection is iterated, an iterator is used for clarity, even when formally unnecessary. The type of the iterator is usually omitted, but included when it adds to understanding. • The ‘collect’ operation is left implicit where this is practical. 2.3.4 Use of Natural Language We strove to be precise in our use of natural language, in this case English. For example, the description of UML semantics includes phrases such as “X provides the ability to…” and “X is a Y.” In each of these cases, the usual English meaning is assumed, although a deeply formal description would demand a specification of the semantics of even these simple phrases. March 2003 OMG-Unified Modeling Language, v1.5 2-11 2 UML Semantics The following general rules apply: • When referring to an instance of some metaclass, we often omit the word “instance.” For example, instead of saying “a Class instance” or “an Association instance,” we just say “a Class” or “an Association.” By prefixing it with an “a” or “an,” assume that we mean “an instance of.” In the same way, by saying something like “Elements” we mean “a set (or the set) of instances of the metaclass Element.” • Every time a word coinciding with the name of some construct in UML is used, that construct is referenced. • Terms including one of the prefixes sub, super, or meta are written as one word (for example, metamodel, subclass). 2.3.5 Naming Conventions and Typography In the description of UML, the following conventions have been used: • When referring to constructs in UML, not their representation In the metamodel, normal text is used. • Metaclass names that consist of appended nouns/adjectives, initial embedded capitals are used (for example, ‘ModelElement,’ ‘StructuralFeature’). • Names of metaassociations/association classes are written in the same manner as metaclasses (for example, ‘ElementReference’). • Initial embedded capital is used for names that consist of appended nouns/adjectives (for example, ‘ownedElement,’ ‘allContents’). • Boolean metaattribute names always start with ‘is’ (for example, ‘isAbstract’). • Enumeration types always end with “Kind” (for example, ‘AggregationKind’). • While referring to metaclasses, metaassociations, metaattributes, etc. in the text, the exact names as they appear in the model are always used. • Names of stereotypes are delimited by guillemets and begin with lowercase (for example, «type»). Part 2 - Foundation 2.4 Foundation Package The Foundation package is the language infrastructure that specifies the static structure of models. The Foundation package is decomposed into the following subpackages: Core, Extension Mechanisms, and Data Types. Figure 2-4 illustrates the Foundation Packages. The Core package specifies the basic concepts required for an elementary metamodel and defines an architectural backbone for attaching additional language constructs, such as metaclasses, metaassociations, and metaattributes. The Extension Mechanisms package specifies how model elements are customized and extended with new semantics. The Data Types package defines basic data structures for the language. 2-12 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Figure 2-4 Foundation Packages 2.5 Core 2.5.1 Overview The Core package is the most fundamental of the subpackages that compose the UML Foundation package. It defines the basic abstract and concrete metamodel constructs needed for the development of object models. Abstract constructs are not instantiable and are commonly used to reify key constructs, share structure, and organize the UML metamodel. Concrete metamodel constructs are instantiable and reflect the modeling constructs used by object modelers (cf. metamodelers). Abstract constructs defined in the Core include ModelElement, GeneralizableElement, and Classifier. Concrete constructs specified in the Core include Class, Attribute, Operation, and Association. The Core package specifies the core constructs required for a basic metamodel and defines an architectural backbone (“skeleton”) for attaching additional language constructs such as metaclasses, metaassociations, and metaattributes. Although the Core package contains sufficient semantics to define the remainder of UML, it is not the UML meta-metamodel. It is the underlying base for the Foundation package, which in turn serves as the infrastructure for the rest of language. In other packages, the Core is extended by adding metaclasses to the backbone using generalizations and associations. The following sections describe the abstract syntax, well-formedness rules, and semantics of the Core package. 2.5.2 Abstract Syntax The abstract syntax for the Core package is expressed in graphic notation in the following figures. Figure 2-5 on page 2-13 shows the model elements that form the structural backbone of the metamodel. Figure 2-6 on page 2-14 shows the model Core Data Types Extension Mechanisms March 2003 OMG-Unified Modeling Language, v1.5 2-13 2 UML Semantics elements that define relationships. Figure 2-7 on page 2-15 shows the model elements that define dependencies. Figure 2-8 on page 2-16 shows the various kinds of classifiers. Figure 2-9 on page 2-17 shows auxiliary elements for template parameters, presentation elements, and comments. Figure 2-5 Core Package - Backbone Element GeneralizableElement isRoot : Boolean isLeaf : Boolean isAbstract : Boolean Attribute initialValue : Expression Method body : ProcedureExpression Operation concurr ency : Cal lConcurrencyKi nd i sRoot : Bool ean isLeaf : Boolean isAbstract : Boolean specification : String *1 * +specification 1 ElementOwnership visibility : VisibilityKind isSpecification : Boolean Namespace Constrai nt body : BooleanExpression ModelElement name : Name 0..1 * +namespace 0..1 +ownedElement * * * +constraint * +constrainedElement * {ordered} BehavioralFeature isQuery : Boolean Feature ownerScope : ScopeKind visibility : VisibilityKind StructuralFeature multiplicity : Multiplicity changeability : ChangeableKind targetScope : ScopeKind orderi ng : Or deri ngKi nd Parameter defaultValue : Expression kind : ParameterDirectionKind 0..1 * 0..1 +parameter* {ordered} Classifier * 0..1 +feature* {ordered} +owner 0..1 * 1 +typedFeature* +type1 * 1 +typedParameter* +type1 2-14 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Figure 2-6 Core Package - Relationships {ordered} Associ at i onClass Class isActi ve : Bool ean Rel ati onshi p Fl ow ModelEl ement name : Name * * +sourceFl ow * +source * * * +targetFl ow * +target * Associ at i on Attribute initialVal ue : Expr essi on Associati onEnd isNavi gabl e : Bool ean or der i ng : Or der i ngKind aggr egati on : AggregationKind targetScope : ScopeKind mul t i pl i ci ty : Mul ti pl i ci t y changeabi l i t y : Changeabl eKind visibility : VisibilityKind 2..* 1 +connect i on 2..* 1 * 0..1 +quali fi er * {ordered} +associ ationEnd 0..1 Gener al i zabl eElement isRoot : Bool ean i sLeaf : Bool ean isAbstr act : Bool ean Classifier 1 * +parti ci pant 1 +associ ation * ** +speci fiedEnd * +specification * General i zati on di scr i minat or : Name * 1 +gener al i zat i on * +child 1 1* +parent 1 +specialization * 0. .1 * +power t ype 0. .1 +power t ypeRange * March 2003 OMG-Unified Modeling Language, v1.5 2-15 2 UML Semantics Figure 2-7 Core Package - Dependencies Usage Permission Abstraction mapping : MappingExpression Dependency Binding ModelElement name : Name 1..* * +supplier 1..* +supplierDependency * 1..* * +client 1..* +clientDependency * Relationship 2-16 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Figure 2-8 Core Package - Classifiers EnumerationLiteral Classi fi er Cl as s isActive : Boolean Dat aType Interface ElementResidence visibility : VisibilityKind Primitive Enumeration 1 1..* +enumeration 1 +literal 1..* {ordered} No de ModelElement name : Name ArtifactCompone nt * *+deploymentLocation * +deployedComponent * * * +container* +resident* * * +implementation *+implementationLocation * ProgrammingLanguageDataType expression : TypeExpression March 2003 OMG-Unified Modeling Language, v1.5 2-17 2 UML Semantics Figure 2-9 Core Package - Auxiliary elements 2.5.2.1 Abstraction An abstraction is a Dependency relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. In the metamodel, an Abstraction is a Dependency in which there is a mapping between the supplier and the client. Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional. If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. The situation is similar if there is more than one supplier element. The UML standard stereotyped classes of Abstraction are Derivation, Realization, Refinement, and Trace. (These are the names for the Abstraction class with the stereotypes «derive», «realize», «refine», and «trace», respectively.) Element PresentationElement TemplateParameter Comment body : String ModelElement name : Name ** +presentation * +subject * 0..1 * +template 0..1 +templateParameter * {ordered} 0..1 * +defaultEl ement0..1 * * * * +annotatedElement* Binding TemplateArgument * 1* +modelElement 1 1 1..* +binding1 +argument 1..* {ordered} 2-18 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes Stereotypes 2.5.2.2 Artifact An Artifact represents a physical piece of information that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files. An Artifact may constitute the implementation of a deployable component. mapping A MappingExpression that states the abstraction relationship between the supplier and the client. In some cases, such as Derivation, it is usually formal and unidirectional; in other cases, such as Trace, it is usually informal and bidirectional. The mapping attribute is optional and may be omitted if the precise relationship between the elements is not specified. «derive» Class (Name for the stereotyped class is Derivation.) Specifies a derivation relationship among model elements that are usually, but not necessarily, of the same type. A derived dependency specifies that the client may be computed from the supplier. The mapping specifies the computation. The client may be implemented for design reasons, such as efficiency, even though it is logically redundant. «realize» Class (Name for the stereotyped class is Realization.) Specifies a realization relationship between a specification model element or elements (the supplier) and a model element or elements that implement it (the client). The implementation model element is required to support all of the operations or received signals that the specification model element declares. The implementation model element must make or inherit its own declarations of the operations and signal receptions. The mapping specifies the relationship between the two. The mapping may or may not be computable. Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc. «refine» Class (Name for the stereotyped class is Refinement.) Specifies refinement relationship between model elements at different semantic levels, such as analysis and design. The mapping specifies the relationship between the two elements or sets of elements. The mapping may or may not be computable, and it may be unidirectional or bidirectional. Refinement can be used to model transformations from analysis to design and other such changes. «trace» Class (Name for the stereotyped class is Trace.) Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. Since model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal. March 2003 OMG-Unified Modeling Language, v1.5 2-19 2 UML Semantics In the metamodel, an Artifact is a Classifier with an optional aggregation association to one or more Components. As a Classifier, Artifacts may have Features that represent properties of the Artifact (e.g., a “read-only” attribute or a “check in” operation). It should be noted that sometimes Artifacts may need to be linked to Classifiers directly, without introducing a ‘Component.’ For instance, in the context of code generation, the resulting Artifacts (source code files) are never deployed as Components. In that case, a «derive» Dependency can be used between the Classifier(s) and the generated Artifact. The standard stereotypes of Artifact are «file», the subclasses of «file» («executable», «source», «library», and «document»), and «table». These stereotypes can be further subclassed into implementation and platform specific stereotypes (e.g., «jarFile» for Java archives). Associations Stereotypes 2.5.2.3 Association An association defines a semantic relationship between classifiers. The instances of an association are a set of tuples relating instances of the classifiers. Each tuple value may appear at most once. In the metamodel, an Association is a declaration of a semantic relationship between Classifiers, such as Classes. An Association has at least two AssociationEnds. Each end is connected to a Classifier - the same Classifier may be connected to more than one AssociationEnd in the same Association. The Association represents a set of connections among instances of the Classifiers. An instance of an Association is a Link, which is a tuple of Instances drawn from the corresponding Classifiers. implementation Location The deployable Component(s) that are implemented by this Artifact. «document» Class Denotes a generic file that is not a «source» file or «executable». Subclass of «file». «executable» Class Denotes a program file that can be executed on a computer system. Subclass of «file». «file» Class Denotes a physical file in the context of the system developed. «library» Class Denotes a static or dynamic library file. Subclass of «file». «source» Class Denotes a source file that can be compiled into an executable file. Subclass of «file». «table» Class Denotes a database table. 2-20 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes Associations Stereotypes Standard Constraints Tagged Values Inherited Features Association is a GeneralizableElement. The following elements are inherited by a child Association. name The name of the Association which, in combination with its associated Classifiers, must be unique within the enclosing namespace (usually a Package). connection An Association consists of at least two AssociationEnds, each of which represents a connection of the association to a Classifier. Each AssociationEnd specifies a set of properties that must be fulfilled for the relationship to be valid. The bulk of the structure of an Association is defined by its AssociationEnds. The classifiers belonging to the association are related to the AssociationEnds by the participant rolename association. «implicit» The «implicit» stereotype is applied to an association, specifying that the association is not manifest, but rather is only conceptual. xor Association The {xor} constraint is applied to a set of associations, specifying that over that set, exactly one is manifest for each associated instance. Xor is an exclusive or (not inclusive or) constraint. persistence Association Persistence denotes the permanence of the state of the association, marking it as transitory (its state is destroyed when the instance is destroyed) or persistent (its state is not destroyed when the instance is destroyed). connection The child must have the same number of ends as the parent. Each participant class must be a descendant of the participant class in the same position in the parent. If the Association is an AssociationClass, its class properties (attributes, operations, etc.) are inherited. Various other properties are subject to change in the child. This specification is likely to be further clarified in UML 2.0. March 2003 OMG-Unified Modeling Language, v1.5 2-21 2 UML Semantics Non-Inherited Features 2.5.2.4 AssociationClass An association class is an association that is also a class. It not only connects a set of classifiers but also defines a set of features that belong to the relationship itself and not any of the classifiers. Inherited Features AssociationClass inherits features as specified in both Class and Association. In the metamodel, an AssociationClass is a declaration of a semantic relationship between Classifiers, which has a set of features of its own. AssociationClass is a subclass of both Association and Class (i.e., each AssociationClass is both an Association and a Class); therefore, an AssociationClass has both AssociationEnds and Features. 2.5.2.5 AssociationEnd An association end is an endpoint of an association, which connects the association to a classifier. Each association end is part of one association. The association-ends of each association are ordered. In the metamodel, an AssociationEnd is part of an Association and specifies the connection of an Association to a Classifier. It has a name and defines a set of properties of the connection (e.g., which Classifier the Instances must conform to, their multiplicity, and if they may be reached from another Instance via this connection). In the following descriptions when referring to an association end for a binary association, the source end is the other end. The target end is the one whose properties are being discussed. isRoot isLeaf isAbstract Not inheritable by their very nature, but they define the generalization structure. name Each model element has a unique name. 2-22 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes aggregation When placed on one end (the “target” end), specifies whether the class on the target end is an aggregation with respect to the class on the other end (the “source”end). Only one end can be an aggregation. Possibilities are: • none - The target class is not an aggregate. • aggregate - The target class is an aggregate; therefore, the source class is a part and must have the aggregation value of none. The part may be contained in other aggregates. • composite - The target class is a composite; therefore, the source class is a part and must have the aggregation value of none. The part is strongly owned by the composite and may not be part of any other composite. changeability Specifies whether or not links may be created or destroyed after the initialization of objects at the opposite ends. Possibilities are: • changeable - No restrictions on creation and destruction of links. • frozen - No links may be destroyed after the objects at the opposite ends have been initialized, and no new links may be created after the objects that would participate in the new link at the opposite ends have been initialized. • addOnly - No link may be destroyed after the objects at the opposite ends have been initialized. Links may be created anytime. ordering When placed on a target end, specifies whether the set of links from the source instance to the target instance is ordered. The ordering must be determined and maintained by Operations that add links. It represents additional information not inherent in the objects or links themselves. Possibilities are: • unordered - The links form a set with no inherent ordering. • ordered - A set of ordered links can be scanned in order. • Other possibilities (such as sorted) may be defined later by declaring additional keywords. As with user-defined stereotypes, this would be a private extension supported by particular editing tools. isNavigable When placed on a target end, specifies whether traversal from a source instance to its associated target instances is possible. Specification of each direction across the Association is independent. A value of true means that the association can be navigated by the source class and the target rolename can be used in navigation expressions. multiplicity When placed on a target end, specifies the number of target instances that may be associated with a single source instance across the given Association. March 2003 OMG-Unified Modeling Language, v1.5 2-23 2 UML Semantics Associations name (Inherited from ModelElement) The rolename of the end. When placed on a target end, provides a name for traversing from a source instance across the association to the target instance or set of target instances. It represents a pseudo-attribute of the source classifier (i.e., it may be used in the same way as an Attribute) and must be unique with respect to Attributes and other pseudo-attributes of the source Classifier. targetScope Specifies whether the target value is an instance or a classifier. Possibilities are: • instance. An instance value is part of each link. This is the default. • classifier. A classifier itself is part of each link. Normally this would be fixed at modeling time and need not be stored separately at run time. visibility Specifies the visibility of the association end from the viewpoint of the classifier on the other end. Possibilities are: • public - Other classifiers may navigate the association and use the rolename in expressions, similar to the use of a public attribute. • protected - Descendants of the source classifier may navigate the association and use the rolename in expressions, similar to the use of a protected attribute. • private - Only the source classifier may navigate the association and use the rolename in expressions, similar to the use of a private attribute. • package - Classifiers in the same package (or a nested subpackage, to any level) as the association declaration may navigate the association and use the rolename in expressions. qualifier An optional list of qualifier Attributes for the end. If the list is empty, then the Association is not qualified. specification Designates zero or more Classifiers that specify the Operations that may be applied to an Instance accessed by the AssociationEnd across the Association. These determine the minimum interface that must be realized by the actual Classifier attached to the end to support the intent of the Association. May be an Interface or another Classifier. These classifiers do not indicate the classes of the participants in a link, merely the operations that may be applied when traversing a link. participant Designates the Classifier participating in the Association at the given end. A link of the Association contains a reference to an instance of the class (including a descendant of the given class or a class that realizes a given interface) in the given position in the link. (unnamed composite end) Designates the Association that owns the AssociationEnd. 2-24 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Stereotypes 2.5.2.6 Attribute An attribute is a named slot within a classifier that describes a range of values that instances of the classifier may hold. In the metamodel, an Attribute is a named piece of the declared state of a Classifier, particularly the range of values that Instances of the Classifier may hold. Attributes Associations 2.5.2.7 BehavioralFeature A behavioral feature refers to a dynamic feature of a model element, such as an operation or method. In the metamodel, a BehavioralFeature specifies a behavioral aspect of a Classifier. All different kinds of behavioral aspects of a Classifier, such as Operation and Method, are subclasses of BehavioralFeature. BehavioralFeature is an abstract metaclass. «association» Class Specifies a real association (default and redundant, but may be included for emphasis). «global» Class Specifies that the target is a global value that is known to all elements rather than an actual association. «local» Class Specifies that the relationship represents a local variable within a procedure rather than an actual association. «parameter» Class Specifies that the relationship represents an operation, method, or procedure parameter rather than an actual association. «self» Class Specifies that the relationship represents a reference to the object that owns an operation or action rather than an actual association. initialValue An Expression specifying the value of the attribute upon initialization. It is meant to be evaluated at the time the object is initialized. (Note that an explicit constructor may supersede an initial value.) associationEnd Designates the optional AssociationEnd that owns a qualifier attribute. Note that an attribute may be part of an AssociationEnd (in which case it is a qualifier) or part of a Classifier (by inheritance from Feature, in which case it is a feature) but not both. If the value is empty, the attribute is not a qualifier attribute. March 2003 OMG-Unified Modeling Language, v1.5 2-25 2 UML Semantics Attributes Associations Stereotypes 2.5.2.8 Binding A binding is a relationship between a template (as supplier) and a model element generated from the template (as client). It includes a list of arguments that match the template parameters. The template is a form that is cloned and modified by substitution to yield an implicit model fragment that behaves as if it were a direct part of the model. A Binding must have one supplier and one client; unlike a general Dependency, the supplier and client may not be sets. In the metamodel, a Binding is a Dependency where the supplier is the template and the client is the instantiation of the template that performs the substitution of parameters of a template. A Binding has a list of arguments that replace the parameters of the supplier to yield the client. The client is fully specified by the binding of the supplier’s parameters and does not add any information of its own. An element may participate as a supplier in multiple Binding relationships to different clients. An element may participate in only one Binding relationship as a client. Associations isQuery Specifies whether an execution of the Feature leaves the state of the system unchanged. True indicates that the state is unchanged; false indicates that side-effects may occur. name (Inherited from ModelElement) The name of the Feature. The entire signature of the Feature (name and parameter list) must be unique within its containing Classifier. parameter An ordered list of Parameters for the Operation. To call the Operation, the caller must supply a list of values compatible with the types of the Parameters. «create» Class Specifies that the designated feature creates an instance of the classifier to which the feature is attached. May be promoted to the Classifier containing the feature. «destroy» Class Specifies that the designated feature destroys an instance of the classifier to which the feature is attached. May be promoted to the classifier containing the feature. argument An ordered list of arguments. Each argument is a TemplateArgument element. The model element attached to the TemplateArgument by the modelElement association replaces the corresponding supplier parameter in the supplier definition, and the result represents the definition of the client as if it had been defined directly. 2-26 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.5.2.9 Class A class is a description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment. In the metamodel, a Class describes a set of Objects sharing a collection of Features, including Operations, Attributes, and Methods that are common to the set of Objects. Furthermore, a Class may realize zero or more Interfaces; this means that its full descriptor (see “Inheritance” on page 2-69 for the definition) must contain every Operation from every realized Interface (it may contain additional operations as well). A Class defines the data structure of Objects, although some Classes may be abstract (i.e., no Objects can be created directly from them). Each Object instantiated from a Class contains its own set of values corresponding to the StructuralFeatures declared in the full descriptor. Objects do not contain values corresponding to BehavioralFeatures or class-scope Attributes; all Objects of a Class share the definitions of the BehavioralFeatures from the Class, and they all have access to the single value stored for each class-scope attribute. Attributes Stereotypes isActive Specifies whether an Object of the Class maintains its own thread of control. If true, then an Object has its own thread of control and runs concurrently with other active Objects. Such a class is informally called an active class. If false, then Operations run in the address space and under the control of the active Object that controls the caller. Such a class is informally called a passive class. «auxiliary» Class Specifies a class that supports another more central or fundamental class, typically by implementing secondary logic or control flow. The class that the auxiliary supports may be defined explicitly using a Focus class or implicitly by a dependency relationship. Auxiliary classes are typically used together with Focus classes, and are particularly useful for specifying the secondary business logic or control flow of components during design. See also: «focus». «focus» Class Specifies a class that defines the core logic or control flow for one or more auxiliary classes that support it. Support classes may be defined explicitly using Auxiliary classes or implicitly by dependency relationships. Focus classes are typically used together with one or more Auxiliary classes, and are particularly useful for specifying the core business logic or control flow of components during design. See also: «auxiliary». March 2003 OMG-Unified Modeling Language, v1.5 2-27 2 UML Semantics Stereotypes (continued) Inherited Features Class is a GeneralizableElement. The following elements are inherited by a child classifier, in addition to those specified under its parent, Classifier. 2.5.2.10 Classifier A classifier is an element that describes behavioral and structural features; it comes in several specific forms, including class, data type, interface, component, artifact, and others that are defined in other metamodel packages. In the metamodel, a Classifier declares a collection of Features, such as Attributes, Methods, and Operations. It has a name, which is unique in the Namespace enclosing the Classifier. Classifier is an abstract metaclass. «implementation» Class Specifies the implementation of a class in some programming language (e.g., C++, Smalltalk, Java) in which an instance may not have more than one class. This is in contrast to Class, for which an instance may have multiple classes at one time and may gain or lose classes over time, and an object (a child of instance) may dynamically have multiple classes. An Implementation class is said to realize a Type if it provides all of the operations defined for the Type with the same behavior as specified for the Type’s operations. An Implementation Class may realize a number of different Types. Note that the physical attributes and associations of the Implementation class do not have to be the same as those of any Type it realizes and that the Implementation Class may provide methods for its operations in terms of its physical attributes and associations. See also: «type». «type» Class Specifies a domain of objects together with the operations applicable to the objects, without defining the physical implementation of those objects. A type may not contain any methods, maintain its own thread of control, or be nested. However, it may have attributes and associations. The associations of a Type are defined solely for the purpose of specifying the behavior of the type's operations and do not represent the implementation of state data. Although an object may have at most one Implementation Class, it may conform to multiple different Types. See also: «implementation». isActive The child may be active when the parent is passive, but not vice versa. In most cases, they are the same. 2-28 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Classifier is a child of GeneralizableElement and Namespace. As a GeneralizableElement, it may inherit Features and participation in Associations (in addition to things inherited as a ModelElement). It also inherits ownership of StateMachines, Collaborations, etc. As a Namespace, a Classifier may declare other Classifiers nested in its scope. Nested Classifiers may be accessed by other Classifiers only if the nested Classifiers have adequate visibility. There are no data value or state consequences of nested Classifiers (i.e., it is not an aggregation or composition). Associations Stereotypes feature An ordered list of Features, like Attribute, Operation, Method owned by the Classifier. association Denotes the AssociationEnd of an Association in which the Classifier participates at the given end. This is the inverse of the participant association from AssociationEnd. A link of the association contains a reference to an instance of the class in the given position. powertypeRange Designates zero or more Generalizations for which the Classifier is a powertype. If the cardinality is zero, then the Classifier is not a powertype; if the cardinality is greater than zero, then the Classifier is a powertype over the set of Generalizations designated by the association, and the child elements of the Generalizations are the instances of the Classifier as a powertype. A Classifier that is a powertype can be marked with the «powertype» stereotype. specifiedEnd Indicates an AssociationEnd for which the given Classifier specifies operations that may be applied to instances obtained by traversing the association from the other end. (This relationship does not define the structure of the association, merely operations that may be applied on traversing it.) «metaclass» Class Specifies that the instances of the classifier are classes. «powertype» Class Specifies that the classifier is a metaclass whose instances are siblings marked by the same discriminator. For example, the metaclass TreeSpecies might be a power type for the subclasses of Tree that represent different species, such as AppleTree, BananaTree, and CherryTree. «process» Class Specifies a classifier that represents a heavy-weight flow of control. «thread» Class Specifies a classifier that represents a flow of control. «utility» Class Specifies a classifier that has no instances, but rather denotes a named collection of non-member attributes and operations, all of which are class-scoped. March 2003 OMG-Unified Modeling Language, v1.5 2-29 2 UML Semantics Tagged Values Inherited Features Classifier is a GeneralizableElement. The following elements are inherited by a child classifier. Note that inheritance makes the inherited elements part of the (virtual) full descriptor of the classifier, but it does not change its actual data structure. See the explanation for the meaning of each kind of inheritance. Non-Inherited Features The following elements are not inherited by a child classifier. persistence Persistence denotes the permanence of the state of the classifier, marking it as transitory (its state is destroyed when the instance is destroyed) or persistent (its state is not destroyed when the instance is destroyed). semantics Classifier Semantics is the specification of the meaning of the classifier. associationEnd The child class inherits participation in all associations of its parent, subject to all the same properties. constraint Constraints on the parent apply to the child. feature Attributes of the parent are part of the full descriptor of the child and may not be declared again or overridden. Operations of the parent are part of the full descriptor of the child but may be overridden; a redeclaration may change its hierarchy location (isRoot, isLeaf, isAbstract) but may not change its specification or parameter structure. The concurrency level may be loosened (e.g., from guarded to concurrent). An overriding operation may link to a different Method. An overriding operation can have isQuery=true when the parent had a false value, but not vice versa (in other words, once a side-effect, always a side-effect). Methods of the parent are part of the full descriptor of the child but may be overridden. An overriding method can set the isQuery status, change its hierarchy structure, but may not change its parameter structure. It may link to a different operation that overrides the operation of the parent method. generalization specialization These are implicitly inherited, in the sense that they define ancestors and descendants, but not explicitly inherited, as they are the arcs in the generalization graph. They establish the generalization structure itself as a directed graph, into which the child classifier fits. ownedElement The namespace of the parent is available to the child, except for private access. 2-30 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.5.2.11 Comment A comment is an annotation attached to a model element or a set of model elements. It has no semantic force but may contain information useful to the modeler. Attributes Associations Stereotypes 2.5.2.12 Component A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. A component is typically specified by one or more classifiers that reside on the component. A subset of these classifiers explicitly define the component’s external interfaces. A component conforms to the interfaces that it exposes, where the interfaces represent services provided by elements that reside on the component. A component may be implemented by one or more artifacts, such as binary, executable, or script files. A component may be deployed on a node. isRoot isLeaf isAbstract By their very nature, these are not inherited name Each classifier has its own unique name parameter Template structure is not inherited. Each classifier must declare its own templace structure, if any. A nontemplate can be child of a template and vice versa. powertypeRange A powertype corresponds to a particular node in the generalization hierarchy, so it is not inherited. body A string that is the comment. annotatedElement A ModelElement or set of ModelElements described by the Comment. «requirement» Class Specifies a desired feature, property, or behavior of an element as part of a system. «responsibility» Class Specifies a contract or an obligation of an element in its relationship to other elements. March 2003 OMG-Unified Modeling Language, v1.5 2-31 2 UML Semantics Components may be specified in both design models (e.g., using static structure diagrams) and in implementation models (e.g., using implementation diagrams). When they are specified as part of a design model components need not be allocated to nodes, nor do they need to have any associated implementation artifacts. In the metamodel, a Component is a child of Classifier. It does not have its own Features, but instead acts as a container for other Classifiers that have Features. A Component is specified by the Interfaces is exposes and the Classifiers that reside on it. The visibility attribute of the ElementResidence association defines whether a resident element is visible outside the Component: an external Interface of a Component has visibility value ‘public.’ A Component may be implemented by one or more Artifacts, and may be deployed on a Node. Associations Inherited Features The following elements are inherited by a child Component, in addition to those specified under Classifier. Non-Inherited Features 2.5.2.13 Constraint A constraint is a semantic condition or restriction expressed in text. In the metamodel, a Constraint is a BooleanExpression on an associated ModelElement(s), which must be true for the model to be well formed. This restriction can be stated in natural language, or in different kinds of languages with a well defined deploymentLocation The set of Nodes the Component is residing on. resident (Association class ElementResidence) The set of model elements that specify the component. The visibility attribute shows the external visibility of the element outside the component: an external Interface of a Component has visibility = ‘public’ for its ElementResidence association. implementation The set of Artifacts that implement the Component. For a Component, these Artifacts are generally «executable». (none) deploymentLocation The set of locations may differ. Often it is more restrictive on the child. resident The set of resident elements may differ. Often it is more restrictive on the child and contains additional elements. implementation The set of Artifacts that implement the child Component will usually differ. 2-32 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics semantics. Certain Constraints are predefined in the UML, others may be user defined. Note that a Constraint is an assertion, not an executable mechanism. It indicates a restriction that must be enforced by correct design of a system. Attributes Associations Stereotypes 2.5.2.14 DataType A data type is a type whose values have no identity (i.e., they are pure values). Data types include primitive built-in types (such as integer and string) as well as definable enumeration types (such as the predefined enumeration type boolean whose literals are false and true). In the metamodel, a DataType defines a special kind of Classifier in which Operations are all pure functions (i.e., they can return DataValues but they cannot change DataValues, because they have no identity). For example, an “add” operation on a number with another number as an argument yields a third number as a result; the target and argument are unchanged. Inherited Features DataType inherits features as specified in Classifier. body A BooleanExpression that must be true when evaluated for an instance of a system to be well formed. constrainedElement A ModelElement or list of ModelElements affected by the Constraint. If the constrained element is a Stereotype, then the constraint applies to all ModelElements that use the stereotype. «invariant» Class Specifies a constraint that must be attached to a set of classifiers or relationships. It indicates that the conditions of the constraint must hold over time (for the time period of concern in the particular containing element) for the classifiers or relationships and their instances. «postcondition» Class Specifies a constraint that must be attached to an operation, and denotes that the conditions of the constraint must hold after the invocation of the operation. «precondition» Class Specifies a constraint that must be attached to an operation, and denotes that the conditions of the constraint must hold for the invocation of the operation. «stateInvariant» Class Specifies a constraint that must be attached to a state vertex in a state machine that has a classifier for a context. The stereotype indicates that the constraint holds for instances of the classifier when an instance is in that state. March 2003 OMG-Unified Modeling Language, v1.5 2-33 2 UML Semantics 2.5.2.15 Dependency A term of convenience for a Relationship other than Association, Generalization, Flow, or metarelationship (such as the relationship between a Classifier and one of its Instances). A dependency states that the implementation or functioning of one or more elements requires the presence of one or more other elements. In the metamodel, a Dependency is a directed relationship from a client (or clients) to a supplier (or suppliers) stating that the client is dependent on the supplier (i.e., the client element requires the presence and knowledge of the supplier element). The kinds of Dependency are Abstraction, Binding, Permission, and Usage. Various stereotypes of those elements are predefined. Associations 2.5.2.16 Element An element is an atomic constituent of a model. In the metamodel, an Element is the top metaclass in the metaclass hierarchy. It has two subclasses: ModelElement and PresentationElement. Element is an abstract metaclass. Tagged Values 2.5.2.17 ElementOwnership Element ownership defines the visibility of a ModelElement contained in a Namespace. In the metamodel, ElementOwnership reifies the relationship between ModelElement and Namespace denoting the ownership of a ModelElement by a Namespace and its visibility outside the Namespace. See Section 2.5.2.27, “ModelElement,” on page 2-41. client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements. supplier Inverse of client. Designates the element that is unaffected by a change. In a two-way relationship (such as some Refinement Abstractions) this would be the more general element. In an undirected situation, such as a Trace Abstraction, the choice of client and supplier may be irrelevant. documentation Element Documentation is a comment, description, or explanation of the element to which it is attached. 2-34 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes 2.5.2.18 ElementResidence Association class between Component and ModelElement that defines the set of ModelElements that specify a Component. See Component::resident. Shows that the component supports the element. The visibility attribute of ElementResidence defines the visibility of a resident element outside the component: an external Interface of a Component has visibility = ‘public’ for its ElementResidence association. Attributes 2.5.2.19 Enumeration In the metamodel, Enumeration defines a kind of DataType whose range is a list of predefined values, called enumeration literals. isSpecification Specifies whether the ownedElement is part of the specification for the containing namespace (in cases where specification is distinguished from the realization). Otherwise the ownedElement is part of the realization. In cases in which the distinction is not made, the value is false by default. visibility Specifies whether the ModelElement can be seen and referenced by other ModelElements. Possibilities: • public - Any outside ModelElement can see the ModelElement. • protected - Any descendent of the ModelElement can see the ModelElement. • private - Only the ModelElement itself, or elements nested within it can see the ModelElement. • package - ModelElements declared in the same package (or a nested subpackage, to any level) as the given ModelElement can see the ModelElement. Note that use of an element in another Package may also be subject to access or import of its Package as described in Model Management; see Permission. visibility Specifies whether a ModelElement that resides in a Component is visible externally. Possible values for ElementResidence visibility are: • public - Any resident ModelElement with public visibility is part of the Component’s external Interface and can be used by other elements, if they have permission to access or import the Component. • private - The ModelElement is internal to the Component and cannot be used by external elements. • protected - The ModelElement is only visible to Descendant Components. Note: the visibility values ‘package’ does not apply to Element Residence visibility. The Component and its residents have ElementOwnership associations with visibility values to the Package that contains them. March 2003 OMG-Unified Modeling Language, v1.5 2-35 2 UML Semantics Enumeration literals can be copied, stored as values, and passed as arguments. They are ordered within their enumeration datatype. An enumeration literal can be compared for an exact match or to a range within its enumeration datatype. There is no other algebra defined on them (e.g., they cannot be added or subtracted). The run-time instances of a Primitive dataype are Values. Each such value corresponds to exactly one EnumerationLiteral defined as part of the Enumeration type itself. An Enumeration may have operations, but they must be pure functions (this is the rule for all DataType elements). Associations 2.5.2.20 EnumerationLiteral An EnumerationLiteral defines an element of the run-time extension of an Enumeration data type. It has no relevant substructure, that is, it is atomic. The enumeration literals of a particular Enumeration datatype are ordered. It has a name (inherited from ModelElement) that can be used to identify it within its enumeration dataype. Note that an EnumerationLiteral is a ModelElement and may appear in (M1) models to define the structure of an Enumeration. In a run-time (M0) system, enumeration literals are DataValues in many-to-one correspondence to EnumerationLiterals that they represent. (This is a subtle but necessary distinction between M1 and M0 entities.) The run-time values corresponding to enumeration literals can be compared for equality and for relative ordering or inclusion in a range of enumeration literals. Associations 2.5.2.21 Feature A feature is a property, like operation or attribute, which is encapsulated within a Classifier. In the metamodel, a Feature declares a behavioral or structural characteristic of an Instance of a Classifier or of the Classifier itself. Feature is an abstract metaclass. literal An ordered set of EnumationLiteral elements, each specifying a possible value of an instance of the enumeration element. enumeration The enumeration classifier of which this enumeration literal is an instance. 2-36 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes Associations 2.5.2.22 Flow A flow is a relationship between two versions of an object or between an object and a copy of it. In the metamodel, a Flow is a child of Relationship. A Flow is a directed relationship from a source or sources to a target or targets. Predefined stereotypes of Flow are «become» and «copy». Become relates one version of an object to another with a different value, state, or location. Copy relates an object to another object that starts as a copy of it. name (Inherited from ModelElement) The name used to identify the Feature within the Classifier or Instance. It must be unique across inheritance of names from ancestors including names of outgoing AssociationEnd. (See more specific rules for the exact details. Attributes, discriminators, and opposite association ends must have unique names in the set of inherited names. There may be multiple declarations of the same operation. Multiple operations may have the same name but different signatures; see the rules for precise details.) ownerScope Specifies whether Feature appears in each Instance of the Classifier or whether there is just a single instance of the Feature for the entire Classifier. Possibilities are: • instance - Each Instance of the Classifier holds its own value for the Feature. • classifier - There is just one value of the Feature for the entire Classifier. visibility Specifies whether the Feature can be used by other Classifiers. Visibilities of nested Classifiers combine so that the most restrictive visibility is the result. Possibilities: • public - Any outside Classifier with visibility to the Classifier can use the Feature. • protected - Any descendent of the Classifier can use the Feature. • private - Only the Classifier itself can use the Feature. • package - Any Classifier declared in the same package (or a nested subpackage, to any level) as the owner of the Feature can use the Feature. owner The Classifier declaring the Feature. Note that an Attribute may be owned by a Classifier (in which case it is a feature) or an AssociationEnd (in which case it is a qualifier) but not both. March 2003 OMG-Unified Modeling Language, v1.5 2-37 2 UML Semantics Stereotypes 2.5.2.23 GeneralizableElement A generalizable element is a model element that may participate in a generalization relationship. In the metamodel, a GeneralizableElement can be a generalization of other GeneralizableElements (i.e., all Features defined in and all ModelElements contained in the ancestors are also present in the GeneralizableElement). GeneralizableElement is an abstract metaclass. Attributes «become» Class Specifies a Flow relationship, source and target of which represent the same instance at different points in time, but each with potentially different values, state instance, and roles. A Become flow relationship from A to B means that instance A becomes B with possibly new values, state instance, and roles at a different moment in time/space. «copy» Class Specifies a Flow relationship, the source and target of which are different instances, but each with the same values, state instance, and roles (but a distinct identity). A Copy flow relationship from A to B means that B is an exact copy of A. Future changes in A are not necessarily reflected in B. isAbstract Specifies whether the GeneralizableElement may not have a direct instance. True indicates that an instance of the GeneralizableElement must be an instance of a child of the GeneralizableElement. False indicates that there may be an instance of the GeneralizableElement that is not an instance of a child. An abstract GeneralizableElement is not instantiable since it does not contain all necessary information. That is, it may not have a direct instance. It may have an indirect instance, and a model at a higher level of abstraction may include instances of an abstract type, with the understanding that in a fully expanded concrete snapshot, such instances would have concrete types that are descendants of the abstract types. isLeaf Specifies whether the GeneralizableElement is a GeneralizableElement with no descendents. True indicates that it may not have descendents, false indicates that it may have descendents (whether or not it actually has any descendents at the moment). isRoot Specifies whether the GeneralizableElement is a root GeneralizableElement with no ancestors. True indicates that it may not have ancestors, false indicates that it may have ancestors (whether or not it actually has any ancestors at the moment). 2-38 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Associations Inherited Features The following elements are inherited by a child GenerizableElement. Non-Inherited Features 2.5.2.24 Generalization A generalization is a taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element (it has all of its properties, members, and relationships) and may contain additional information. In the metamodel, a Generalization is a directed inheritance relationship, uniting a GeneralizableElement with a more general GeneralizableElement in a hierarchy. Generalization is a subtyping relationship (i.e., an Instance of the more general GeneralizableElement may be substituted by an Instance of the more specific GeneralizableElement). See Inheritance for the consequences of Generalization relationships. generalization Designates a Generalization whose parent GeneralizableElement is the immediate ancestor of the current GeneralizableElement. specialization Designates a Generalization whose child GeneralizableElement is the immediate descendent of the current GeneralizableElement. constraint All constraints on the parent apply to the child. isRoot isLeaf isAbstract Not inheritable by their very nature, but they define the generalization structure. IsRoot may be true only if there are no parents. IsLeaf may be true only if there are no children. name Each model element has a unique name. March 2003 OMG-Unified Modeling Language, v1.5 2-39 2 UML Semantics Attributes Associations Stereotypes Standard Constraints discriminator Designates the partition to which the Generalization link belongs. All of the Generalization links that share a given parent GeneralizableElement are divided into disjoint sets (that is, partitions) by their discriminator names. Each partition (a set of links sharing a discriminator name) represents an orthogonal dimension of specialization of the parent GeneralizableElement. The discriminator need not be unique. The empty string is also considered as a partition name, therefore all Generalization links have a discriminator. If the set of Generalization links that have the same parent all have the same name, then the children in the Generalization links are GeneralizableElements that specialize the parent, and an instance of any of them is a legal instance of the parent. Otherwise an indirect instance of the parent must be a (direct or indirect) instance of at least one element from each of the partitions. child Designates a GeneralizableElement that is the specialized version of the parent GeneralizableElement. parent Designates a GeneralizableElement that is the generalized version of the child GeneralizableElement. powertype Designates a Classifier that serves as a powertype for the child element along the dimension of generalization expressed by the Generalization. The child element is therefore an instance of the powertype element. «implementation» Class Specifies that the child inherits the implementation of the parent (its attributes, operations and methods) but does not make public the supplier’s interfaces nor guarantee to support them, thereby violating substitutability. This is private inheritance and is usually used only for programming implementation purposes. complete Generalization Specifies a constraint applied to a set of generalizations with the same discriminator and the same parent, indicating that any instance of the parent must be an instance of at least one child within the set of generalizations. If a parent has a single discriminator, the set of its child generalizations being complete implies that the parent is abstract. The connotation of declaring a set of generalizations complete is that all of the children with the given discriminator have been declared and that additional ones are not expected (in other words, the set of generalizations is closed), and designs may assume with some confidence that the set of children is fixed. If a new child is nevertheless added in the future, existing models may be adversely affected and may require modification. 2-40 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Standard Constraints (continued) 2.5.2.25 Interface An interface is a named set of operations that characterize the behavior of an element. In the metamodel, an Interface contains a set of Operations that together define a service offered by a Classifier realizing the Interface. A Classifier may offer several services, which means that it may realize several Interfaces, and several Classifiers may realize the same Interface. Interfaces are GeneralizableElements. Interfaces may not have Attributes, Associations, or Methods. An Interface may participate in an Association provided the Interface cannot see the Association; that is, a Classifier (other than an Interface) may have an Association to an Interface that is navigable from the Classifier but not from the Interface. Inherited Features Interface inherits features as specified in Classifier. 2.5.2.26 Method A method is the implementation of an operation. It specifies the algorithm or procedure that effects the results of an operation. In the metamodel, a Method is a declaration of a named piece of behavior in a Classifier and realizes one (directly) or a set (indirectly) of Operations of the Classifier. There may be at most one method for a particular classifier (as owner of the method) and operation (as specification of the method) pairing. disjoint Generalization Specifies a constraint applied to a set of generalizations, indicating that instance of the parent may be an instance of no more than one of the given children within the set of generalizations. This is the default semantics of generalization. incomplete Generalization Specifies a constraint applied to a set of generalizations with the same discriminator, indicating that an instance of the parent need not be an instance of a child within the set (but there is no guarantee that such an instance will actually exist). Being incomplete implies that the parent is concrete. The connotation of declaring a set of generalizations incomplete is that all of the children with the given discriminator have not necessarily been declared and that additional ones might be added, therefore users should not count on the set of children being fixed. overlapping Generalization Specifies a constraint applied to a set of generalizations, indicating that an instance of one child may be simultaneously an instance of another child in the set (but there is no guarantee that such an instance will actually exist). March 2003 OMG-Unified Modeling Language, v1.5 2-41 2 UML Semantics Attributes Associations 2.5.2.27 ModelElement A model element is an element that is an abstraction drawn from the system being modeled. Contrast with view element, which is an element whose purpose is to provide a presentation of information for human comprehension. In the metamodel, a ModelElement is a named entity in a Model. It is the base for all modeling metaclasses in the UML (even though it is not displayed explicitly as such on diagrams for ElementOwnership, ElementResidence, ElementImport, TemplateParameter, TemplateArgument, and Argument). All other modeling metaclasses are either direct or indirect subclasses of ModelElement. Each ModelElement can be regarded as a template. A template has a set of templateParameters that denotes which of the parts of a ModelElement are the template parameters. A ModelElement is a template when there is at least one template parameter. If it is not a template, a ModelElement cannot have template parameters. However, such embedded parameters are not usually complete and need not satisfy well-formedness rules. It is the arguments supplied when the template is instantiated that must be well formed. Partially instantiated templates are allowed. This is the case when there are arguments provided for some, but not all templateParameters. A partially instantiated template is still a template, since it still has parameters. Attributes Associations body The implementation of the Method as a ProcedureExpression. specification Designates an Operation that the Method implements. The Operation must be owned by the Classifier that owns the Method or be inherited by it. The signatures of the Operation and Method must match. name An identifier for the ModelElement within its containing Namespace. asArgument Indicates zero or more TemplateArgument for which the model element is an argument in a template binding. clientDependency Inverse of client. Designates a set of Dependency in which the ModelElement is a client. constraint A set of Constraints affecting the element. implementationLocation The component that an implemented model element resides in. 2-42 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Note that if a ModelElement has at least one templateParameter, then it is a template, otherwise it is an ordinary element. Tagged Values Inherited Features ModelElement is not a GeneralizableElement but some of its descendants are. The following elements are inherited by children of elements that are GeneralizableElements. namespace Designates the Namespace that contains the ModelElement. Every ModelElement except a root element must belong to exactly one Namespace or else be a composite part of another ModelElement (which is a kind of virtual namespace). The pathname of Namespace or ModelElement names starting from the root package provides a unique designation for every ModelElement. The association attribute visibility specifies the visibility of the element outside its namespace (see ElementOwnership). presentation A set of PresentationElements that present a view of the ModelElement. supplierDependency Inverse of supplier. Designates a set of Dependency in which the ModelElement is a supplier. templateParameter (association class TemplateParameter) A composite aggregation ordered list of parameters. Each parameter is a dummy ModelElement designated as a placeholder for a real ModelElement to be substituted during a binding of the template (see Binding). The real model element must be of the same kind (or a descendant kind) as the dummy ModelElement. The properties of the dummy ModelElement are ignored, except the name of the dummy element is used as the name of the template parameter. The association class TemplateParameter may be associated with a default ModelElement of the same kind as the dummy ModelElement. In the case of a Binding that does not supply an argument corresponding to the parameter, the value of the default ModelElement is used. If a Binding lacks an argument and there is no default ModelElement, the construct is invalid. Note that the template parameter element lacks structure. For example, a parameter that is a Class lacks Features; they are found in the actual argument. derived A true value indicates that the model element can be completely derived from other model elements and is therefore logically redundant. In an analysis model, the element may be included to define a useful name or concept. In a design model, the usual intent is that the element should exist in the implementation to avoid the need for recomputation. March 2003 OMG-Unified Modeling Language, v1.5 2-43 2 UML Semantics Non-Inherited Features 2.5.2.28 Namespace A namespace is a part of a model that contains a set of ModelElements each of whose names designates a unique element within the namespace. In the metamodel, a Namespace is a ModelElement that can own other ModelElements, like Associations and Classifiers. The name of each owned ModelElement must be unique within the Namespace. Moreover, each contained ModelElement is owned by at most one Namespace. The concrete subclasses of Namespace have additional constraints on which kind of elements may be contained. Namespace is an abstract metaclass. Note that explicit parts of a model element, such as the features of a Classifier, are not modeled as owned elements in a namespace. A namespace is used for unstructured contents such as the contents of a package or a class declared inside the scope of another class. Associations constraint The child is subject to all constraints of the parent. presentation The child is, by default, presented the same as the parent, but the presentation may be overridden. stereotype If a model element is classified by a stereotype, then its children are also classified by the stereotype. They may use the tags defined on the stereotype and they are subject to constraints imposed by the stereotype. taggedValue If a tag is defined to apply to a model element (for example, because it is classified by a stereotype defining the tag), then the tag applies to children of the model element.. clientDependency supplierDependency A general inheritance rule is not possible deploymentLocation The set of locations may differ. Often it is more restrictive on the child. implementationLocation The child may be implemented differently from the parent. name Each model element has its own name. Names are not inherited. namespace The child and the parent may be in different namespaces. templateParameter A parent and child may have different template structure. ownedElement (association class ElementOwnership) A set of ModelElements owned by the Namespace. Its visibility attribute states whether the element is visible outside the namespace. 2-44 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.5.2.29 Node A node is a run-time physical object that represents a computational resource, generally having at least a memory and often processing capability as well, and upon which components may be deployed. In the metamodel, a Node is a subclass of Classifier. It is associated with a set of Components that are deployed on the Node. Associations Inherited Features The following elements are inherited by a child Node, in addition to those specified under Classifier. Non-Inherited Features 2.5.2.30 Operation An operation is a service that can be requested from an object to effect behavior. An operation has a signature, which describes the actual parameters that are possible (including possible return values). In the metamodel, an Operation is a BehavioralFeature that can be applied to the Instances of the Classifier that contains the Operation. deployedComponent The set of Components deployed on the Node. (none) resident The set of resident elements may differ. Often it is more restrictive on the child. March 2003 OMG-Unified Modeling Language, v1.5 2-45 2 UML Semantics Attributes Tagged Values 2.5.2.31 Parameter A parameter is an unbound variable that can be changed, passed, or returned. A parameter may include a name, type, and direction of communication. Parameters are used in the specification of operations, messages and events, templates, etc. concurrency Specifies the semantics of concurrent calls to the same passive instance (i.e., an Instance originating from a Classifier with isActive=false). Active instances control access to their own Operations so this property is usually (although not required in UML) set to sequential. Possibilities include: • sequential - Callers must coordinate so that only one call to an Instance (on any sequential Operation) may be outstanding at once. If simultaneous calls occur, then the semantics and integrity of the system cannot be guaranteed. • guarded - Multiple calls from concurrent threads may occur simultaneously to one Instance (on any guarded Operation), but only one is allowed to commence. The others are blocked until the performance of the first Operation is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks. Guarded Operations must perform correctly (or block themselves) in the case of a simultaneous sequential Operation or guarded semantics cannot be claimed. • concurrent - Multiple calls from concurrent threads may occur simultaneously to one Instance (on any concurrent Operation). All of them may proceed concurrently with correct semantics. Concurrent Operations must perform correctly in the case of a simultaneous sequential or guarded Operation or concurrent semantics cannot be claimed. isAbstract If true, then the operation does not have an implementation, and one must be supplied by a descendant. If false, the operation must have an implementation in the class or inherited from an ancestor. isLeaf If true, then the implementation of the operation may not be overriden by a descendant class. If false, then the implementation of the operation may be overridden by a descendant class (but it need not be overridden). isRoot If true, then the class must not inherit a declaration of the same operation. If false, then the class may (but need not) inherit a declaration of the same operation. (But the declaration must match in any case; a class may not modify an inherited operation declaration.) semantics Operation Semantics is the specification of the meaning of the operation. 2-46 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics In the metamodel, a Parameter is a declaration of an argument to be passed to, or returned from, an Operation, a Signal, etc. Attributes Associations 2.5.2.32 Permission Permission is a kind of dependency. It grants a model element permission to access elements in another namespace. In the metamodel, Permission in a Dependency between a client ModelElement and a supplier ModelElement. The client receives permission to reference the supplier’s contents. The supplier must be a Namespace. The predefined stereotypes of Permission are access, import, and friend. In the case of the access and import stereotypes, the client is granted permission to reference elements in the supplier namespace with public visibility. In the case of the import stereotype, the public names in the supplier namespace are added to the client namespace. An element may also access any protected contents of an ancestor namespace. An element may also access any contents (public, protected, private, or package) of its own namespace or a containing namespace. In the case of the friend stereotype, the client is granted permission to reference elements in the supplier namespace, regardless of visibility. defaultValue An Expression whose evaluation yields a value to be used when no argument is supplied for the Parameter. kind Specifies what kind of a Parameter is required. Possibilities are: • in - An input Parameter (may not be modified). • out - An output Parameter (may be modified to communicate information to the caller). • inout - An input Parameter that may be modified. • return -A return value of a call. name (Inherited from ModelElement) The name of the Parameter, which must be unique within its containing Parameter list. type Designates a Classifier to which an argument value must conform. March 2003 OMG-Unified Modeling Language, v1.5 2-47 2 UML Semantics Stereotypes 2.5.2.33 PresentationElement A presentation element is a textual or graphical presentation of one or more model elements. In the metamodel, a PresentationElement is an Element which presents a set of ModelElements to a reader. It is the base for all metaclasses used for presentation. All other metaclasses with this purpose are either direct or indirect subclasses of PresentationElement. PresentationElement is an abstract metaclass. The subclasses of this class are proper to a graphic editor tool and are not specified here. It is a stub for their future definition. 2.5.2.34 Primitive A Primitive defines a predefined DataType, without any relevant UML substructure (i.e., it has no UML parts). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically. Primitive datatypes used in UML itself include Integer, UnlimitedInteger, and String. The run-time instances of a Primitive dataype are DataValues. The values are in many- to-one correspondence to mathemetical elements defined outside of UML (for example, the various integers). 2.5.2.35 ProgrammingLanguageDataType A data type is a type whose values have no identity (i.e., they are pure values). A programming language data type is a data type specified according to the semantics of a particular programming language, using constructs available in that language. There are a wide variety of programming languages and many of them include type constructs not included as UML classifiers. In some cases, it is important to represent those constructs such that their exact form in the programming language is available. The ProgrammingLanguagedData type captures such programming language types in a language-dependent fashion. They are represented by the name of the language and a string characterizing them, subject to interpretation by the particular language. Because «access» Class Access is a stereotyped permission dependency between two namespaces, denoting that the public contents of the target namespace are accessible to the namespace of the source package. «friend» Class Friend is a stereotyped permission dependency whose source is a model element, such as an operation, class, or package, and whose target is a model element in a different package, such as an operation, class, or package. A friend relationship grants the source access to the target regardless of the declared visibility. It extends the visibility of the supplier so that the client can see into the supplier. «import» Class Import is a stereotyped permission dependency between two namespaces, denoting that the public contents of the target package are added to the namespace of the source package. 2-48 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics they are dependent on particular languages, they are not portable among languages (except by agreement among the languages) and they do not map into other UML classifiers. Their semantics is therefore opaque within UML except by special interpretation by a profile intended for the particular language. Note that many or most programming language types can be directly represented using other UML classifiers, and such representation makes available deeper semantic analysis. A ProgrammingLanguageDataType may omit its name. Two ProgrammingLanguageDataType elements without names are not considered equivalent. Attributes Inherited Features ProgrammingLanguageDataType is meant to define language-dependent constructs for which inheritance properties are undefined in UML. 2.5.2.36 Relationship A relationship is a connection among model elements. In the metamodel, Relationship is a term of convenience without any specific semantics. It is abstract. Children of Relationship are Association, Dependency, Flow, and Generalization. 2.5.2.37 StructuralFeature A structural feature refers to a static feature of a model element, such as an attribute. In the metamodel, a StructuralFeature declares a structural aspect of an Instance of a Classifier, such as an Attribute. For example, it specifies the multiplicity and changeability of the StructuralFeature. StructuralFeature is an abstract metaclass. expression An expression for the ProgrammingLanguageDataType expressed in its particular programming language. March 2003 OMG-Unified Modeling Language, v1.5 2-49 2 UML Semantics Attributes Associations Tagged Values 2.5.2.38 TemplateArgument Reifies the relationship between a Binding and one of its arguments (a ModelElement). changeability Whether the value may be modified after the object is initialized. Possibilities are: • changeable - No restrictions on modification. • frozen - No values may be added or removed after the object is initialized. • addOnly - Values may be added anytime. No values may be removed after the object is initialized. multiplicity The possible number of data values for the feature that may be held by an instance. The cardinality of the set of values is an implicit part of the feature. In the common case in which the multiplicity is 1..1, then the feature is a scalar (i.e., it holds exactly one value). ordering Specifies whether the set of instances is ordered. The ordering must be determined and maintained by Operations that add values to the feature. This property is only relevant if the multiplicity is greater than one. Possibilities are: • unordered - The instances form a set with no inherent ordering. • ordered - A set of ordered instances can be scanned in order. • Other possibilities (such as sorted) may be defined later by declaring additional keywords. As with user-defined stereotypes, this would be a private extension supported by particular editing tools. targetScope Specifies whether the targets are ordinary Instances or Classifiers. Possibilities are: • instance - Each value contains a reference to an Instance of the target Classifier. This is the setting for a normal Attribute. • classifier - Each value contains a reference to the target Classifier itself. This represents a way to store meta-information. type Designates the classifier whose instances are values of the feature. Must be a Class, Interface, or DataType. The actual type may be a descendant of the declared type or (for an Interface) a Class that realizes the declared type. persistence Attribute Persistence denotes the permanence of the state of the feature, marking it as transitory (its state is destroyed when the instance is destroyed) or persistent (its state is not destroyed when the instance is destroyed). 2-50 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Associations 2.5.2.39 TemplateParameter Defines the relationship between a template (a ModelElement) and its parameter (a ModelElement). A ModelElement with at least one templateParameter association is a template (by definition). In the metamodel, TemplateParameter reifies the relationship between a ModelElement that is a template and a ModelElement that is a dummy placeholder for a template argument. See Section 2.5.2.27, “ModelElement,” on page 2-41, association templateParameter, for details. Associations 2.5.2.40 Usage A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. The relationship is not a mere historical artifact, but an ongoing need; therefore, two elements related by usage must be in the same model. In the metamodel, a Usage is a Dependency in which the client requires the presence of the supplier. How the client uses the supplier, such as a class calling an operation of another class, a method having an argument of another class, and a method from a class instantiating another class, is defined in the description of the particular Usage stereotype. Various stereotypes of Usage are predefined, but the set is open-ended and may be added to. binding The Binding that owns the template argument. modelElement The actual argument for the subject Binding. defaultElement An optional default value ModelElement. In case of a Binding of the template ModelElement in the reified TemplateParameter class association, the defaultElement is used as the argument of the bound element if no argument is supplied for the corresponding template parameter. If no argument is supplied and there is no default value, the model is ill formed. March 2003 OMG-Unified Modeling Language, v1.5 2-51 2 UML Semantics Stereotypes 2.5.3 Well-formedness Rules The following well-formedness rules apply to the Core package. 2.5.3.1 Association «call» Class Call is a stereotyped usage dependency whose source is an operation and whose target is an operation. The relationship may also be subsumed to the class containing an operation, with the meaning that there exists an operation in the class to which the dependency applies. A call dependency specifies that the source operation or an operation in the source class invokes the target operation or an operation in the target class. A call dependency may connect a source operation to any target operation that is within scope including, but not limited to, operations of the enclosing classifier and operations of other visible classifiers. «create» Class Create is a stereotyped usage dependency denoting that the client classifier creates instances of the supplier classifier. «instantiate» Class A stereotyped usage dependency among classifiers indicating that operations on the client create instances of the supplier. «send» Class Send is a stereotyped usage dependency whose source is an operation and whose target is a signal, specifying that the source sends the target signal. [1] The AssociationEnds must have a unique name within the Association. self.allConnections->forAll( r1, r2 | r1.name = r2.name implies r1 = r2 ) [2] At most one AssociationEnd may be an aggregation or composition. self.allConnections->select(aggregation <#none)->size <= 1 [3] If an Association has three or more AssociationEnds, then no AssociationEnd may be an aggregation or composition. 2-52 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Additional operations 2.5.3.2 AssociationClass Additional operations self.allConnections->size >=3 implies self.allConnections->forall(aggregation = #none) [4] The connected Classifiers of the AssociationEnds should be included in the Namespace of the Association, or be Classifiers with public visibility in other Namespaces to which the Namespace of the Association has “access” Permissions. self.allConnections->forAll(r | self.namespace.allContents->includes (r.participant) ) or self.allConnections->forAll(r | self.namespace.allContents->excludes (r.participant) implies self.namespace.clientDependency->exists (d | d.oclIsTypeOf(Permission) and d.stereotype.name = 'access' and d.supplier.oclAsType(Namespace).ownedElement->select (e | e.elementOwnership.visibility = #public)->includes (r.participant) or d.supplier.oclAsType(GeneralizableElement). allParents.oclAsType(Namespace).ownedElement->select (e | e. elementOwnership.visibility = #public)->includes (r.participant) or d.supplier.oclAsType(Package).allImportedElements->select (e | e. elementImport.visibility = #public) ->includes (r.participant) ) ) [1] The operation allConnections results in the set of all AssociationEnds of the Association. allConnections : Set(AssociationEnd); allConnections = self.connection [1] The names of the AssociationEnds and the StructuralFeatures do not overlap. self.allConnections->forAll( ar | self.allFeatures->forAll( f | f.oclIsKindOf(StructuralFeature) implies ar.name <> f.name )) [2] An AssociationClass cannot be defined between itself and something else. self.allConnections->forAll(ar | ar.participant <> self) [1] The operation allConnections results in the set of all AssociationEnds of the AssociationClass, including all connections defined by its parent (transitive closure). allConnections : Set(AssociationEnd); allConnections = self.connection->union(self.parent->select (s | s.oclIsKindOf(Association))->collect (a : Association | a.allConnections))->asSet March 2003 OMG-Unified Modeling Language, v1.5 2-53 2 UML Semantics 2.5.3.3 AssociationEnd Additional operations 2.5.3.4 Attribute 2.5.3.5 BehavioralFeature [1] The Classifier of an AssociationEnd cannot be an Interface or a DataType if the association is navigable away from that end. (self.participant.oclIsKindOf (Interface) or self.participant.oclIsKingOf (DataType)) implies self.association.connection->select (ae | ae <> self)->forAll(ae | ae.isNavigable = #false) [2] An Instance may not belong by composition to more than one composite Instance. self.aggregation = #composite implies self.multiplicity.upperbound = 1 [1] The operation upperbound returns the maximum upperbound value across all potential ranges of a multiplicity. upperbound( ) : UnlimitedInteger; upperbound = self.range->exists(r : MultiplicityRange | r.upper = result) and self.range->forall(r : MultiplicityRange | r.upper <= result) [1] Qualifier attributes have multiplicity of 1..1 self.associationEnd->notEmpty() implies self.multiplicity.is(1,1) [1] All Parameters should have a unique name. self.parameter->forAll(p1, p2 | p1.name = p2.name implies p1 = p2) [2] The type of the Parameters should be included in the Namespace of the Classifier. self.parameter->forAll( p | self.owner.namespace.allContents->includes (p.type) ) 2-54 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Additional operations 2.5.3.6 Binding [1] The operation hasSameSignature checks if the argument has the same signature as the instance itself. hasSameSignature ( b : BehavioralFeature ) : Boolean; hasSameSignature (b) = (self.name = b.name) and (self.parameter->size = b.parameter->size) and Sequence{ 1..(self.parameter->size) }->forAll( index : Integer | b.parameter->at(index).type = self.parameter->at(index).type and b.parameter->at(index).kind = self.parameter->at(index).kind ) [2] The operation matchesSignature checks if the argument has a signature that would clash with the signature of the instance itself (and therefore must be unique). Mismatches in kind or any differences in return parameters do not cause a mismatch: matchesSignature ( b : BehavioralFeature ) : Boolean; matchesSignature (b) = (self.name = b.name) and (self.parameter->size = b.parameter->size) and Sequence{ 1..(self.parameter->size) }->forAll( index : Integer | b.parameter->at(index).type = self.parameter->at(index).type or (b.parameter->at(index).kind = return and self.parameter->at(index).kind = return) ) [1] The client ModelElement must conform to the type of the supplier ModelElement in a Binding. self.client.oclIsKindOf(self.supplier) [2] Each argument ModelElement of the supplier must have the same type (or a descendant of the type) of the corresponding supplier parameter ModelElement in a Binding. let range : Set(Integer) = [1..self.arguments->size()] in range->forAll(index | arguments->at(index).oclIsKindOf( supplier.templateParameter->at(index).oclType [3] The number of arguments must equal the number of parameters. self.arguments->size() = self.supplier.templateParameter->size() [4] A Binding has one client and one supplier. (self.client->size = 1) and (self.supplier->size = 1) March 2003 OMG-Unified Modeling Language, v1.5 2-55 2 UML Semantics 2.5.3.7 Class 2.5.3.8 Classifier [5] A ModelElement may participate in at most one Binding as a client. Binding.allInstances->forAll [b1, b2 | (b1 <> b2) implies (b1.client <> b2.client)] [1] If a Class is concrete, all the Operations of the Class should have a realizing Method in the full descriptor. not self.isAbstract implies self.allOperations->forAll (op | self.allMethods->exists (m | m.specification->includes(op))) [2] A Class can only contain Classes, Associations, Generalizations, UseCases, Constraints, Dependencies, Collaborations, DataTypes, and Interfaces as a Namespace. self.allContents->forAll(c | ) c.oclIsKindOf(Class )or c.oclIsKindOf(Association ) or c.oclIsKindOf(Generalization)or c.oclIsKindOf(UseCase ) or c.oclIsKindOf(Constraint )or c.oclIsKindOf(Dependency )or c.oclIsKindOf(Collaboration )or c.oclIsKindOf(DataType ) or c.oclIsKindOf(Interface ) [1] No BehavioralFeature of the same kind may match the same signature in a Classifier. self.feature->forAll(f, g | ( ( (f.oclIsKindOf(Operation) and g.oclIsKindOf(Operation)) or (f.oclIsKindOf(Method ) and g.oclIsKindOf(Method )) or (f.oclIsKindOf(Reception) and g.oclIsKindOf(Reception)) ) and f.oclAsType(BehavioralFeature).matchesSignature(g) ) implies f = g) [2] No Attributes may have the same name within a Classifier self.feature->select ( a | a.oclIsKindOf (Attribute) )->forAll ( p, q | p.name = q.name implies p = q ) [3] No opposite AssociationEnds may have the same name within a Classifier. self.allOppositeAssociationEnds->forAll ( p, q | p.name = q.name implies p = q ) [4] The name of an Attribute may not be the same as the name of an opposite AssociationEnd or a ModelElement contained in the Classifier. 2-56 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Additional operations self.feature->select ( a | a.oclIsKindOf (Attribute) )->forAll ( a | not self.allOppositeAssociationEnds->union (self.allContents)->collect ( q | q.name )->includes (a.name) ) [5] The name of an opposite AssociationEnd may not be the same as the name of an Attribute or a ModelElement contained in the Classifier. self.oppositeAssociationEnds->forAll ( o | not self.allAttributes->union (self.allContents)->collect ( q | q.name )->includes (o.name) ) [6] For each Operation in a specification realized by the Classifier, the Classifier must have a matching Operation. self.specification.allOperations->forAll (interOp | self.allOperations->exists( op | op.hasMatchingSignature (interOp) ) ) [7] All of the generalizations in the range of a powertype have the same discriminator. self.powertypeRange->forAll (g1, g2 | g1.discriminator = g2.discriminator) [8] Discriminator names must be distinct from attribute names and opposite AssociationEnd names. self.allDiscriminators->intersection (self.allAttributes.name->union (self.allOppositeAssociationEnds.name))->isEmpty [1] The operation allFeatures results in a Set containing all Features of the Classifier itself and all its inherited Features. allFeatures : Set(Feature); allFeatures = self.feature->union( self.parent.oclAsType(Classifier).allFeatures) [2] The operation allOperations results in a Set containing all Operations of the Classifier itself and all its inherited Operations. allOperations : Set(Operation); allOperations = self.allFeatures->select(f | f.oclIsKindOf(Operation)) [3] The operation allMethods results in a Set containing all Methods of the Classifier itself and all its inherited Methods. allMethods : set(Method); allMethods = self.allFeatures->select(f | f.oclIsKindOf(Method)) [4] The operation allAttributes results in a Set containing all Attributes of the Classifier itself and all its inherited Attributes. allAttributes : set(Attribute); allAttributes = self.allFeatures->select(f | f.oclIsKindOf(Attribute)) [5] The operation associations results in a Set containing all Associations of the Classifier itself. associations : set(Association); associations = self.association.association->asSet March 2003 OMG-Unified Modeling Language, v1.5 2-57 2 UML Semantics 2.5.3.9 Comment No extra well-formedness rules. [6] The operation allAssociations results in a Set containing all Associations of the Classifier itself and all its inherited Associations. allAssociations : set(Association); allAssociations = self.associations->union ( self.parent.oclAsType(Classifier).allAssociations) [7] The operation oppositeAssociationEnds results in a set of all AssociationEnds that are opposite to the Classifier. oppositeAssociationEnds : Set (AssociationEnd); oppositeAssociationEnds = self.associations->select ( a | a.connection->select ( ae | ae.participant = self ).size = 1 )->collect ( a | a.connection-> select ( ae | ae.participant <> self ) )->union ( self.associations->select ( a | a.connection->select ( ae | ae.participant = self ).size > 1 )->collect ( a | a.connection) ) [8] The operation allOppositeAssociationEnds results in a set of all AssociationEnds, including the inherited ones, that are opposite to the Classifier. allOppositeAssociationEnds : Set (AssociationEnd); allOppositeAssociationEnds = self.oppositeAssociationEnds->union ( self.parent.allOppositeAssociationEnds ) [9] The operation specification yields the set of Classifiers that the current Classifier realizes. specification: Set(Classifier) specification = self.clientDependency-> select(d | d.oclIsKindOf(Abstraction) and d.stereotype.name = "realization" and d.supplier.oclIsKindOf(Classifier)) .supplier.oclAsType(Classifier) [10] The operation allContents returns a Set containing all ModelElements contained in the Classifier together with the contents inherited from its parents. allContents : Set(ModelElement); allContents = self.contents->union( self.parent.allContents->select(e | e.elementOwnership.visibility = #public or e.elementOwnership.visibility = #protected)) [11] The operation allDiscriminators results in a Set containing all Discriminators of the Generalizations from which the Classifier is descended itself and all its inherited Features. allDiscriminators : Set(Name); allDiscriminators = self.generalization.discriminator->union( self.parent.oclAsType(Classifier).allDiscriminators) 2-58 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.5.3.10 Component Additional operations 2.5.3.11 Constraint 2.5.3.12 DataType [1] A Component may only contain other Components in its namespace. self.allContents->forAll( c | c.oclIsKindOf(Component)) [2] A Component does not have any Features. self.feature->isEmpty [3] A Component may only have as residents DataTypes, Interfaces, Classes, Associations, Dependencies, Constraints, Signals, DataValues and Objects. self.allResidentElements->forAll( re | re.oclIsKindOf(DataType) or re.oclIsKindOf(Interface) or re.oclIsKindOf(Class) or re.oclIsKindOf(Association) or re.oclIsKindOf(Dependency) or re.oclIsKindOf(Constraint) or re.oclIsKindOf(Signal) or re.oclIsKindOf(DataValue) or re.oclIsKindOf(Object) ) [1] The operation allResidentElements results in a Set containing all ModelElements resident in a Component or one of its ancestors. allResidentElements : set(ModelElement) allResidentElements = self.resident->union( self.parent.oclAsType(Component).allResidentElements->select( re | re.elementResidence.visibility = #public or re.elementResidence.visibility = #protected)) [1] A Constraint cannot be applied to itself. not self.constrainedElement->includes (self) [1] A DataType can only contain Operations, which all must be queries. self.allFeatures->forAll(f | f.oclIsKindOf(Operation) and f.oclAsType(Operation).isQuery) [2] A DataType cannot contain any other ModelElements. self.allContents->isEmpty March 2003 OMG-Unified Modeling Language, v1.5 2-59 2 UML Semantics 2.5.3.13 Dependency No extra well-formedness rules. 2.5.3.14 Element No extra well-formedness rules. 2.5.3.15 ElementOwnership No additional well-formedness rules. 2.5.3.16 ElementResidence No additional well-formedness rules. 2.5.3.17 Enumeration No additional well-formedness rules. 2.5.3.18 EnumerationLiteral No additional well-formedness rules. 2.5.3.19 Feature No extra well-formedness rules. 2.5.3.20 GeneralizableElement [1] A root cannot have any Generalizations. self.isRoot implies self.generalization->isEmpty [2] No GeneralizableElement can have a parent Generalization to an element that is a leaf. self.parent->forAll(s | not s.isLeaf) [3] Circular inheritance is not allowed. not self.allParents->includes(self) [4] The parent must be included in the Namespace of the GeneralizableElement. self.generalization->forAll(g | self.namespace.allContents->includes(g.parent) ) [5] A GeneralizableElement may only be a child of GeneralizableElement of the same kind. self.generalization.parent->forAll(p | self.oclIsKindOf(p)) 2-60 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Additional Operations 2.5.3.21 Generalization No extra well-formedness rules. 2.5.3.22 ImplementationClass (stereotype of Class) 2.5.3.23 Interface 2.5.3.24 Method [1] The operation parent returns a Set containing all direct parents. parent : Set(GeneralizableElement); parent = self.generalization.parent [2] The operation allParents returns a Set containing all the Generalizable Elements inherited by this GeneralizableElement (the transitive closure), excluding the GeneralizableElement itself. allParents : Set(GeneralizableElement); allParents = self.parent->union(self.parent.allParents) [1] All direct instances of an implementation class must not have any other Classifiers that are implementation classes. self.instance.forall(i | i.classifier.forall(c | c.stereotype.name = "implementationClass" implies c = self)) [2] A parent of an implementation class must be an implementation class. self.parent->forAll(stereotype.name="implementationClass") [1] An Interface can only contain Operations. self.allFeatures->forAll(f | f.oclIsKindOf(Operation) or f.oclIsKindOf(Reception)) [2] An Interface cannot contain any ModelElements. self.allContents->isEmpty [3] All Features defined in an Interface are public. self.allFeatures->forAll ( f | f.visibility = #public ) [1] If the realized Operation is a query, then so is the Method. self.specification->isQuery implies self.isQuery [2] The signature of the Method should be the same as the signature of the realized Operation. self.hasSameSignature (self. specification) March 2003 OMG-Unified Modeling Language, v1.5 2-61 2 UML Semantics 2.5.3.25 ModelElement That part of the model owned by a template is not subject to all well-formedness rules. A template is not directly usable in a well formed model. The results of binding a template are subject to well-formedness rules. (not expressed in OCL) Additional operations [3] The visibility of the Method should be the same as for the realized Operation. self.visibility = self.specification.visibility [4] The realized Operation must be a feature (possibly inherited) of the same Classifier as the Method. self.owner.allOperations->includes(self.specification) [5] If the realized Operation has been overridden one or more times in the ancestors of the owner of the Method, then the Method must realize the latest overriding (that is, all other Operations with the same signature must be owned by ancestors of the owner of the realized Operation). self.specification.owner.allOperations->includesAll (self.owner.allOperations->select(op | self.hasSameSignature(op))) [6] There may be at most one method for a given classifier (as owner of the method) and operation (as specification of the method) pair. self.owner.allMethods->select(operation = self.operation)->size = 1 [1] The operation supplier results in a Set containing all direct suppliers of the ModelElement. supplier : Set(ModelElement); supplier = self.clientDependency.supplier [2] The operation allSuppliers results in a Set containing all the ModelElements that are suppliers of this ModelElement, including the suppliers of these Model Elements. This is the transitive closure. allSuppliers : Set(ModelElement); allSuppliers = self.supplier->union(self.supplier.allSuppliers) [3] The operation “model” results in the set of Models to which the ModelElement belongs. model : Set(Model); model = self.namespace->union(self.namespace.allSurroundingNamespaces) ->select( ns| ns.oclIsKindOf (Model)) [4] A ModelElement is a template when it has parameters. isTemplate : Boolean; isTemplate = (self.templateParameter->notEmpty) [5] A ModelElement is an instantiated template when it is related to a template by a Binding relationship. 2-62 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.5.3.26 Namespace Additional operations isInstantiated : Boolean; isInstantiated = self.clientDependency->select( oclIsKindOf(Binding))->notEmpty [6] The templateArguments are the arguments of an instantiated template, which substitute for template parameters. templateArguments : Set(ModelElement); templateArguments = self.clientDependency-> select(oclIsKindOf(Binding)).oclAsType(Binding).argument [1] If a contained element, which is not an Association or Generalization has a name, then the name must be unique in the Namespace. self.allContents->forAll(me1, me2 : ModelElement | ( not me1.oclIsKindOf (Association) and not me2.oclIsKindOf (Association) and me1.name <> ‘’ and me2.name <> ‘’ and me1.name = me2.name ) implies me1 = me2 ) [2] All Associations must have a unique combination of name and associated Classifiers in the Namespace. self.allContents -> select(oclIsKindOf(Association))-> forAll(a1, a2 | a1.name = a2.name and a1.connection.participant = a2.connection.participant implies a1 = a2) [1] The operation contents results in a Set containing all ModelElements contained by the Namespace. contents : Set(ModelElement) contents = self.ownedElement -> union(self.namespace, contents) [2] The operation allContents results in a Set containing all ModelElements contained by the Namespace. allContents : Set(ModelElement); allContents = self.contents [3] The operation allVisibleElements results in a Set containing all ModelElements visible outside of the Namespace. March 2003 OMG-Unified Modeling Language, v1.5 2-63 2 UML Semantics 2.5.3.27 Node No extra well-formedness rules. 2.5.3.28 Operation No additional well-formedness rules. 2.5.3.29 Parameter No additional well-formedness rules. 2.5.3.30 PresentationElement No extra well-formedness rules. 2.5.3.31 Primitive No additional well-formedness rules. 2.5.3.32 StructuralFeature allVisibleElements : Set(ModelElement) allVisibleElements = self.allContents -> select(e | e.elementOwnership.visibility = #public) [4] The operation allSurroundingNamespaces results in a Set containing all surrounding Namespaces. allSurroundingNamespaces : Set(Namespace) allSurroundingNamespaces = self.namespace->union(self.namespace.allSurroundingNamespaces) [1] The connected type should be included in the owner’s Namespace. self.owner.namespace.allContents->includes(self.type) [2] The type of a StructuralFeature must be a Class, DataType, or Interface. self.type.oclIsKindOf(Class) or self.type.oclIsKindOf(DataType) or self.type.oclIsKindOf(Interface) 2-64 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.5.3.33 Trace 2.5.3.34 Type (stereotype of Class) 2.5.3.35 Usage No extra well-formedness rules. 2.5.4 Detailed Semantics This section provides a description of the dynamic semantics of the elements in the Core. It is structured based on the major constructs in the core, such as interface, class, and association. 2.5.4.1 Association An association declares a connection (link) between instances of the associated classifiers (e.g., classes). It consists of at least two association ends, each specifying a connected classifier and a set of properties that must be fulfilled for the relationship to be valid. The multiplicity property of an association end specifies how many instances of the classifier at a given end (the one bearing the multiplicity value) may be associated with a single instance at each of the other ends, with single qualifier values at all qualified ends. A multiplicity is a range of nonnegative integers. When multiplicity is enforced is a semantic variation point. For example, implementations might allow violations of minimum multiplicity during object initialization. A trace is an Abstraction with the «trace» stereotype. These are the additional constraints due to the stereotype. [1] The client ModelElements of a Trace must all be from the same Model. self.client->forAll(e1, e2 | e1.model = e2.model) [2] The supplier ModelElements of a Trace must all be from the same Model. self.supplier->forAll(e1, e2 | e1.model = e2.model) [3] The client and supplier ModelElements must be from two different Models. self.client.model <> self.supplier.model [4] The client and supplier ModelElements must all be from models of the same system. self.client.model.intersection(self.supplier.model) <> Set{} [1] A Type may not have any Methods. not self.feature->exists(oclIsKindOf(Method)) [2] The parent of a type must be a type. self.parent->forAll(stereotype.name = "type") March 2003 OMG-Unified Modeling Language, v1.5 2-65 2 UML Semantics The association end also states whether or not a link may be traversed towards the object on that end from the objects on the other ends of the link (isNavigable). Navigability does not apply to getting an end object from a link object, that is, a link of an association class, because once a link object is obtained, the navigation has already taken place. The visibility of an association end specifies whether procedures and actions owned by other classifiers can navigate links of the association. Navigation is constrained by the visibility of the end being read. The options are relative to the classifiers at the other ends of the association. The association end may limit navigation of links to • procedures and actions owned by all classifiers (public), • classifiers at the other ends and their children (protected), • classifiers at the other ends and not their children (private), or • classifiers in the same package, or a nested subpackage, to any level (package). Visibility does not apply to getting an end object from a link object, that is, a link of an association class, because once a link object is visible to a procedure or action, all its ends are visible. An association end also specifies whether or not links may be created or destroyed after the initialization of objects at the opposite ends. The association end may state • that no constraints exist (changeable), • that a link may not be destroyed after the objects at the opposite ends have been initialized, and that new links may not be created after the objects that would participate in the new link at the opposite ends have been initialized (frozen), or, • that a link may not be destroyed after the objects at the opposite ends have been initialized (addOnly). Note that the semantics of frozen requires that objects participating in links with two or more frozen ends cannot have links created unless all the linked objects are being initialized. Changeability constraints affect when links may be created or destroyed, not whether links themselves are mutable. Links are not mutable once they are created, except that they can be destroyed and reordered. Qualifier values, end objects, and link classifier, if any, of a link cannot be changed once a link is created. Changeability constraints also do not affect the modifiability of the objects that are attached to the links, or the classifiers participating in the association. The ordering attribute of association end states that if the instances related to a single instance at each of the other ends, with single qualifier values at all qualified ends, have an ordering that must be preserved, the order of insertion of new links must be specified by operations that add or modify links. Note that sorting is a performance optimization and is not an example of a logically ordered association, because the ordering information in a sort does not add any information. 2-66 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics In UML, Associations can be of three different kinds: 1) ordinary association, 2) composite aggregate, and 3) shareable aggregate. Since the aggregate construct can have several different meanings depending on the application area, UML gives a more precise meaning to two of these constructs (i.e., association and composite aggregate) and leaves the shareable aggregate more loosely defined in between. An association may represent an aggregation (i.e., a whole/part relationship). In this case, the association-end attached to the whole element is designated, and the other association-end of the association represents the parts of the aggregation. Only binary associations may be aggregations. Composite aggregation is a strong form of aggregation, which requires that a part instance be included in at most one composite at a time and that the composite object has sole responsibility for the disposition of its parts. This means that the composite object is responsible for the creation and destruction of the parts. In implementation terms, it is responsible for their memory allocation. If a composite object is destroyed, it must destroy all of its parts. It may remove a part and give it to another composite object, which then assumes responsibility for it. If the multiplicity from a part to composite is zero-to-one, the composite may remove the part, and the part may assume responsibility for itself, otherwise it may not live apart from a composite. A consequence of these rules is that a composite implies propagation semantics (i.e., some of the dynamic semantics of the whole is propagated to its parts). For example, if the whole is copied or destroyed, then so are the parts as well (because a part may belong to at most one composite). A classifier on the composite end of an association may have parts that are classifiers and associations. At the instance level, an instance of a part element is considered “part of” the instance of a composite element. If an association is part of a composite and it connects two classes that are also part of the same composite, then a link of the association will connect objects that are part of the same composite object of which the link is part. A shareable aggregation denotes weak ownership (i.e., the part may be included in several aggregates) and its owner may also change over time. However, the semantics of a shareable aggregation does not imply deletion of the parts when an aggregate referencing it is deleted. Both kinds of aggregations define a transitive, antisymmetric relationship (i.e., the instances form a directed, non-cyclic graph). Composition instances form a strict tree (or rather a forest). A qualifier declares a partition of the set of associated instances with respect to an instance at the qualified end (the qualified instance is at the end to which the qualifier is attached). A qualifier instance comprises one value for each qualifier attribute. Given a qualified object and a qualifier instance, the number of objects at the other end of the association is constrained by the declared multiplicity. In the common case in which the multiplicity is 0..1, the qualifier value is unique with respect to the qualified object, and designates at most one associated object. In the general case of multiplicity 0..*, the set of associated instances is partitioned into subsets, each selected by a given qualifier instance. In the case of multiplicity 1 or 0..1, the qualifier has both semantic and implementation consequences. In the case of multiplicity 0..*, it has no real semantic consequences but suggests an implementation that facilitates easy access of sets of associated instances linked by a given qualifier value. March 2003 OMG-Unified Modeling Language, v1.5 2-67 2 UML Semantics Note that the multiplicity of a qualifier is given assuming that the qualifier value is supplied. The “raw” multiplicity without the qualifier is assumed to be 0..*. This is not fully general but it is almost always adequate, as a situation in which the raw multiplicity is 1 would best be modeled without a qualifier. Note also that a qualified multiplicity whose lower bound is zero indicates that a given qualifier value may be absent, while a lower bound of 1 indicates that any possible qualifier value must be present. The latter is reasonable only for qualifiers with a finite number of values (such as enumerated values or integer ranges) that represent full tables indexed by some finite range of values. 2.5.4.2 AssociationClass An association may be refined to have its own set of features (i.e., features that do not belong to any of the connected classifiers) but rather to the association itself. Such an association is called an association class. It will be both an association, connecting a set of classifiers, and a class, and as such have features and be included in other associations. The semantics of such an association is a combination of the semantics of an ordinary association and of a class. The AssociationClass construct can be expressed in a few different ways in the metamodel (e.g., as a subclass of Class, as a subclass of Association, or as a subclass of Classifier). Since an AssociationClass is a construct being both an association (having a set of association-ends) and a class (declaring a set of features), the most accurate way of expressing it is as a subclass of both Association and Class. In this way, AssociationClass will have all the properties of the other two constructs. Moreover, if new kinds of associations containing features (e.g., AssociationDataType) are to be included in UML, these are easily added as subclasses of Association and the other Classifier. The terms child, subtype, and subclass are synonyms and mean that an instance of a classifier being a subtype of another classifier can always be used where an instance of the latter classifier is expected. The neutral terms parent and child, with the transitive closures ancestor and descendant, are the preferred terms in this document. 2.5.4.3 Class The purpose of a class is to declare a collection of methods, operations, and attributes that fully describe the structure and behavior of objects. All objects instantiated from a class will have attribute values matching the attributes of the full class descriptor and support the operations found in the full class descriptor. Some classes may not be directly instantiated. These classes are said to be abstract and exist only for other classes to inherit and reuse the features declared by them. No object may be a direct instance of an abstract class, although an object may be an indirect instance of one through a subclass that is non-abstract. When a class is instantiated to create a new object, a new instance is created, which is initialized containing an attribute value for each attribute found in the full class descriptor. The object is also initialized with a connection to the list of methods in the full class descriptor. 2-68 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Note – An actual implementation behaves as if there were a full class descriptor, but many clever optimizations are possible in practice. Finally, the identity of the new object is returned to the creator. The identity of every instance in a well formed system is unique and automatic. A class can have generalizations to other classes. This means that the full class descriptor of a class is derived by inheritance from its own segment declaration and those of its ancestors. Generalization between classes implies substitutability (i.e., an instance of a class may be used whenever an instance of a superclass is expected). If the class is specified as a root, it cannot be a subclass of other classes. Similarly, if it is specified as a leaf, no other class can be a subclass of the class. Each attribute declared in a class has a visibility and a type. Visibility limits availability of the attribute to procedures and actions of any class (public), inside the class and its subclasses (protected), any classes within the containing package (package), or only inside the class (private). The targetScope of the attribute declares whether its value should be an instance (of a child) of that type or if it should be (a child of) the type itself. There are two alternatives for the ownerScope of an attribute: • it may state that each object created by the class (or by its subclasses) has its own value of the attribute, or • that the value is owned by the class itself. An attribute also declares how many attribute values should be connected to each owner (multiplicity). When multiplicity is enforced is a semantic variation point. For example, implementations might allow violations of minimum multiplicity during object initialization. An attribute also declares what the initial values should be, and if these attribute values may be changed: • none - no constraints exists, • frozen - values cannot be added or removed after the object has been initialized, or • addOnly - new values may be added anytime. Values cannot be removed after the object has been initialized. For each operation, the operation name, the types of the parameters, and the return type(s) are specified, as well as its visibility (see above). An operation may also include a specification of the effects of its invocation. The specification can be done in several different ways (e.g., with pre- and post-conditions, pseudo-code, or just plain text). Each operation declares if it is applicable to the instances, the class, or to the class itself (ownerScope). Furthermore, the operation states whether or not its application will modify the state of the object (isQuery). The operation also states whether or not the operation may be realized by a different method in a subclass (isPolymorphic). A method realizing an operation has the same signature as the operation and a procedure implementing the specification of the operation. Methods in descendents override and replace methods inherited from ancestors (see Section 2.5.4.4, “Inheritance,” on page 2-69). Each method implements an operation declared in the class or inherited from an ancestor. The same operation may be declared more than once in a full class descriptor, but their descriptions must all match, March 2003 OMG-Unified Modeling Language, v1.5 2-69 2 UML Semantics except that the generalization properties (isRoot, IsAbstract, isLeaf) may vary, and a child operation may strengthen query properties (the child may be a query even though the parent is not). The specification of the method must match the specification of its matching operation, as defined above for operations. Furthermore, if the isQuery attribute of an operation is true, then it must also be true in any realizing method. However, if it is false in the operation, it may still be true in the method if the method does not actually modify the state to carry out the behavior required by the operation (this can only be true if the operation does not inherently modify state). The visibility of a method must match its operation. Classes may have associations to each other. This implies that objects created by the associated classes are semantically connected (i.e., that links exist between the objects, according to the requirements of the associations). See Association on the next page. Associations are inherited by subclasses. A class may realize a set of interfaces. This means that each operation found in the full descriptor for any realized interface must be present in the full class descriptor with the same specification (see Semantics section Section 2.5.4.4, “Inheritance,” on page 2-69). The relationship between interface and class is not necessarily one-to-one; a class may offer several interfaces and one interface may be offered by more than one class. The same operation may be defined in multiple interfaces that a class supports; if their specifications are identical, then there is no conflict; otherwise, the model is ill formed. Moreover, a class may contain additional operations besides those found in its interfaces. A class acts as the namespace for various kinds of contained elements defined within its scope, including classes, interfaces, and associations (note that this is purely a scoping construction and does not imply anything about aggregation), the contained classifiers can be used as ordinary classifiers in the container class. If a class inherits another class, the contents of the ancestor are available to its descendents if the visibility of an element is public or protected; however, if the visibility is private, then the element is not visible and therefore not available in the descendant. 2.5.4.4 Inheritance To understand inheritance, it is first necessary to understand the concept of a full descriptor and a segment descriptor. A full descriptor is the full description needed to describe an object or other instance (see Section 2.5.4.5, “Instantiation,” on page2-70). It contains a description of all of the attributes, associations, and operations that the object contains. In a pre-object-oriented language, the full descriptor of a data structure was declared directly in its entirety. In an object-oriented language, the description of an object is built out of incremental segments that are combined using inheritance to produce a full descriptor for an object. The segments are the modeling elements that are actually declared in a model. They include elements such as class and other generalizable elements. Each generalizable element contains a list of features and other relationships that it adds to what it inherits from its ancestors. The mechanism of inheritance defines how full descriptors are produced from a set of segments connected by generalization. The full descriptors are implicit, but they define the structure of actual instances. 2-70 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Each kind of generalizable element has a set of inheritable features. For any model element, these include constraints. For classifiers, these include features (attributes, operations, signal receptions, and methods) and participation in associations. The ancestors of a generalizable element are its parents (if any) together with all of their ancestors (with duplicates removed). For a Namespace (such as a Package or a Class with nested declarations), the public or protected contents of the Namespace are available to descendants of the Namespace. If a generalizable element has no parent, then its full descriptor is the same as its segment descriptor. If a generalizable element has one or more parents, then its full descriptor contains the union of the features from its own segment descriptor and the segment descriptors of all of its ancestors. For a classifier, no attribute, operation, or signal with the same signature may be declared in more than one of the segments (in other words, they may not be redefined). A method may be declared in more than one segment. The way methods override each other is a semantic variation point. The constraints on the full descriptor are the union of the constraints on the segment itself and all of its ancestors. If any of them are inconsistent, then the model is ill formed. In any full descriptor for a classifier, each method must have a corresponding operation. In a concrete classifier, each operation in its full descriptor must have a corresponding method in the full descriptor. The purpose of the full descriptor is explained under Section 2.5.4.5, “Instantiation,” on page 2-70. 2.5.4.5 Instantiation The purpose of a model is to describe the possible states of a system and their behavior. The state of a system comprises objects, values, and links. Each object is described by a full class descriptor. The class corresponding to this descriptor is the direct class of the object. If an object is not completely described by a single class (multiple classification), then any class in the minimal set of unrelated (by generalization) classes whose union completely describes the object is a direct class of the object. Similarly each link has a direct association and each value has a direct data type. Each of these instances is said to be a direct instance of the classifier from which its full descriptor was derived. An instance is an indirect instance of the classifier or any of its ancestors. The data content of an object comprises one value for each attribute in its full class descriptor (and nothing more). The value must be consistent with the type of the attribute. The data content of a link comprises a tuple containing a list of instances, one that is an indirect instance of each participant classifier in the full association descriptor. The instances and links must obey any constraints on the full descriptors of which they are instances (including both explicit constraints and built-in constraints such as multiplicity). The state of a system is a valid system instance if every instance in it is a direct instance of some element in the system model and if all of the constraints imposed by the model are satisfied by the instances. March 2003 OMG-Unified Modeling Language, v1.5 2-71 2 UML Semantics The behavioral parts of UML describe the valid sequences of valid system instances that may occur as a result of both external and internal behavioral effects. 2.5.4.6 Interface The purpose of an interface is to collect a set of operations that constitute a coherent service offered by classifiers. Interfaces provide a way to partition and characterize groups of operations. An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, may use interfaces for specifying different services offered by their instances. Several classifiers may realize the same interface. All of them must contain at least the operations matching those contained in the interface. The specification of an operation contains the signature of the operation (i.e., its name, the types of the parameters, and the return type). An interface does not imply any internal structure of the realizing classifier. For example, it does not define which algorithm to use for realizing an operation. An operation may, however, include a specification of the effects of its invocation. The specification can be done in several different ways (e.g., with pre and post-conditions, pseudo-code, or just plain text). Each operation declares if it applies to the instances of the classifier declaring it or to the classifier itself (e.g., a constructor on a class (ownerScope)). Furthermore, the operation states whether or not its application will modify the state of the instance (isQuery). The operation also states whether or not all the classes must have the same realization of the operation (isPolymorphic). An interface can be a child of other interfaces denoted by generalizations. This means that a classifier offering the interface must provide not only the operations declared in the interface but also those declared in the ancestors of the interface. If the interface is specified as a root, it cannot be a child of other interfaces. Similarly, if it is specified as a leaf, no other interface can be a child of the interface. 2.5.4.7 Operation Operation is a conceptual construct, while Method is the implementation construct. Their common features, such as having a signature, are expressed in the BehavioralFeature metaclass, and the specific semantics of the Operation. The Method constructs are defined in the corresponding subclasses of BehavioralFeature. 2.5.4.8 PresentationElement The responsibility of presentation element is to provide a textual and graphical projection of a collection of model elements. In this context, projection means that the presentation element represents a human readable notation for the corresponding model elements. The notation for UML can be found in Chapter 3 of this document. Presentation elements and model elements must be kept in agreement, but the mechanisms for doing this are design issues for model editing tools. 2-72 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.5.4.9 Template A template is a parameterized model element that cannot be used directly in a model. Instead, it may be used to generate other model elements using the Binding relationship; those generated model elements can be used in normal relationships with other elements. A template represents the parameterization of a model element, such as a class or an operation, although conceptually any model element may be used (but not all may be useful). The template element is attached by composite aggregation to an ordered list of parameter elements. Each parameter element has a name that represents a parameter name within the template element. Any use of the name within the scope of the template element represents an unbound parameter that is to be replaced by an actual value in a Binding of the template. For example, a parameter may represent the type of an attribute of a class (for a class template). The corresponding attribute would have an association to the template parameter as its type. Note that the scope of the template includes all of the elements recursively owned by it through composite aggregation. For example, a parameterized class template owns its attributes, operations, and so on. Neither the parameterized elements nor its contents may be used directly in a model without binding. A template element has the templateParameter association to a list of ModelElements that serve as its parameters. To avoid introducing metamodel (M2) elements in an ordinary (M1) model, the model contains a representative of each parameter element, rather than the type of the parameter element. For example, a frequent kind of parameter is a class. Instead of including the metaclass Class in the (M1) ordinary model, a dummy class must be declared whose name is the name of the parameter. This dummy element is meaningful only within the template (it may not be used within the wider model) and it has no features (such as attributes and operations), because the features are part of an actual element that is supplied when the template is bound. Because a template parameter is only a dummy that lacks internal structure, it may violate well-formedness constraints of elements of its kind; the actual elements supplied during binding must satisfy ordinary well-formedness constraints. Note also that when the template is bound, the bound element does not show the explicit structure of an element of its kind; it is a stub. Its semantics and well- formedness rules must be evaluated as if the actual substitutions of actual elements for parameters had been made; but the expansions are not explicitly shown in a canonical model as they are regarded as derived. A template element is therefore effectively isolated from the directly-usable part of the model and is indirectly connected to its ultimate instances through Binding associations to bound elements. The bound elements may be used in ordinary models in places where the model element underlying the template could be used. 2.5.4.10 Miscellaneous A constraint is a Boolean expression over one or several elements that must always be true. A constraint can be specified in several different ways (e.g., using natural language or a constraint language). March 2003 OMG-Unified Modeling Language, v1.5 2-73 2 UML Semantics A dependency specifies that the semantics of a set of model elements requires the presence of another set of model elements. This implies that if the source is somehow modified, the dependents probably must be modified. The reason for the dependency can be specified in several different ways (e.g., using natural language or an algorithm) but is often implicit. A Usage or Binding dependency can be established only between elements in the same model, since the semantics of a model cannot be dependent on the semantics of another model. If a connection is to be established between elements in different models, a Trace or Refinement should be used. Refinement can connect elements in different or same models. Whenever the supplier element of a dependency changes, the client element is potentially invalidated. After such invalidation, a check should be performed followed by possible changes to the derived client element. Such a check should be performed after which action can be taken to change the derived element to validate it again. The semantics of this validation and change is outside the scope of UML. A data type is a special kind of classifier, similar to a class, but whose instances are primitive values (not objects). For example, the integers and strings are usually treated as primitive values. A primitive value does not have an identity, so two occurrences of the same value cannot be differentiated. Usually, it is used for specification of the type of an attribute. An enumeration type is a user-definable type comprising a finite number of values. 2.6 Extension Mechanisms 2.6.1 Overview The Extension Mechanisms package is the subpackage that specifies how specific UML model elements are customized and extended with new semantics by using stereotypes, constraints, tag definitions, and tagged values. A coherent set of such extensions, defined for specific purposes, constitutes a UML profile (see Section 2.15, “Model Management,” on page 2-181). The UML provides a rich set of modeling concepts and notations that have been carefully designed to meet the needs of typical software modeling projects. However, users may sometimes require additional features beyond those defined in the UML standard. These needs are met in UML by its built-in extension mechanisms that enable new kinds of modeling elements to be added to the modeler’s repertoire as well as to attach free-form information to modeling elements. The principal extension mechanism is the concept of Stereotype. It provides a way of defining virtual subclasses of UML metaclasses with new metaattributes and additional semantics. A fundamental constraint on all extensions defined using the profile extension mechanism is that extensions must be strictly additive to the standard UML semantics. This means that such extensions must not conflict with or contradict the standard semantics. In effect, these extension mechanisms are a means for refining the standard semantics of UML and do not support arbitrary semantic extension. They allow the modeler to add new modeling elements to UML for use in creating UML models for 2-74 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics process-specific or implementation language-specific domains (for example, supporting code generation for a certain language and infrastructure). It should be noted that stereotypes and tags are used in the definition of UML itself. They are used to define standard model elements that are not considered complex enough to be defined directly as UML metaclasses. Stereotypes are themselves metaclasses in UML. Consequently, the user of a UML tool can define stereotypes; for example, a new stereotype «persistent» could be defined that can be attached to classes. Many users will not define new stereotypes, but will only apply them during modeling; for example, the stereotype “«persistent»” can be attached to the class “Invoice” by the modeler. A tool could use this as an indicator that a database table definition needs to be generated. A profile is a stereotyped package that contains model elements that have been customized for a specific domain or purpose by extending the metamodel using stereotypes, tagged definitions, and constraints. A profile may specify model libraries on which it depends and the metamodel subset that it extends. A stereotype is a model element that defines additional values (based on tag definitions), additional constraints, and optionally a new graphical representation. All model elements that are branded by one or more particular stereotypes receive these values and constraints in addition to the attributes, associations, and superclasses that the element has in the standard UML. Stereotypes augment the classification mechanism based on the built in UML metamodel class hierarchy; therefore, names of new stereotypes must not clash with the names of predefined UML metamodel elements or standard elements. Tag definitions specify new kinds of properties that may be attached to model elements. The actual properties of individual model elements are specified using Tagged Values. These may either be simple datatype values or references to other model elements. Tag definitions can be compared to metaattribute definitions while tagged values correspond to values attached to model elements. They may be used to represent properties such as management information (author, due date, status), code generation information (optimizationLevel, containerClass). Constraints can also be attached to any model element to refine its semantics. Constraints attached to a stereotype must be observed by all model elements branded by that stereotype. If the rules are specified formally in a profile (for example, by using OCL for the expression of constraints), then a modeling tool may be able to interpret the rules and aid the modeler in enforcing them when applying the profile. Although it is outside the scope and intent of the UML specification, it is also possible to extend the UML metamodel by explicitly adding new metaclasses and other meta constructs. This capability depends on the use of tools and repositories that support the OMG Meta Object Facility (MOF). Profiles are sometimes referred to as the ‘lightweight’ built-in extension mechanisms of UML, in contrast with the ‘heavyweight’ extensibility mechanism as defined by the MOF specification. This is because there are restrictions on how UML profiles can extend the UML metamodel. These restrictions are intended to ensure that any extensions defined by a UML profile are purely additive. Such restrictions do not apply in the MOF context where, in March 2003 OMG-Unified Modeling Language, v1.5 2-75 2 UML Semantics principle, any metamodel can be defined. (Consequently, every profile definition could also be expressed as an MOF metamodel, but not all MOF metamodels based on UML can be expressed as proper UML profiles.) From a pragmatic viewpoint, when modeling tools are used to specify lightweight extensions, they should fully support UML extension mechanisms (including a default graphical notation for extended elements) and the XMI that they produce must be compatible with the predefined XMI for UML DTDs. (Note that this is expected to be less readable than a dedicated XMI format based on an MOF metamodel.) When defining profiles, modelers should be careful to base their extensions on the most semantically similar constructs in the UML metamodel. Failure to observe this can easily result in semantically incorrect or semantically redundant language extensions. When capturing the extended semantics of a domain in the definition of a profile (with the purpose of enabling tool support for the domain), modelers should also be careful not to focus exclusively on defining stereotypes. In most cases a combination of stereotypes and predefined standard model elements will be most effective. Examples of standard or common model elements in a profile definition are standard classes that the user is intended to reuse or subclass, or a set of standard Templates that the user may apply. Several profile-related standard stereotypes and tags are defined in the Model Management package and chapter, including «profile», «modelLibrary», «appliedProfile», and {applicableSubset}. The following sections describe the abstract syntax, well-formedness rules, and semantics of the Extension Mechanisms package. 2.6.2 Abstract Syntax The abstract syntax for the Extension Mechanisms package is expressed in graphic notation in Figure 2-10. 2-76 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Figure 2-10 Extension Mechanisms 2.6.2.1 Constraint (as extended) The constraint concept allows new semantics to be specified linguistically for a model element. The specification is written as an expression in a designated constraint language. The language can be specially designed for writing constraints (such as OCL), a programming language, mathematical notation, or natural language. If constraints are to be enforced by a model editor tool, then the tool must understand the syntax and semantics of the constraint language. Because the choice of language is arbitrary, constraints are an extension mechanism. In the metamodel, a constraint directly attached to a model element describes semantic restrictions that this model element must obey. Constraints attached to a Stereotype apply to each model element that bears that stereotype. Note that, for the case of constraints attached to stereotype definitions, the scope of the constraint is the UML metamodel and not the model in which it is defined. This allows the definition of well- formedness rules for stereotypes in the same manner as the well-formedness rules of other metamodel elements. GeneralizableElement (from Core) {xor} Stereotype icon : Geometry baseClass : Name Constrai nt (from Core) 0..1 * +constrainedSter eotype 0..1 +stereotypeConstraint * TagDefinition tagType : Name multiplicity : Multiplicity *0..1 +definedTag * +owner 0..1 ModelElement (from Core) * * +stereotype * +extendedElement * * * +constrainedElement *{ordered} +constraint * TaggedValue dataValue : String 1 * +type1 +typedValue* 1 * 1 +taggedValue* * * +referenceValue * +referenceTag* [*] [*] March 2003 OMG-Unified Modeling Language, v1.5 2-77 2 UML Semantics Attributes Associations Any one Constraint must have one or more constrainedElement links, or one constrainedStereotype link, but not both. 2.6.2.2 ModelElement (as extended) Any model element may have arbitrary tagged values and constraints (subject to these making sense). A model element may also have one or more stereotypes. In the latter case, the base class of the stereotype must match the metaclass of that model element (such as Class, Association, Dependency) or one of its subclasses. The presence of a stereotype may impose implicit constraints on the modeling element and may require the presence of specific tagged values. Associations body A boolean expression defining the constraint. Expressions are written as strings in a designated language. For the model to be well formed, the expression must always yield a true value when evaluated for instances of the constrained elements at any time when the system is stable; that is, not during the execution of an atomic operation. When a constraint is attached to a stereotype, the lexical scope of that constraint is the UML metamodel rather than the M1 model in which the constraint is defined. This means that there is no need to explicitly import the UML metamodel. constrainedElement An ordered list of elements subject to the constraint. constrainedStereotype A stereotype to which the constraint applies. This constraint will automatically apply to all model elements branded by that stereotype. constraint A constraint that must be satisfied by the model element. A model element may have a set of constraints. The constraint is to be evaluated when the system is stable; that is, not in the middle of an atomic operation. stereotype Designates the stereotypes that further qualify the UML metaclass (the base class or one of its subclasses) of the modeling element. The stereotype does not conflict with or contradict the standard semantics of the metaclass to which it applies, but may specify additional constraints and tag definitions. All constraints and tag definitions on a stereotype apply to the model elements that are branded by the stereotype. The stereotype acts as a virtual metaclass describing the model element. taggedValue An arbitrary property attached to the model element based on an associated tag definition. The interpretation of the tagged value is outside the scope of the UML metamodel. 2-78 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.6.2.3 Stereotype The stereotype concept provides a way of branding (classifying) model elements so that they behave in some respects as if they were instances of new virtual metamodel constructs. These model elements have the same structure (attributes, associations, operations) as similar non-stereotyped model elements of the same kind. The stereotype may specify additional constraints and tag definitions that apply to model elements. In addition, a stereotype may be used to indicate a difference in meaning or usage between two model elements with identical structure. In the metamodel, the Stereotype metaclass is a subclass of GeneralizableElement. Tag definitions and constraints attached to a stereotype apply to all model elements branded by that stereotype. A stereotype may also specify a geometrical icon to be used for presenting elements with the stereotype. If a stereotype is a subclass of another stereotype, then it inherits all of the constraints and tagged values from its stereotype supertype and it must apply to the same kind of base class. A stereotype keeps track of the base class to which it may be applied. Stereotypes are typically grouped in a Profile package. Attributes Associations 2.6.2.4 TagDefinition A tag definition specifies the tagged values that can be attached to a kind of model element. Among other things, tag definitions can be used to define the virtual meta attributes of the stereotype to which they are attached. Some of these meta attributes may be references to other metamodel elements and, in effect, can be used to specify new one-way meta references. However, this latter feature should be used with discretion since it can easily be misused to define new semantics that are more than just refinement of the original UML metamodel. baseClass Specifies the names of one or more UML modeling elements to which the stereotype applies, such as Class, Association, Refinement, Constraint. This is the name of a metaclass; that is, a class from the UML metamodel itself rather than a user model class. icon The geometrical description for an icon to be used to present an image of a model element branded by the stereotype. extendedElement Designates the model elements affected by the stereotype. Each one must be a model element of the kind specified by the baseClass attribute. definedTag Specifies a set of tag definitions, each of which specifies tagged values that a model element branded by the stereotype can have. stereotypeConstraint Designates constraints that apply to all model elements branded by this stereotype. These constraints are defined in the scope of the full UML metamodel. March 2003 OMG-Unified Modeling Language, v1.5 2-79 2 UML Semantics Tag definitions should be defined in conjunction with a stereotype since that allows them to be used in a more disciplined manner (stereotypes are constrained by the semantics of their base class). However, primarily for reasons of compatibility with models defined on the basis of UML 1.3, it is still possible to have tag definitions that are not associated with any stereotype. Attributes Associations 2.6.2.5 TaggedValue A tagged value allows information to be attached to any model element in conformance with its tag definition. Although a tagged value, being an instance of a kind of ModelElement, automatically inherits the name attribute, the name that is actually used in the tagged value is the name of the associated tag definition. The interpretation of tagged values is intentionally beyond the scope of UML semantics. It must be determined by user or tool conventions that may be specified in a profile in which the tagged value is defined. It is expected that various model analysis tools will define tag definitions to supply information needed for their operations beyond the basis semantics of UML. Such information could include code generation options, model management information, or user-specified semantics. Any tagged value must have one or more reference value links or one or more data values, but not both. Attributes multiplicity Specifies the number of data values that tagged values based on this tag must have, or, the number of model elements that can be associated to the related tagged values. tagType In the general case, where the tag type is a data type, this specifies the range of values of the tagged values associated with the tag definition. In the special case, where the tag type refers to a metaclass that is not a datatype, the tag value references model elements that are instances of the metaclass. typedValue The tagged values that conform to this tag definition. owner The stereotype to which this tag definition belongs. dataValue Specifies the set of values that are part of the tagged value. The type of this value must conform to the type specified in the tagType attribute of the associated tag definition. The number of values that can be specified is defined by the multiplicity attribute of the associated tag definition. 2-80 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Associations 2.6.3 Well-formedness Rules The following well-formedness rules apply to the Extension Mechanisms package. 2.6.3.1 Constraint 2.6.3.2 ModelElement type Specifies the tag definition that defines the name, meaning, and type of the tagged value. referenceValue Specifies the model elements that this tagged value references. These elements are model-level instances of the metaclass or stereotype specified by the tagType attribute of the corresponding tag definition. The number of references is defined by the multiplicity attribute of the associated tag definition. [1] A Constraint attached to a stereotype must not conflict with constraints on any inherited stereotype, or associated with the base class. -- cannot be specified with OCL, level M2 not accessible [2] A constraint attached to a stereotyped model element (either directly or through another stereotype) must not conflict with any constraints on the associated stereotype, nor with the class (the base class) of the model element. -- cannot be specified with OCL, level M2 not accessible [3] A constraint attached to a stereotype will apply to all model elements branded by that stereotype and must not conflict with any constraints on the attached branding stereotype, nor with the class (the base class) of the model element. -- cannot be specified with OCL, level M2 not accessible [1] Tags associated with a model element (directly via a property list or indirectly via a stereotype) must not clash with any meta attributes associated with the model element. -- cannot be specified with OCL, level M2 not accessible [2] A model element must have at most one tagged value with a given tag name. self.taggedValue->forAll(t1, t2 : TaggedValue | t1.type.name = t2.type.name implies t1 = t2) [3] A stereotype cannot extend itself. self.stereotype->excludes(self) March 2003 OMG-Unified Modeling Language, v1.5 2-81 2 UML Semantics 2.6.3.3 Stereotype Additional Operations 2.6.3.4 TagDefinition [1] Stereotype names must not clash with any base class names. Stereotype.allInstances->forAll(st | st.baseClass <> self.name) [2] The base class name must be provided Set {self.baseClass}->notEmpty [3] Tag names attached to a stereotype must not clash with M2 meta-attribute namespace of the appropriate base class element, nor with tag definition names of any inherited stereotype -- cannot be specified with OCL, level M2 not accessible [4] The base class of a stereotype must be the same or a subclass of the base class of parent stereotypes. -- cannot be specified with OCL, level M2 not accessible [5] All stereotype definitions must be contained either directly or transitively in a profile package. findProfile(self)->notEmpty [1] The find profile operation returns either the single-element set containing profile package in which the model element is defined or an empty set if the element is not contained in any profile. findProfile (me : ModelElement) : Set (Package) if (me.namespace->notEmpty) then if (me.namespace.oclIsKindOf(Package) and me.namespace.stereotype->notEmpty) and me.namespace.stereotype->exists(s|s.name = profile) then result = me.namespace else -- go up to the next level of namespace result = findProfile (me.namespace) else result = me.namespace -- return empty set [1] The type associated with a tag definition is either the name of a UML metaclass, including elements of the DataType package, or an instance of the DataType metaclass or one of its descendants. -- cannot be specified with OCL, level M2 not accessible [2] All tag definitions must be contained either directly or transitively in a profile package. findProfile(self)->notEmpty 2-82 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.6.3.5 TaggedValue 2.6.4 Detailed Semantics The various extension mechanisms defined in this chapter represent extensions to the modeling language UML that affect the structure and semantics of models produced by the user. Within a model, any user-level model element may have a set of links to stereotypes, and a set of tagged values conformant to existing tag definitions. The constraints defined for the stereotype specify restrictions on the instantiation of the model. An instance of a user-level model element must satisfy all of the constraints on its model element for the model to be well formed. Evaluation of constraints is to be performed when the relevant portion of the system is “stable,” that is, after the completion of any internal operations when it is waiting for external events. In general, constraints are written in any language that can adequately specify the desired constraints, such as OCL, C++, or natural language. The interpretation of the constraints must be specified by the constraint language. A stereotype refers to a base class, which is a class in the UML metamodel (not a user- level modeling element) such as Class, Association, Refinement, etc. A stereotype may be a subclass of one or more existing stereotypes. In that case, it inherits their constraints and tag definitions and may add additional ones of its own. In principle, a stereotype inherits the base class value of its parent, if one exists (this is expressed as a constraint on these values). The modeler may refine this to any subclass of that base class. For instance, if a stereotype s with a base class b is defined, then a stereotype t that has s as its superclass has either b or any subclass of b as its base class value. If a stereotype has multiple superclasses, then all of these superclasses must be derived from a single common superclass. In that case, the base class of the subclass is equivalent to the most specific parent stereotype, or a subclass of that. For instance, if a stereotype s has supertypes t and u with base classes “Classifier” and “Class” respectively, then the base class of s is “Class” or any subclass of “Class” in UML. [1] The data value of a tagged value is exclusive to the “referenceValue” association. if (self.referenceValue->size > 0) then (self.dataValue->size = 0) else (self.dataValue->size > 0) endif [2] The data value of a tagged value must conform to the data type specified by the “tagType” attribute of the tag definition. -- cannot be specified with OCL (requires an OCL function that converts a string name into a corresponding metatype) [3] The model elements associated with a tagged value by the “referenceValue” association must be instances of the metaclass specified by the “tagType” attribute of the tag definition. -- cannot be specified with OCL (requires an OCL function that converts a string name into a corresponding metatype) March 2003 OMG-Unified Modeling Language, v1.5 2-83 2 UML Semantics If a model element is branded by an attached stereotype, then the UML base class of the model element must be the base class specified by the stereotype or one of the subclasses of that base class. Any constraints on the stereotype are implicitly attached to the model element. Any tag definitions belonging to the stereotype will serve as specifications for tagged values associated to the model element. If the stereotype is a subclass of one or more stereotypes, then any constraints or tag definitions from those stereotypes also apply to the model element (because they are inherited by this stereotype). If there are any conflicts among the multiple constraints and tag definitions (inherited or directly specified), then the model is ill formed, as is the case with general specialization hierarchies. 2.6.5 Notes Backward compatibility of profiles with UML 1.3 has been addressed by maintaining the basic UML 1.3 extension features while adding new features that can be optionally exploited. There are two areas where backward compatibility has been carefully considered. First, although it is generally recommended that tags should be defined in the context of a stereotype, they may still be defined independently as was the case with UML 1.3. Second, although it is generally recommended that tag definitions should be typed, they may still be defined with type declared String; that is, they are effectively not typed. UML 1.4 compliant tools are expected to make use of the ability to type tags, and to provide conversion utilities for models based on earlier versions of UML. It is important to note, however, that older models that contain tags declared to be of type String should still work correctly, since String continues to be a standard UML datatype. The following are some typical examples of stereotypes and tag definitions: A stereotype of Class with an associated tag definition Stereotype Base Class Parent Tags Constraints Description persistent Class N/A storageMode none Classes of this stereotype are persistent and may be stored in a variety of different modes. Tag Stereotype Type Multiplicity Description storageMode persistent StorageProfile::StorageEnum (an enumeration: {table, file, object}) * identifies the storage mode 2-84 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics A stereotype of Class with an associated tag definition A stereotype of Class with an associated tag definition A stereotype of Class with an associated tag definition A tag defined independently of a stereotype A tag defined independently of a stereotype 2UML Semantics Stereotype Base Class Parent Tags Constraints Description persistent Class N/A isPersistent none Classes of this stereotype may be persistent, depending on the value of the “isPersistent” tag. Tag Stereotype Type Multiplicity Description isPersistent persistent UML::Datatypes::Boolean 1 indicates whether the class is persistent or not Stereotype Base Class Parent Tags Constraints Description persistent Class N/A primaryKeyClass none Classes of this stereotype have a reference to indicate the primary key specification. Tag Stereotype Type Multiplicity Description primaryKeyClass persistent reference to UML::Foundation::Class 1 Identifies the M1 class that serves as the primary key. Stereotype Base Class Stereotype Parent Tags Constraints Description workflow ActionState N/A resources none action states of this stereotype represent workflow actions. Tag Stereotype Type Multiplicity Description debugMode N/A DebugProfile::DebugDomain (an enumeration with three possible choices: {on, off, trace}) 1 Used to set the desired debug mode for a model post-processor. Tag Stereotype Type Multiplicity Description aliasNames N/A UML::Datatypes::String * Reuses the standard String datatype at the M1 level. March 2003 OMG-Unified Modeling Language, v1.5 2-85 2 UML Semantics 2.7 Data Types 2.7.1 Overview The Data Types package is the subpackage that specifies the different data types that are used to define UML. This chapter has a simpler structure than the other packages, since it is assumed that the semantics of these basic concepts are well known. 2.7.2 Abstract Syntax The abstract syntax for the Data Types package is expressed in graphic notation in Figure 2-11 and Figure 2-12. Figure 2-11 Data Types Package - Main Figure 2-12 Data Types Package - Expressions AggregationKind <> Boolean <> ChangeableKind <> Expression language : Name body : String Name Int eger ParameterDirectionKind <> ScopeKind <> String VisibilityKind <> PseudostateKind <> CallConcurrencyKind <> Mult ip li ci ty Ran ge lower : Integer upper : UnlimitedInteger Multiplicity 1..*1 +range 1..*1 Ma pp in g body : String UnlimitedInteger LocationReference OrderingKind <> Geometry ooleanExpression TimeExpression TypeExpressionArgLis tsExpression MappingExpression Expression language : Name body : String ProcedureExpression 2-86 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics In the metamodel, the data types are used for declaring the types of the class attributes. They appear as strings in the diagrams and not with a separate ‘data type’ icon. In this way, the sizes of the diagrams are reduced. However, each occurrence of a particular name of a data type denotes the same data type. Note that these data types are the data types used for defining UML and not the data types to be used by a user of UML. The latter data types will be instances of the DataType metaclass defined in the metamodel. 2.7.3.1 AggregationKind An enumeration that denotes what kind of aggregation an Association is. When placed on a target end, specifies the relationship of the target end to the source end. AggregationKind defines an enumeration whose values are: 2.7.3.2 ArgListsExpression In the metamodel, ArgListsExpression defines a statement which will result in a set of object lists when it is evaluated. 2.7.3.3 Boolean In the metamodel, Boolean defines an enumeration that denotes a logicial condition. Its enumeration literals are: 2.7.3.4 BooleanExpression In the metamodel, BooleanExpression defines a statement that will evaluate to an instance of Boolean when it is evaluated. 2.7.3.5 CallConcurrencyKind An enumeration that denotes the semantics of multiple concurrent calls to the same passive instance (i.e., an Instance originating from a Classifier with isActive=false). It is an enumeration with the values. none The end is not an aggregate. aggregate The end is an aggregate; therefore, the other end is a part and must have the aggregation value of none. The part may be contained in other aggregates. composite The end is a composite; therefore, the other end is a part and must have the aggregation value of none. The part is strongly owned by the composite and may not be part of any other composite. true The Boolean condition is satisfied. false The Boolean condition is not satisfied. March 2003 OMG-Unified Modeling Language, v1.5 2-87 2 UML Semantics 2.7.3.6 ChangeableKind In the metamodel, ChangeableKind defines an enumeration that denotes how an AttributeLink or LinkEnd may be modified. Its values are: 2.7.3.7 Expression In the metamodel, an Expression defines a statement which will evaluate to a (possibly empty) set of instances when executed in a context. An Expression does not modify the environment in which it is evaluated. An expression contains an expression string and the name of an interpretation language with which to evaluate the string. Attributes sequential Callers must coordinate so that only one call to an Instance (on any sequential Operation) may be outstanding at once. If simultaneous calls occur, then the semantics and integrity of the system cannot be guaranteed. guarded Multiple calls from concurrent threads may occur simultaneously to one Instance (on any guarded Operation), but only one is allowed to commence. The others are blocked until the performance of the first Operation is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks. Guarded Operations must perform correctly (or block themselves) in the case of a simultaneous sequential Operation or guarded semantics cannot be claimed. concurrent Multiple calls from concurrent threads may occur simultaneously to one Instance (on any concurrent Operation). All of them may proceed concurrently with correct semantics. Concurrent Operations must perform correctly in the case of a simultaneous sequential or guarded Operation or concurrent semantics cannot be claimed. changeable No restrictions on modification. frozen The value may not be changed from the source end after the creation and initialization of the source object. Operations on the other end may change a value. addOnly If the multiplicity is not fixed, values may be added at any time from the source object, but once created a value may not be removed from the source end. Operations on the other end may change a value. language Names the language in which the expression body is represented. The interpretation of the expression depends on the language. If the language name is omitted, no interpretation for the expression can be assumed by UML. body The text of the expression expressed in the given language. 2-88 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Predefined language names include the following: In general, a language name should be spelled and capitalized exactly as it appears in the document defining the language. For example, use COBOL, not Cobol; use Ada, not ADA; use PostScript, not Postscript. In other words, spell it correctly. 2.7.3.8 Geometry An uninterpreted type used to describe the geometrical shape of icons, such as those that may be attached to stereotypes. The details of this specification are not currently part of UML and must therefore be supplied by the implementation of a model editing tool, with the understanding that they will likely be tool-specific. This type is therefore not actually defined in the metamodel but is used only as the type of attributes. 2.7.3.9 Integer In the metamodel, Integer is a classifier element that is an instance of Primitive, representing the predefined type of integers. An instance of Integer an element in the (infinite) set of integers (…-2, -1, 0, 1, 2…). 2.7.3.10 LocationReference Designates a position within a behavior sequences for the insertion of an extension use case. May be a line or range of lines in code, or a state or set of states in a state machine, or some other means in a different kind of specification. 2.7.3.11 Mapping In the metamodel, a Mapping is an expression that is used for mapping ModelElements. For exchange purposes, it should be represented as a String. Attributes 2.7.3.12 MappingExpression An expression that evaluates to a mapping. OCL The Object Constraint Language (see Chapter 6, “Object Constraint Language Specification”). (The empty string) This represents a natural-language statement. As such, it is obviously intended for human information rather than formal specification. body A string describing the mapping. The format of the mapping is currently unspecified in UML. March 2003 OMG-Unified Modeling Language, v1.5 2-89 2 UML Semantics 2.7.3.13 Multiplicity In the metamodel, a Multiplicity defines a non-empty set of non-negative integers. A set which only contains zero ({0}) is not considered a valid Multiplicity. Every Multiplicity has at least one corresponding String representation. Additional operations 2.7.3.14 MultiplicityRange In the metamodel, a MultiplicityRange defines a range of integers. The upper bound of the range cannot be below the lower bound. The lower bound must be a nonnegative integer. The upper bound must be a nonnegative integer or the special value unlimited, which indicates there is no upper bound on the range. Additional operations [1] The allows operation takes an integer as input. It checks if a given integer cardinality is allowed by a multiplicity. allows(i : Integer) : Boolean; allows(i) = self.range->exists(r : MultiplicityRange |r.contains(i)) [2] The operation compatibleWith takes another multiplicity as input. It checks if one multiplicity is compatible with another. compatibleWith(other : Multiplicity) : Boolean; compatibleWith(other) = Integer.allInstances()-> forAll(i : Integer | self.allows(i) implies other.allows(i)) [3] The operation lowerbound returns the lowest lower bound of the ranges in a multiplicity. lowerbound( ) : Integer; lowerbound = self.range->exists(r : MultiplicityRange |r.lower = result) and self.range->forall(r : MultiplicityRange |r.lower <= result) [4] The operation upperbound returns the highest upper bound of the ranges in a multiplicity. upperbound( ) : UnlimitedInteger; upperbound = self.range->exists(r : MultiplicityRange |r.upper = result) and self.range->forall(r : MultiplicityRange |r.upper <= result) [5] The is operation determines if the upper and lower bound of the ranges are the ones given. is(lowerbound : integer, upperbound : unlimitedInteger) : Boolean is(lowerbound, upperbound) = (lowerbound = self.lowerbound and upperbound = self.upperbound) [1] The operation contains takes an integer as input and checks if a given integer is within the range specified by a multiplicity range. contains(i : Integer) : Boolean; contains(i) = (self.lower<=i and i<=self.upper) 2-90 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.7.3.15 Name In the metamodel, a Name defines a token which is used for naming ModelElements. A name is represented as a String. 2.7.3.16 OrderingKind Defines an enumeration that specifies how the elements of a set are arranged. Used in conjunction with elements that have a multiplicity in cases when the multiplicity value is greater than one. The ordering must be determined and maintained by operations that modify the set. The intent is that the set of enumeration literals be open for new values to be added by tools for purposes of design, code generation, etc. For example, a value of sorted might be used for a design specification. Values are: 2.7.3.17 ParameterDirectionKind In the metamodel, ParameterDirectionKind defines an enumeration that denotes if a Parameter is used for supplying an argument and/or for returning a value. The enumeration values are: 2.7.3.18 ProcedureExpression In the metamodel, ProcedureExpression defines a statement that will result in a change to the values of its environment when it is evaluated. 2.7.3.19 PseudostateKind In the metamodel, PseudostateKind defines an enumeration that discriminates the kind of Pseudostate. See Section 2.7.3.19, “PseudostateKind,” on page 2-90 for details. The enumeration values are listed below. unordered The elements of the set have no inherent ordering. ordered The elements of the set have a sequential ordering. Other possibilities (such as sorted) may be defined later by declaring additional keywords. As with user-defined stereotypes, this would be a private extension supported by particular editing tools. in An input Parameter (may not be modified). out An output Parameter (may be modified to communicate information to the caller). inout An input Parameter that may be modified. return A return value of a call. March 2003 OMG-Unified Modeling Language, v1.5 2-91 2 UML Semantics 2.7.3.20 ScopeKind In the metamodel, ScopeKind defines an enumeration that denotes whether a feature belongs to individual instances or an entire classifier. Its values are: 2.7.3.21 String In the metamodel, String is a classifier element that is an instance of Primitive. An instance of String defines a piece of text. 2.7.3.22 TimeExpression In the metamodel, TimeExpression defines a statement that will define the time of occurrence of an event. The specific format of time expressions is not specified here and is subject to implementation considerations. choice Splits an incoming transition into several disjoint outgoing transitions. Each outgoing transition has a guard condition that is evaluated after prior actions on the incoming path have been completed. At least one outgoing transition must be enabled or the model is ill formed. deepHistory When reached as the target of a transition, restores the full state configuration that was active just before the enclosing composite state was last exited. fork Splits an incoming transition into several concurrent outgoing transitions. All of the transitions fire together. initial The default target of a transition to the enclosing composite state. join Merges transitions from concurrent regions into a single outgoing transition. All the transitions fire together. junction Chains together transitions into a single run-to-completion path. May have multiple input and/or output transitions. Each complete path involving a junction is logically independent and only one such path fires at one time. May be used to construct branches and merges. shallowHistory When reached as the target of a transition, restores the state within the enclosing composite state that was active just before the enclosing state was last exited. Does not restore any substates of the last active state. instance The feature pertains to Instances of a Classifier. For example, it is a distinct Attribute in each Instance or an Operation that works on an Instance. classifier The feature pertains to an entire Classifier. For example, it is an Attribute shared by the entire Classifier or an Operation that works on the Classifier, such as a creation operation. 2-92 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.7.3.23 TypeExpression In the metamodel, TypeExpression is the encoding of a programming language type in the interpretation language. It is used within a ProgrammingLanguageDataType. 2.7.3.24 UnlimitedInteger In the metamodel, UnlimitedInteger is a classifier element that is an instance of Primitive. It defines a data type whose range is the nonnegative integers augmented by the special value “unlimited.” It is used for the upper bound of multiplicities. Additional operations 2.7.3.25 VisibilityKind In the metamodel, VisibilityKind defines an enumeration that denotes how the element to which it refers is seen outside the enclosing name space. Its values are: 2ML Semantics Part 3 - Behavioral Elements This Behavioral Elements package is the language superstructure that specifies the dynamic behavior or models. The Behavioral Elements package is decomposed into the following subpackages: Common Behavior, Collaborations, Use Cases, State Machines, Activity Graphs, and Actions. 2.8 Behavioral Elements Package Common Behavior specifies the core concepts required for behavioral elements. The Collaborations package specifies a behavioral context for using model elements to accomplish a particular task. The Use Case package specifies behavior using actors and use cases. The State Machines package defines behavior using finite-state transition [1] The operation <= determines whether an unlimited integer is less than or equal to another. <= (ui2 : unlimitedInteger) : Boolean; <= (ui2) = (ui2 = #unlimited or (self <> #unlimited and self.oclAsType(Integer) <= ui2.oclAsType(Integer))) public Other elements may see and use the target element. protected Descendants of the source element may see and use the target element. private Only the source element may see and use the target element. package Elements declared in the same package as the target element may see and use the target element. March 2003 OMG-Unified Modeling Language, v1.5 2-93 2 UML Semantics systems. The Activity Graphs package defines a special case of a state machine that is used to model processes. The Actions package defines behavior using a detailed model of computation. Figure 2-13 Behavioral Elements Package 2.9 Common Behavior 2.9.1 Overview The Common Behavior package is the most fundamental of the subpackages that compose the Behavioral Elements package. It specifies the core concepts required for dynamic elements and provides the infrastructure to support Collaborations, State Machines, Use Cases, and Actions. The following sections describe the abstract syntax, well-formedness rules and semantics of the Common Behavior package. Use Cases State MachinesCollaborations Common Behavior Activity Graphs Actions 2-94 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.9.2 Abstract Syntax The abstract syntax for the Common Behavior package is expressed in graphic notation in the following figures. Figure 2-14 shows the model elements that define Signals and Receptions. Figure 2-14 Common Behavior - Signals Figure 2-15 on page 2-95 illustrates the Procedure model element and its support for Expressions and Methods. Exception Reception specification : String isRoot : Boolean isLeaf : Boolean isA bstract : B oolean BehavioralFeature (fro m C ore) Signal 1 0..* + signal 1 +reception 0..* ** +context * +raisedSignal * Classifier (from Core) March 2003 OMG-Unified Modeling Language, v1.5 2-95 2 UML Semantics Figure 2-15 Common Behavior - Procedure Figure 2-16 on page 2-96 shows the model elements that define Instances and Links. Method (from Core) Procedure language : Name body : String isList : Boolean 0..* 0..1 +method 0..* +procedure 0..1 Expression (from Data Types)0..1 0..* +procedure 0..1 +expression 0..* ModelElement (from Core) 2-96 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Figure 2-16 Common Behavior - Instances DataVal ue Obj ect ModelElement (from Core) SubsystemInstance NodeInstance Attribute (from Core) ComponentInstance * 0..1 +resident * 0..1 Classifier (from Core) AttributeLink *1* +attribute 1 Instance 0..1 +resident 0..1 1..* * +classifier 1..* * 1 0..* 1 +slot 0..* * 1 * +value1 0..* 0..1 +ownedInstance 0..* +owner 0..1 Procedure Stimulus * * * +argument * {ordered} * 1 * +sender 11 * +receiver 1 * 1* +dispatchAction 1* March 2003 OMG-Unified Modeling Language, v1.5 2-97 2 UML Semantics Figure 2-17 Common Behavior - Links The following metaclasses are contained in the Common Behavior package. 2.9.2.1 AttributeLink An attribute link is a named slot in an instance, which holds the value of an attribute. In the metamodel, AttributeLink is a piece of the state of an Instance and holds the value of an Attribute. Associations value The Instance, which is the value of the AttributeLink. attribute The Attribute from which the AttributeLink originates. LinkObject Object ModelElement (from Core) AssociationEnd (from Core) AttributeLink Association (from Core) Stimulus LinkEndLink Instance +associationEnd 1 +qualifierValue*{ordered} 2..*1 +connection 2..*1 {ordered} +association1 * * 1 * 0..10..1 * +linkEnd * * 1 * +communicationLink 0..1* 0..1 1 2 .. *1 +connection 2 .. *{ordered} +ownedLink * +instance 11 * +owner 0..1 * 0..1 2-98 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.9.2.2 ComponentInstance A component instance is an instance of a component that resides on a node instance. A component instance may have a state. In the metamodel, a ComponentInstance is an Instance that originates from a Component. It may be associated with a set of Instance, and may reside on a NodeInstance. Associations 2.9.2.3 DataValue A data value is an instance with no identity. In the metamodel, DataValue is a child of Instance that cannot change its state (i.e., all Operations that are applicable to it are pure functions or queries). DataValues are typically used as attribute values. 2.9.2.4 Exception An exception is a signal raised by behavioral features typically in case of execution faults. In the metamodel, Exception is derived from Signal. An Exception is associated with the BehavioralFeatures that raise it. Associations 2.9.2.5 Instance The instance construct defines an entity to which a set of operations can be applied and which has a state that stores the effects of the operations. In the metamodel, Instance is connected to at least one Classifier that declares its structure and behavior. It has a set of attribute values and is connected to a set of Links, both sets matching the definitions of its Classifiers. The two sets implement the current state of the Instance. An Instance may also own other Instances or Links. Instance is an abstract metaclass. resident A collection of Instances that exist inside the ComponentInstance. context (Inherited from Signal) The set of BehavioralFeatures that raise the exception. March 2003 OMG-Unified Modeling Language, v1.5 2-99 2 UML Semantics Associations Standard Constraints Tagged Values 2.9.2.6 Link The link construct is a connection between instances. In the metamodel, Link is an instance of an Association. It has a set of LinkEnds that matches the set of AssociationEnds of the Association. A Link defines a connection between Instances. Associations slot The set of AttributeLinks that holds the attribute values of the Instance. linkEnd The set of LinkEnds of the connected Links that are attached to the Instance. classifier The set of Classifiers that declare the structure of the Instance. ownedInstance The set of Instances that are owned by the Instance. ownedLink The set of Links that are owned by the Instance. owner Specifies the Instance that owns the Instance. destroyed Association Destroyed is a constraint applied to an instance, specifying that the instance is destroyed during the execution. new Association New is a constraint applied to an instance, specifying that the instance is created during the execution. transient Association Transient is a constraint applied to an instance, specifying that the instance is created and destroyed during the execution. persistent Association Persistence denotes the permanence of the state of the instance, marking it as transitory (its state is destroyed when the instance is destroyed) or persistent (its state is not destroyed when the instance is destroyed). association The Association that is the declaration of the link. connection The tuple of LinkEnds that constitute the Link. owner Specifies the Instance that owns the Link. 2-100 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Standard Constraints 2.9.2.7 LinkEnd A link end is an end point of a link. In the metamodel, LinkEnd is the part of a Link that connects to an Instance. It corresponds to an AssociationEnd of the Link’s Association. Associations Standard Constraints 2.9.2.8 LinkObject A link object is a link with its own set of attribute values and to which a set of operations may be applied. In the metamodel, LinkObject is a connection between a set of Instances, where the connection itself may have a set of attribute values and to which a set of Operations may be applied. It is a child of both Object and Link. destroyed Association Destroyed is a constraint applied to a link, specifying that the link is destroyed during the execution. new Association New is a constraint applied to a link, specifying that the link is created during the execution. transient Association Transient is a constraint applied to a link, specifying that the link is created and destroyed during the execution. associationEnd The AssociationEnd that is the declaration of the LinkEnd.. instance The Instance connected to the LinkEnd. qualifierValue The AttributeLinks that hold the values of the Qualifier associated with the corresponding AssociationEnd. association Association Association is a constraint applied to a link-end, specifying that the corresponding instance is visible via association. global Association Global is a constraint applied to a link-end, specifying that the corresponding instance is visible because it is in a global scope relative to the link. local Association Local is a constraint applied to link-end, specifying that the corresponding instance is visible because it is in a local scope relative to the link. parameter Association Parameter is a constraint applied to a link-end, specifying that the corresponding instance is visible because it is a parameter relative to the link. self Association Self is a constraint applied to a link-end, specifying that the corresponding instance is visible because it is the dispatcher of a request. March 2003 OMG-Unified Modeling Language, v1.5 2-101 2 UML Semantics 2.9.2.9 NodeInstance A node instance is an instance of a node. A collection of component instances may reside on the node instance. In the metamodel, NodeInstance is an Instance that originates from a Node. Each ComponentInstance that resides on a NodeInstance must be an instance of a Component that resides on the corresponding Node. Associations 2.9.2.10 Object An object is an instance that originates from a class. In the metamodel, Object is a subclass of Instance and it originates from at least one Class. The set of Classes may be modified dynamically, which means that the set of features of the Object may change during its life-time. 2.9.2.11 Procedure A procedure is a coordinated set of actions that models a computation, such as an algorithm. It can also be used without actions to express a procedure in a textual language. In the metamodel, Procedure is a subclass of ModelElement. It can be linked to a Method or Expression to model how the method is carried out or the expression is evaluated. Attributes Associations resident A collection of ComponentInstances that reside on the NodeInstances. language Names the language in which the body attribute is written. body The text of the procedure written in the given language. isList Determines whether the arguments to the procedure are passed as attributes of a single object, or are passed separately. See descriptions in Actions. expression An expression the value of which is calculated by the procedure. Used to provide a detailed action model for an expression. method A method which is performed by the procedure. Used to provide a detailed action model for a method. 2-102 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.9.2.12 Reception A reception is a declaration stating that a classifier is prepared to react to the receipt of a signal. The reception designates a signal and specifies the expected behavioral response. A reception is a summary of expected behavior. The details of handling a signal are specified by a state machine. In the metamodel, Reception is a child of BehavioralFeature and declares that the Classifier containing the feature reacts to the signal designated by the reception feature. The isPolymorphic attribute specifies whether the behavior is polymorphic or not; a true value indicates that the behavior is not always the same and may be affected by state or subclassing. The specification indicates the expected response to the Signal. Attributes Associations 2.9.2.13 Signal A signal is a specification of an asynchronous stimulus communicated between instances. The receiving instance handles the signal by a state machine. Signal is a generalizable element and is defined independently of the classes handling the signal. A reception is a declaration that a class handles a signal, but the actual handling is specified by a state machine. In the metamodel, Signal is a child to Classifier, with the parameters expressed as Attributes. A Signal is always asynchronous. A Signal is associated with the BehavioralFeatures that raise it. isAbstract If true, then the reception does not have an implementation, and one must be supplied by a descendant. If false, the reception must have an implementation in the classifier or inherited from an ancestor. isLeaf If true, then the implementation of the reception may not be overridden by a descendant classifier. If false, then the implementation of the reception may be overridden by a descendant classifier (but it need not be overridden). isRoot If true, then the classifier must not inherit a declaration of the same reception. If false, then the classifier may (but need not) inherit a declaration of the same reception. (But the declaration must match in any case; a classifier may not modify an inherited declaration of a reception.) specification A description of the effects of the classifier receiving a Signal, stated by a String. signal The Signal that the Classifier is prepared to handle. March 2003 OMG-Unified Modeling Language, v1.5 2-103 2 UML Semantics Associations 2.9.2.14 Stimulus A stimulus reifies a communication between two instances. In the metamodel, Stimulus is a communication (i.e., a Signal sent to an Instance, or an invocation of an Operation). It can also be a request to create an Instance, or to destroy an Instance. It has a sender, a receiver, and may have a set of actual arguments, all being Instances. Associations 2.9.2.15 SubsystemInstance A subsystem instance is an instance of a subsystem. It is the runtime representation of a subsystem, hence it can be connected to links corresponding to associations of the subsystem. Its task is to handle incoming communication by re-directing stimuli to the appropriate receiver inside the subsystem. In the metamodel, SubsystemInstance is a subclass of Instance. 2.9.3 Well-formedness Rules The following well-formedness rules apply to the Common Behavior package. 2.9.3.1 AttributeLink context The set of BehavioralFeatures that raise the signal. reception A set of Receptions that indicates Classes prepared to handle the signal. argument The sequence of Instances being the arguments of the Stimulus. communicationLink The Link, which is used for communication. dispatchAction The procedure that caused the Stimulus to be dispatched when it was executed. receiver The Instance that receives the Stimulus. sender The Instance that sends the Stimulus. [1] The type of the Instance must match the type of the Attribute. self.value.classifier->union ( self.value.classifier.allParents)->includes ( self.attribute.type) 2-104 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.9.3.2 ComponentInstance 2.9.3.3 DataValue 2.9.3.4 Exception No extra well-formedness rules. 2.9.3.5 Instance [1] A ComponentInstance originates from exactly one Component. self.classifier->size = 1 and self.classifier.oclIsKindOf (Component) [2] A ComponentInstance may only own ComponentInstances. self.contents->forAll (c | c.oclIsKindOf(ComponentInstance)) [1] A DataValue originates from exactly one Classifier, which is a DataType. (self.classifier->size = 1) and self.classifier.oclIsKindOf(DataType) [2] A DataValue has no AttributeLinks. self.slot->isEmpty [3] A DataValue may not contain any Instances. self.contents->isEmpty [1] The AttributeLinks match the declarations in the Classifiers. self.slot->forAll ( al | self.classifier->exists ( c | c.allAttributes->includes ( al.attribute ) ) ) [2] The Links matches the declarations in the Classifiers. self.allLinks->forAll ( l | self.classifier->exists ( c | c.allAssociations->includes ( l.association ) ) ) [3] If two Operations have the same signature, they must be the same. self.classifier->forAll ( c1, c2 | c1.allOperations->forAll ( op1 | c2.allOperations->forAll ( op2 | op1.hasSameSignature (op2) implies op1 = op2 ) ) ) March 2003 OMG-Unified Modeling Language, v1.5 2-105 2 UML Semantics Additional operations [3] There are no name conflicts between the AttributeLinks and opposite LinkEnds. self.slot->forAll( al | not self.allOppositeLinkEnds->exists( le | le.name = al.name ) ) and self.allOppositeLinkEnds->forAll( le | not self.slot->exists( al | le.name = al.name ) ) [4] For each Association in which an Instance is involved, the number of opposite LinkEnds must match the multiplicity of the AssociationEnd. self.classifier.allOppositeAssociationEnds->forAll ( ae | ae.multiplicity.multiplicityRange->exists ( mr | self.selectedLinkEnds (ae)->size >= mr.lower and (mr.upper = ‘unlimited’ or (mr.upper <> ‘unlimited’ and self.selectedLinkEnds (ae)->size <= mr.upper.oclAsType (Integer) ) ) ) ) [5] The number of associated AttributeLinks must match the multiplicity of the Attribute. self.classifier.allAttributes->forAll ( a | a.multiplicity.multiplicityRange->exists ( mr | self.selectedAttributeLinks (a)->size >= mr.lower and (mr.upper = ‘unlimited’ or (mr.upper <> ‘unlimited’ and self.selectedLinkEnds (a)->size <= mr.upper.oclAsType (Integer) ) ) ) ) [1] The operation allLinks results in a set containing all Links of the Instance itself. allLinks : set(Link); allLinks = self.linkEnd.link [2] The operation allOppositeLinkEnds results in a set containing all LinkEnds of Links connected to the Instance with another LinkEnd. allOppositeLinkEnds : set(LinkEnd); allOppositeLinkEnds = self.allLinks.connection->select (le | le.instance <> self) [3] The operation selectedLinkEnds results in a set containing all opposite LinkEnds corresponding to a given AssociationEnd. selectedLinkEnds (ae : AssociationEnd) : set(LinkEnd); selectedLinkEnds (ae) = self.allOppositeLinkEnds->select (le | le.associationEnd = ae) [4] The operation selectedAttributeLinks results in a set containing all AttributeLinks corresponding to a given Attribute. 2-106 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.9.3.6 Link 2.9.3.7 LinkEnd 2.9.3.8 LinkObject selectedAttributeLinks (ae : Attribute) : set(AttributeLink); selectedAttributeLinks (a) = self.slot->select (s | s.attribute = a) [5] The operation contents results in a Set containing all ModelElements contained by the Instance. contents: Set(ModelElement); contents = self.ownedInstance->union(self.ownedLink) [1] The set of LinkEnds must match the set of AssociationEnds of the Association. Sequence {1..self.connection->size}->forAll ( i | self.connection->at (i).associationEnd = self.association.connection->at (i) ) [2] There are not two Links of the same Association that connect the same set of Instances in the same way. self.association.link->forAll ( l | Sequence {1..self.connection->size}->forAll ( i | self.connection->at (i).instance = l.connection->at (i).instance ) implies self = l ) [1] The type of the Instance must match the type of the AssociationEnd. self.instance.classifier->union ( self.instance.classifier.allParents)->includes ( self.associationEnd.type) [1] One of the Classifiers must be the same as the Association. self.classifier->includes(self.association) [2] The Association must be a kind of AssociationClass. self.association.oclIsKindOf(AssociationClass) March 2003 OMG-Unified Modeling Language, v1.5 2-107 2 UML Semantics 2.9.3.9 NodeInstance 2.9.3.10 Object 2.9.3.11 Procedure A procedure is a coordinated set of actions that models a computation, such as an algorithm. It can also be used without actions to express a procedure in a textual language. In the metamodel, Procedure is a subclass of ModelElement. It can be linked to a Method or Expression to model how the method is carried out or the expression is evaluated. [1] A NodeInstance must have only one Classifier as its origin, and it must be a Node. self.classifier->forAll ( c | c.oclIsKindOf(Node)) and self.classifier->size = 1 [2] Each ComponentInstance that resides on a NodeInstance must be an instance of a Component that resides on the corresponding Node. self.resident->forAll(n | self.classifier.resident->includes(n.classifier)) [3] A NodeInstance may not contain any Instances. self.contents->isEmpty [1] Each of the Classifiers must be a kind of Class or ClassifierInState. self.classifier->forAll ( c | c.oclIsKindOf(Class) or (c.oclIsKindOf(ClassifierInState) and c.oclAsType(ClassifierInState).type.oclIsKindOf(Class))) [2] An Object may only own Objects, DataValues, Links, UseCaseInstances, CollaborationInstances, and Stimuli. self.contents->forAll(c | c.oclIsKindOf(Object) or c.oclIsKindOf(DataValue) or c.oclIsKindOf(Link) or c.oclIsKindOf(UseCaseInstance) or c.oclIsKindOf(CollaborationInstance) or c.oclIsKindOf(Stimuli)) 2-108 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes Associations 2.9.3.12 Reception 2.9.3.13 Signal 2.9.3.14 Stimulus language Names the language in which the body attribute is written. This language name should follow the conventions for language names in UML, as described for the language attribute of Expression. body The text of the procedure written in the given language.. isList Determines whether the arguments tothe procedure are passed as attributes of a single object, or are passed separately. See description in Actions. expression An expression the value of which is calculated by the procedure. Used to provide a detailed action model for an expression. method A method which is performed by the procedure. Used to provide a detailed action model for a method. [1] A Reception cannot be a query. not self.isQuery [1] A Signal may not contain any ModelElements. self.contents->isEmpty [1] The number of arguments must match the number of arguments of the procedure. self.dispatchAction.argument->size = self.argument->size March 2003 OMG-Unified Modeling Language, v1.5 2-109 2 UML Semantics 2.9.3.15 SubsystemInstance 2.9.4 Detailed Semantics This section provides a description of the semantics of the elements in the Common Behavior package. 2.9.4.1 Object and DataValue An object is an instance that originates from a class, it is structured and behaves according to its class. All objects originating from the same class are structured in the same way, although each of them has its own set of attribute links. Each attribute link references an instance, usually a data value. The number of attribute links with the same name fulfills the multiplicity of the corresponding attribute in the class. The set may be modified according to the specification in the corresponding attribute. For example, each referenced instance must originate from (a specialization of) the type of the attribute, and attribute links may be added or removed according to the changeable property of the attribute. An object may have multiple classes (i.e., it may originate from several classes). In this case, the object will have all the features declared in all of these classes, both the structural and the behavioral ones. Moreover, the set of classes (i.e., the set of features that the object conforms to) may vary over time. New classes may be added to the object and old ones may be detached. This means that the features of the new classes are dynamically added to the object, and the features declared in a class which is removed from the object are dynamically removed from the object. No name clashes between attributes links and opposite link ends are allowed, and each operation which is applicable to the object should have a unique signature. Another kind of instance is data value, which is an instance with no identity. Moreover, a data value cannot change its state; all operations that are applicable to a data value are queries and do not cause any side effects. Since it is not possible to differentiate between two data values that appear to be the same, it becomes more of a philosophical [1] A SubsystemInstance may only own Objects, DataValues, Links, UseCaseInstances, CollaborationInstances, SubsystemInstances, and Stimuli. self.contents->forAll ( c | c.oclIsKindOf(Object) or c.oclIsKindOf(DataValue) or c.oclIsKindOf(Link) or c.oclIsKindOf(UseCaseInstance) or c.oclIsKindOf(CollaborationInstance) or c.oclIsKindOf(SubsystemInstance) or c.oclIsKindOf(Stimulus) ) [2] A SubsystemInstance originates from a Subsystem. self.classifier.oclIsKindOf(Subsystem) 2-110 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics issue whether there are several data values representing the same value or just one for each value-it is not possible to tell. In addition, a data value cannot change its data type. An instance may contain other instances as a result of a (namespace) containment between their classifiers. Namespace rules imply that an instance contained in another instance has access to all names that are accessible to its container instance. Subsystem instances are further discussed in Model Management. 2.9.4.2 Link A link is a connection between instances. Each link is an instance of an association, i.e. a link connects instances of (specializations of) the associated classifiers. In the context of an instance, an opposite end defines the set of instances connected to the instance via links of the same association and each instance is attached to its link via a link-end originating from the same association-end. However, to be able to use a particular opposite end, the corresponding link end attached to the instance must be navigable. An instance may use its opposite ends to access the associated instances. An instance can communicate with the instances of its opposite ends and also use references to them as arguments or reply values in communications. A link object is a special kind of link, which at the same time is also an object. Since an object may change its classes this is also true for a link object. However, one of the classes must always be an association class. 2.9.4.3 Signal, Exception and Stimulus Several kinds of requests exist between instances (e.g., sending a signal and invoking an operation). The former is used to trigger a reaction in the receiver in an asynchronous way and without a reply, while the latter applies an operation to an instance, which can be either done synchronously or asynchronously and may require a reply from the receiver to the sender. Other kinds of requests are used for example to create a new instance or to delete an already existing instance. When an instance communicates with another instance a stimulus is passed between the two instances. Each stimulus has a sender instance and a receiver instance, and possibly a sequence of arguments according to the specifying signal or operation. The stimulus uses a link between the sender and the receiver for communication. This link may be missing if the receiver is an argument inside the current activation, a local or global variable, or if the stimulus is sent to the sender instance itself. Moreover, a stimulus is dispatched by an action (e.g., a call action or a send action). The action specifies the request made by the stimulus, like the operation to be invoked or the signal event to be raised, as well as how the actual arguments of the stimulus are determined. A signal may be attached to a classifier, which means that instances of the classifier will be able to receive that signal. This is facilitated by declaring a reception by the classifier. An exception is a special kind of signal, typically used to signal fault situations. The sender of the exception aborts execution and execution resumes with March 2003 OMG-Unified Modeling Language, v1.5 2-111 2 UML Semantics the receiver of the exception, which may be the sender itself. Unlike other signals, the receiver of an exception is determined implicitly by the interaction sequence during execution; it is not explicitly specified as the target of the send action. The reception of a stimulus originating from a call action by an instance causes the invocation of an operation on the receiver. The receiver executes the method that is found in the full descriptor of the class that corresponds to the operation. The reception of a stimulus originating from a signal by an instance may cause a transition and subsequent effects as specified by the state machine for the classifier of the recipient. This form of behavior is described in the State Machines package. Note that the invoked behavior is described by methods and state machine transitions. Operations and receptions merely declare that a classifier accepts a given operation invocation or signal but they do not specify the implementation. 2.10 Collaborations 2.10.1 Overview The Collaborations package is a subpackage of the Behavioral Elements package. The package uses constructs defined in the Foundation package and the Common Behavior packages. The Collaborations package provides the means to define Collaborations and CollaborationInstanceSets. The main constructs used in a Collaboration include ClassifierRole, AssociationRole, Interaction, and Message while Instance, Stimulus, and Link are used in a CollaborationInstanceSet. The description of cooperating Instances involves two aspects: 1) the structural description of the participants, and 2) the description of their communication patterns. The structure of the participants that play the roles in the performance of a specific task and their relationships is called a Collaboration. The communication pattern performed by Instances playing the roles to accomplish the task is called an Interaction. The behavior is implemented by ensembles of Instances that exchange Stimuli within an overall Interaction. To understand the mechanisms used in a design, it is important to see only those Instances and their Interactions that are involved in accomplishing a purpose or a related set of purposes, projected from the larger system of which they are a part. A Collaboration includes a set of ClassifierRoles and AssociationRoles that define the participants needed for a given set of purposes. Instances conforming to the ClassifierRoles play the roles defined by the ClassifierRoles, while Links between the Instances conform to AssociationRoles of the Collaboration. ClassifierRoles and AssociationRoles define a usage of Instances and Links, and the Classifiers and Associations declare all required properties of these Instances and Links. An Interaction is defined in the context of a Collaboration. It specifies the communication patterns between the roles in the Collaboration. More precisely, it contains a set of partially ordered Messages, each specifying one communication; for example, what Signal to be sent or what Operation to be invoked, as well as the roles to be played by the sender and the receiver, respectively. 2-112 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics A CollaborationInstanceSet references a collection of Instances that jointly perform the task specified by the CollaborationInstanceSet’s Collaboration. These Instances play the roles defined by the ClassifierRoles of the Collaboration; that is, the Instances have all the properties stated by (the Instances conform to) the ClassifierRoles. The Stimuli sent between the Instances when performing the task are participating in the InteractionInstanceSet of the CollaborationInstanceSet. These Stimuli conform to the Messages in one of the Interactions of the Collaboration. Since an Instance can participate in several CollaborationInstanceSets at the same time, all its communications are not necessarily referenced by only one InteractionInstanceSet. They can be interleaved. A parameterized Collaboration represents a design construct that can be used repeatedly in different designs. The participants in the Collaboration, including the Classifiers and Relationships, can be parameters of the generic Collaboration. The parameters are bound to particular ModelElements in each instantiation of generic Collaboration. Such a parameterized Collaboration can capture the structure of a design pattern (note that a design pattern involves more than structural aspects). Whereas most Collaborations can be anonymous because they are attached to a named ModelElement, Collaboration patterns are free standing design constructs that must have names. A Collaboration may be expressed at different levels of granularity. A coarse-grained Collaboration may be refined to produce another Collaboration that has a finer granularity. Collaborations can be used for expressing several different things, like how use cases are realized, actor structures of ROOM, OOram role models, and collaborations as defined in Catalysis. They are also used for setting up the context of Interactions and for defining the mapping between the specification part and the realization part of a Subsystem. A Collaboration may be attached to an Operation or a Classifier, like a UseCase, to describe the realization of the Operation or of the Classifier; that is, what roles Instances play to perform the behavior specified by the Operation or the UseCase. A Collaboration that describes a Classifier, like a UseCase, references Classifiers and Associations in general, while a Collaboration describing an Operation includes the arguments and the local variables of the Operation, as well as ordinary Associations attached to the Classifier owning the Operation. The Interactions defined within the Collaboration specify the communication pattern between the Instances when they perform the behavior specified in the Operation or the UseCase. A Collaboration may also be attached to a Classifier to define the static structure of it; that is, the roles played by the Attributes, the Parameters, etc. A ClassifierRole or an AssociationRole has one or a collection of Classifiers or Associations as its base. The same Classifier or Association can appear as the base of roles in several Collaborations and several times in the same Collaboration, each time in a different role. In each appearance it is specified which of the properties of the Classifier or the Association are needed in the particular usage. These properties constitute a subset of all the properties of that Classifier or Association. March 2003 OMG-Unified Modeling Language, v1.5 2-113 2 UML Semantics A Collaboration is a GeneralizableElement. This implies that a Collaboration may specify a task that is a specialization of another Collaboration’s task. The following sections describe the abstract syntax, well-formedness rules, and semantics of the Collaborations package. 2.10.2 Abstract Syntax The abstract syntax for the Collaborations package is expressed in graphic notation in Figure 2-18 through Figure 2-20. Figure 2-18 Collaborations - Roles AssociationEnd (from Core) At tribut e (from Core) Association (from Core) 2..* 1 +c onnection2..* 1 {ordered} Feature (from Core) Collaboration AssociationEndRole collaborationMultiplicity : Multiplicity 0..1 * +base 0..1 * * * * +availableQualif ier* Classifier (from Core) ModelElement (from Core) * * * +constrainingElement * Action (from Common Behavior) AssociationRole multiplicity : Multiplicity 0..1 * +base 0..1 * 1 * 1 +/ownedElement* 1 2..* 1 +/ c onn ect i on 2..* Cl ass i f ier Rol e multiplicity : Multiplicity ** * +availableFeature * 1 1..* 1 +/ownedElement 1..* * 1* +/type 1 *1..* * +base 1..* * * * +availableCont ents * Message 1 * +action 1 * *0..1 * +c ommunicationConnection 0..1 1 * +sender 1 * * 1 * +r ecei ver1 * * +predecessor * +successor * * 0..1 * +activator 0..1 2-114 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Figure 2-19 Collaborations - Interactions {xor} Generali zableElement (from Core) Namespace (from Core) Message Operation (from Core) Interaction 1 1..*1 +message 1..* Classifier (from Core) Coll aborati on * 0..1* +representedOperation 0..1 1 * +context1 +interaction * * 0..1* +representedClassifier 0..1* * +usedCollaboration * * ModelElement (from Core) March 2003 OMG-Unified Modeling Language, v1.5 2-115 2 UML Semantics Figure 2-20 Collaborations - Instances 2.10.2.1 AssociationEndRole An association-end role specifies an endpoint of an association as used in a collaboration. In the metamodel, an AssociationEndRole is part of an AssociationRole and specifies the connection of an AssociationRole to a ClassifierRole. It is related to the AssociationEnd, declaring the corresponding part in an Association. Attributes Associations collaborationMultiplicity The number of LinkEnds playing this role in a Collaboration. availableQualifier The subset of Qualifiers that are used in the Collaboration. base The AssociationEnd of which the AssociationEndRole is a projection. Mes sage Stimulus (from Common Behavior) * * +playedRole* +conformingStimulus* Interaction 1..* 1 +message 1..* 1 ClassifierRole multiplicity : Multiplicity AssociationRole multiplicity : Multiplicity InteractionInstanceSet *1..* * +participat ingStimulus 1..* 0..1 * +interaction0..1 * Collaboration * 1 +interaction * +context 1 1..*1 +/ownedElement 1..*1 * 1 +/ownedElement * 1 Instance (from Common Behavior) * * +playedRole * +conformingInstance * ModelElement (from Core) Link (from Common Behavior) * * +playedRole * +conformingLink* CollaborationInstanceSet 1* +context 1 +interactionInstance * 0..1 * +collaboration0..1 * * 1..** +participatingInstance 1..* * * +const rainingElement * * * * +par ti c i pat i ngLi nk * * 2-116 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.10.2.2 AssociationRole An association role is a specific usage of an association needed in a collaboration. In the metamodel, an AssociationRole specifies a restricted view of an Association used in a Collaboration. An AssociationRole is a composition of a set of AssociationEndRoles corresponding to the AssociationEnds of its base Association. Attributes Associations 2.10.2.3 ClassifierRole A classifier role is a specific role played by a participant in a collaboration. It specifies a restricted view of a classifier, defined by what is required in the collaboration. In the metamodel, a ClassifierRole specifies one participant of a Collaboration; that is, a role Instances conform to. A ClassifierRole defines a set of Features, which is a subset of those available in the base Classifiers, as well as a subset of ModelElements contained in the base Classifiers, that are used in the role. The ClassifierRole may be connected to a set of AssociationRoles via AssociationEndRoles. As ClassifierRole is a kind of Classifier, a Generalization relationship may be defined between two ClassifierRoles. The child role is a specialization of the parent; that is, the Features and the contents of the child includes the Features and contents of the parent. Attributes Associations multiplicity The number of Links playing this role in a Collaboration. base The Association of which the AssociationRole is a view. conformingLink The collection of Links that conforms to the AssociationRole. multiplicity The number of Instances playing this role in a Collaboration. availableContents The subset of ModelElements contained in the base Classifier, which is used in the Collaboration. availableFeature The subset of Features of the base Classifier, which is used in the Collaboration. base The Classifiers, which the ClassifierRole is a view of. conformingInstance The collection of Instances that conforms to the ClassifierRole. March 2003 OMG-Unified Modeling Language, v1.5 2-117 2 UML Semantics 2.10.2.4 Collaboration A collaboration describes how an operation or a classifier, like a use case, is realized by a set of classifiers and associations used in a specific way. The collaboration defines a set of roles to be played by instances and links, as well as a set of interactions that define the communication between the instances when they play the roles. In the metamodel, a Collaboration contains a set of ClassifierRoles and AssociationRoles, which represent the Classifiers and Associations that take part in the realization of the associated Classifier or Operation. The Collaboration may also contain a set of Interactions that are used for describing the behavior performed by Instances conforming to the participating ClassifierRoles. A Collaboration specifies a view (restriction, slice, projection) of a model of Classifiers. The projection describes the required relationships between Instances that conform to the participating ClassifierRoles, as well as the required subsets of the Features and contained ModelElements of these Classifiers. Several Collaborations may describe different projections of the same set of Classifiers. Hence, a Classifier can be a base for several ClassifierRoles. A Collaboration may also reference a set of ModelElements, usually Classifiers and Generalizations, needed for expressing structural requirements, such as Generalizations required between the Classifiers themselves to fulfill the intent of the Collaboration. A Collaboration is a GeneralizableElement, which implies that one Collaboration may specify a task that is a specialization of the task of another Collaboration. Associations 2.10.2.5 CollaborationInstanceSet A collaboration instance set references a set of instances that jointly collaborate in performing the particular task specified by the collaboration of the collaboration instance. The instances in the collaboration instance set play the roles defined in the collaboration. constrainingElement The ModelElements that add extra constraints, like Generalization and Constraint, on the ModelElements participating in the Collaboration. interaction The set of Interactions that are defined within the Collaboration. ownedElement (Inherited from Namespace) The set of roles defined by the Collaboration. These are ClassifierRoles and AssociationRoles. representedClassifier The Classifier the Collaboration is a realization of. (Used if the Collaboration represents a Classifier.) representedOperation The Operation the Collaboration is a realization of. (Used if the Collaboration represents an Operation.) usedCollaboration Collaborations that are used when defining the source Collaboration. 2-118 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics In the metamodel, a CollaborationInstanceSet references a set of Instances and Links that play the roles defined by the ClassifierRoles and AssociationRoles of the CollaborationInstanceSet’s Collaboration. A CollaborationInstanceSet contains an InteractionInstanceSet, which references the set of Stimuli that are interchanged between the Instances of the CollaborationInstanceSet and corresponds to the Messages of an Interaction in the CollaborationInstanceSet’s Collaboration. Associations 2.10.2.6 Interaction An interaction specifies the communication between instances performing a specific task. Each interaction is defined in the context of a collaboration. In the metamodel, an Interaction contains a set of Messages specifying the communication between a set of Instances conforming to the ClassifierRoles of the owning Collaboration. Associations 2.10.2.7 InteractionInstanceSet An interaction instance set is the set of stimuli that participate in a collaboration instance set. In the metamodel, an InteractionInstanceSet references a collection of Stimuli that conform to the Messages of the InteractionInstanceSet’s Interaction. constrainingElement The ModelElements that add extra constraints, like Generalization and Constraint, on the ModelElements participating in the Collaboration. collaboration The Collaboration, which declares the roles that the Instances that participate in the CollaborationInstanceSet play. interactionInstanceSet The InteractionInstanceSet that references the Stimuli passed between the Instances when performing the task of the CollaborationInstanceSet’s Collaboration. participatingInstance The set of Instances that participate in the CollaborationInstanceSet. participatingLink The set of Links that participate in the CollaborationInstanceSet. context The Collaboration that defines the context of the Interaction. message The Messages that specify the communication in the Interaction. March 2003 OMG-Unified Modeling Language, v1.5 2-119 2 UML Semantics Associations 2.10.2.8 Message A message defines a particular communication between instances that is specified in an interaction. In the metamodel, a Message defines one specific kind of communication in an Interaction. A communication can be raising a Signal, invoking an Operation, creating or destroying an Instance. The Message specifies not only the kind of communication, but also the roles of the sender and the receiver, the dispatching Action, and the role played by the communication Link. Furthermore, the Message defines the relative sequencing of Messages within the Interaction. Associations 2.10.3 Well-formedness Rules The following well-formedness rules apply to the Collaborations package. context The CollaborationInstanceSet that defines the context of the InteractionInstanceSet. participating- Stimulus The Stimuli that participate in the performance of the CollaborationInstanceSet. interaction The Interaction that defines the interaction pattern that the stimuli conforms to. action The Action that causes a Stimulus to be sent according to the Message. activator The Message that invokes the behavior causing the dispatching of the current Message. communicationConnection The AssociationRole played by the Links used in the communications specified by the Message. conformingStimulus The collection of Stimuli that conforms to the Message. interaction The Interaction of which the Message is a part. receiver The role of the Instance that receives the communication and reacts to it. predecessor The set of Messages whose completion enables the execution of the current Message. All of them must be completed before execution begins. sender The role of the Instance that invokes the communication and possibly receives a response. 2-120 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.10.3.1 AssociationEndRole 2.10.3.2 AssociationRole 2.10.3.3 ClassifierRole [1] The type of the ClassifierRole must conform to the type of the base AssociationEnd. self.type.base = self.base.type or self.type.base.allParents->includes (self.base.type) [2] The type must be a kind of ClassifierRole. self.type.oclIsKindOf (ClassifierRole) [3] The qualifiers used in the AssociationEndRole must be a subset of those in the base AssociationEnd. self.base.qualifier->includesAll (self.availableQualifier) [4] In a Collaboration an Association may only be used for traversal if it is allowed by the base Association. self.isNavigable implies self.base.isNavigable [5] An AssociationEndRole is not a role of another AssociationEndRole. not self.base.oclIsKindOf (AssociationEndRole) [1] The AssociationEndRoles must conform to the AssociationEnds of the base Association. Sequence{ 1..(self.connection->size) }->forAll (index | self.connection->at(index).base = self.base.connection->at(index)) [2] The endpoints must be a kind of AssociationEndRoles. self.connection->forAll( r | r.oclIsKindOf (AssociationEndRole) ) [3] An AssociationEnd is not a role of another AssociationEnd. not self.base.oclIsKindOf (AssociationEnd) [1] The AssociationRoles connected to the ClassifierRole must match a subset of the Associations connected to the base Classifiers. self.allAssociations->forAll( ar | self.base.allAssociations->exists ( a | ar.base = a ) ) [2] The Features and contents of the ClassifierRole must be subsets of those of the base Classifiers. self.base.allFeatures->includesAll (self.allAvailableFeatures) and self.base.allContents->includesAll (self.allAvailableContents) [3] A ClassifierRole does not have any Features of its own. March 2003 OMG-Unified Modeling Language, v1.5 2-121 2 UML Semantics Additional operations 2.10.3.4 Collaboration self.allFeatures->isEmpty [4] A ClassifierRole is not a role of another ClassifierRole. not self.base.oclIsKindOf (ClassifierRole) [1] The operation allAvailableFeatures results in the set of all Features contained in the ClassifierRole together with those contained in the parents. allAvailableFeatures : Set(Feature); allAvailableFeatures = self.availableFeature->union (self.parent.allAvailableFeatures) [2] The operation allAvailableContents results in the set of all ModelElements contained in the ClassifierRole together with those contained in the parents. allAvailableContents : Set(ModelElement); allAvailableContents = self.availableContents->union (self.parent.allAvailableContents) [1] All Classifiers and Associations of the ClassifierRoles and AssociationRoles in the Collaboration must be included in the namespace owning the Collaboration. self.allContents->forAll ( e | (e.oclIsKindOf (ClassifierRole) implies self.namespace.allContents->includes ( e.oclAsType(ClassifierRole).base) ) and (e.oclIsKindOf (AssociationRole) implies self.namespace.allContents->includes ( e.oclAsType(AssociationRole).base) )) [2] All the constraining ModelElements must be included in the namespace owning the Collaboration. self.constrainingElement->forAll ( ce | self.namespace.allContents->includes (ce) ) [3] If a ClassifierRole or an AssociationRole does not have a name, then it should be the only one with a particular base. 2-122 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Additional operations self.allContents->forAll ( p | (p.oclIsKindOf (ClassifierRole) implies p.name = '' implies self.allContents->forAll ( q | q.oclIsKindOf(ClassifierRole) implies (p.oclAsType(ClassifierRole).base = q.oclAsType(ClassifierRole).base implies p = q) ) ) and (p.oclIsKindOf (AssociationRole) implies p.name = '' implies self.allContents->forAll ( q | q.oclIsKindOf(AssociationRole) implies (p.oclAsType(AssociationRole).base = q.oclAsType(AssociationRole).base implies p = q) ) ) ) [4] A Collaboration may only contain ClassifierRoles and AssociationRoles, the Generalizations and the Constraints between them, and Actions used in the Collaboration’s Interactions. self.allContents->forAll ( p | p.oclIsKindOf (ClassifierRole) or p.oclIsKindOf (AssociationRole) or p.oclIsKindOf (Generalization) or p.oclIsKindOf (Action) or p.oclIsKindOf (Constraint) ) [5] An Action contained in a Collaboration must be connected to a Message; that is, be the dispatching Action of the Message, in an Interaction of the Collaboration. self.allContents->forAll ( p | p.oclIsKindOf (Action) implies self.interaction->exists ( i : Interaction | i.messages->exists ( m : Message | m.action = p ) ) ) [6] A role with the same name as one of the roles in a parent of the Collaboration must be a child (a specialization) of that role. self.contents->forAll ( c | self.parent.allContents->forall ( p | c.name = p.name implies c.allParents->include (p) )) [1] The operation allContents results in the set of all ModelElements contained in the Collaboration together with those contained in the parents except those that have been specialized. allContents : Set(ModelElement); allContents = self.contents->union ( self.parent.allContents->reject ( e | self.contents.name->include (e.name) )) March 2003 OMG-Unified Modeling Language, v1.5 2-123 2 UML Semantics 2.10.3.5 CollaborationInstanceSet 2.10.3.6 Interaction 2.10.3.7 InteractionInstanceSet No extra well-formedness rules. 2.10.3.8 Message [1] The Interaction of the CollaborationInstanceSet’s InteractionInstanceSet must be defined within the CollaborationInstanceSet’s Collaboration. self.collaboration.interaction->includes ( self.interactionInstanceSet.interaction) [1] All Signals being sent must be included in the namespace owning the Collaboration in which the Interaction is defined. self.message->forAll ( m | m.action.oclIsKindOf(SendAction) implies self.context.namespace.allContents->includes ( m.action->oclAsType (SendAction).signal) ) [1] The sender and the receiver must participate in the Collaboration, which defines the context of the Interaction. self.interaction.context.ownedElement->includes (self.sender) and self.interaction.context.ownedElement->includes (self.receiver) [2] The predecessors and the activator must be contained in the same Interaction. self.predecessor->forAll ( p | p.interaction = self.interaction ) and self.activator->forAll ( a | a.interaction = self.interaction ) [3] The predecessors must have the same activator as the Message. self.allPredecessors->forAll ( p | p.activator = self.activator ) [4] A Message cannot be the predecessor of itself. not self.allPredecessors->includes (self) [5] The communicationLink of the Message must be an AssociationRole in the context of the Message’s Interaction. 2-124 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Additional operations 2.10.4 Detailed Semantics This section provides a description of the semantics of the elements in the Collaborations package. It is divided into two parts: Collaboration and Interaction. The description of behavior involves two aspects: 1) the structural description of the participants, and 2) the description of their communication patterns. The structure of Instances playing roles in a behavior and their relationships is described by a collaboration. The communication pattern performed by Instances playing the roles to accomplish a specific purpose is specified by an interaction. 2.10.4.1 Collaboration Behavior is implemented by ensembles of instances that exchange stimuli to accomplish a task. To understand the mechanisms used in a design, it is important to see only those instances and their interactions that are involved in accomplishing the task or a related set of tasks, projected from the larger system of which they are parts of, and might be used for other purposes as well. Such a static construct is called a collaboration. A collaboration defines an ensemble of participants that are needed for a given set of purposes. The participants define roles that instances and links play when interacting with each other. The roles to be played by the instances are modeled as classifier roles, and by the links as association roles. Classifier roles and association roles define a usage of instances and links, while the classifiers and associations specify all required properties of these instances and links. This means that the structure of an ensemble of interlinked instances conforms to the roles in a collaboration as they collaborate to achieve a given task. Reasoning about the behavior of an ensemble of instances can therefore be done in the context of the collaboration as well as in the context of the instances. self.interaction.context.ownedElement->includes ( self.communicationConnection) [6] The sender and the receiver roles must be connected by the AssociationRole, which acts as the communication connection. self.communicationConnection->size > 0 implies self.communicationConnection.connection->exists (ar | ar.type = self.sender) and self.communicationConnection.connection->exists (ar | ar.type = self.receiver) [1] The operation allPredecessors results in the set of all Messages that precede the current one. allPredecessors : Set(Message); allPredecessors = self.predecessor->union (self.predecessor.allPredecessors) March 2003 OMG-Unified Modeling Language, v1.5 2-125 2 UML Semantics A collaboration can be used for specification of how an operation or a classifier, like a use case, is realized by an ensemble of classifiers and associations. Together, the classifiers and their associations participating in the collaboration meet the requirements of the realized operation or classifier. The collaboration defines a context in which the behavior of the realized element can be specified. A collaboration specifies what properties instances must have to be able to take part in the collaboration; that is, a role in the collaboration specifies the required set of features a conforming instance must have. Furthermore, the collaboration also states what associations must exist between the participants, as well as what classifiers a participant, like a subsystem, must contain. Neither all features nor all contents of the participating classifiers and not all associations between these classifiers are always required in a particular collaboration. Because of this, a collaboration is defined in terms of classifier roles. A classifier role is a description of the features required in a particular collaboration; that is, a classifier role can be seen as a projection of a classifier, which is called the base of the classifier role. (In fact, since an instance can originate from multiple classifiers at the same time (multiple classification), a classifier role can have several base classifiers.) However, instances of different classifiers can play the role defined by the classifier role, as long as they have all the required properties. Several classifier roles may have the same base classifier, even in the same collaboration, but their features and contained elements may be different subsets of the features and contained elements of the classifier. These classifier roles specify different roles played by (possibly different) instances of the same classifier. A collaboration may be attached to an operation or a classifier, like a use case, to describe the context in which their behavior occurs; that is, what roles instances play to perform the behavior specified by the operation or the use case. A collaboration used in this way describes the realization of the operation or the classifier. A collaboration that describes for example a use case, references classifiers and associations in general, while a collaboration describing an operation includes only the parameters and the local variables of the operation, as well as ordinary associations attached to the classifier owning the operation. The interactions defined within the collaboration (see below) specify the communication pattern between the instances when they perform the behavior specified in the operation or the use case. A collaboration may also be attached to a class to define its static structure; that is, how its attributes, parameters etc. cooperate with each other. In a collaboration, the association roles define what associations are needed between the classifiers in this context. Each association role represents the usage of an association in the collaboration, and it is defined between the classifier roles that represent the associated classifiers. The represented association is called the base association of the association role. As the association roles specify a particular usage of an association in a specific collaboration, all constraints expressed by the association ends are not necessarily required to be fulfilled in the specified usage. The multiplicity of the association end may be reduced in the collaboration; that is, the upper and the lower bounds of the association end roles may be inside the bounds of the corresponding end of the base association, as it might be that only a subset of the associated instances participate in the collaboration instance set. Similarly, an association may be traversed in some, but perhaps not all, of the allowed directions in the specific collaboration; that is, the value of the isNavigable property of an 2-126 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics association end role may be false even if the value of that property of the base association end is true. (However, the opposite is not true; that is, an association may not be used for traversal in a direction that is not allowed according to the isNavigable properties of the association ends.) The changeability and ordering of an association end may be strengthened in an association end role; that is, in a particular usage the end is used in a more restricted way than is defined by the association. Furthermore, if an association has a collection of qualifiers (see the Core), some of them may be used in a specific collaboration. An association end role may therefore include a subset of the qualifiers defined by the corresponding association end of the base association. A collaboration instance set references a collection of instances that play the roles defined in the collaboration instance set’s collaboration. An instance participating in a collaboration instance set plays a specific role; that is, conforms to a classifier role, in the collaboration. The number of instances that should play one specific role in a collaboration is specified by the classifier role’s multiplicity. Different instances may play the same role but in different collaboration instance sets. Since all these instances play the same role, they must all conform to the classifier role specifying the role. Thus, they are normally instances of one of the base classifier of the classifier role, or one of their descendants. The only requirement on conforming instances is that they must offer operations according to the classifier role, as well as support attribute links corresponding to the attributes specified by the classifier role, and links corresponding to the association roles connected to the classifier role. They may, therefore, be instances of any classifier meeting this requirement. The instances may, of course, have more attribute links than required by the classifier role, which for example would be the case if they originate from a classifier being a child of a base classifier. Moreover, a conforming instance may also support more attribute links than required if it originates from multiple classifiers (multiple classification). Finally, one instance may play different roles in different collaboration instance sets of the same collaboration. In fact, the instance may play multiple roles in the same collaboration instance set. Collaborations (but not collaboration instance sets) may have generalization relationships to other collaborations. This means that one collaboration can specify a specialization of another collaboration’s task. This implies that all the roles of the parent collaboration are also available in the child collaboration; the child collaboration may, of course, also contain new roles. The former roles may possibly be specialized with new features; that is, the role defined in the parent is replaced in the child by a role with the same name as the parent role. The role in the child must reference the same collection of features and the same collection of contained elements as the role in the parent, and may also reference some additional features and additional contained elements. In this way it is possible to specialize a collaboration both by adding new roles and by replacing existing roles with specializations of them. The specialized role, that is, a role with a generalization relationship to the replaced role, may both reference new features and replace (override) features of its parent. Note that the base classifiers of the specialized roles are not necessarily specializations of the base classifiers of the parent’s roles; it is enough that they contain all the required features. How the instances referenced by a collaboration instance set should interact to jointly perform the behavior of the classifier realized by the collaboration is specified with a set of interactions (see below). The collaboration thus specifies the context in which March 2003 OMG-Unified Modeling Language, v1.5 2-127 2 UML Semantics these interactions are performed. If the collaboration represents an operation, the context includes things like parameters, attributes, and classifiers contained in the classifier owning the operation. The interactions then specify how the arguments, the attribute values, the instances etc. will cooperate to perform the behavior specified by the operation. If the collaboration is a specialization of another collaboration, all communications specified by the parent collaboration are also included in the child, as the child collaboration includes all the roles of the parent. However, new messages may be inserted into these sequences of communication, since the child may include specializations of the parent’s roles as well as new roles. The child may of course also include completely new interactions that do not exist in the parent. Two or more collaborations may be composed to form a new collaboration. For example, when refining a superordinate use case into a set of subordinate use cases, the collaborations specifying each of the subordinate use cases may be composed into one collaboration, which will be a (simple) refinement of the superordinate collaboration. The composition is done by observing that at least one instance must participate in both sets of collaborating instances. This instance has to conform to one classifier role in each collaboration. In the composite collaboration these two classifier roles are merged into a new one, which will contain all features included in either of the two original classifier roles. The new classifier role will, of course, be able to fulfill the requirements of both of the previous collaborations, so the instance participating in both of the two sets of collaborating instances will conform to the new classifier role. A parameterized collaboration represents a design construct that can be used repeatedly in different designs. The participants in the collaboration, including the classifiers and relationships, can be parameters of the generic collaboration. The parameters are bound to particular model elements in each instantiation of generic collaboration. Such a parameterized collaboration can capture the structure of a design pattern (note that a design pattern involves more than structural aspects). Whereas most collaborations can be anonymous because they are attached to a named model element, collaboration patterns are free standing design constructs that must have names. A collaboration may be a specification of a template. There will not be any instances of such a collaboration template, but it can be used for generating ordinary collaborations, which may be instantiated. Collaboration templates may have parameters that act like placeholders in the template. Usually, these parameters would be used as base classifiers and associations, but other kinds of model elements can also be defined as parameters in the collaboration, like operation or signal. In a collaboration generated from the template these parameters are refined by other model elements that make the collaboration instantiable. Moreover, a collaboration may also contain a set of constraining model elements, like constraints and generalizations perhaps together with some extra classifiers. These constraining model elements do not participate in the collaboration themselves, but are used for expressing the extra constraints on the participating elements in the collaboration that cannot be covered by the participating roles themselves. For example, in a collaboration template it might be required that the base classifiers of two roles must have a common ancestor, or one role must be a subclass of another one. 2-128 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics These kinds of requirements cannot be expressed with association roles, as the association roles express the required links between participating instances. An extra set of model elements may therefore be included in the collaboration. 2.10.4.2 Interaction An interaction is defined in the context of a collaboration. It specifies the communication patterns between its roles. More precisely, it contains a set of partially ordered messages, each specifying one communication, such as what signal to be sent or what operation to be invoked, as well as the roles to be played by the sender and the receiver, respectively. The purpose of an interaction is to specify the communication between an ensemble of interacting instances performing a specific task. An interaction is defined within a collaboration; that is, the collaboration defines the context in which the interaction takes place. The instances performing the communication specified by the interaction are included in a collaboration instance set; that is, they conform to the classifier roles of the collaboration instance set’s collaboration. An interaction specifies the sending of a set of stimuli. These are partially ordered based on which execution thread they belong to. Within each thread the stimuli are sent in a sequential order while stimuli of different threads may be sent in parallel or in an arbitrary order. An interaction instance set references the collection of stimuli that constitute the actual communication between the collection of instances. These instances are the collection of instances that participate in the collaboration instance set owning the interaction instance set. Hence, the interaction instance set includes those stimuli that the instances communicate when performing the task of the collaboration instance set. The stimuli of an interaction instance set match the messages of the interaction instance set’s interaction. A message is a specification of a communication. It specifies the roles of the sender and the receiver instances, as well as which association role specifies the communication link. The message is connected to an action, which specifies the statement that, when executed, causes the communication specified by the message to take place. If the action is a call action or a send action, the signal to be sent or the operation to be invoked in the communication is stated by the action. The action also contains the argument expressions that, when executed, will determine the actual arguments being transmitted in the communication. Moreover, any conditions or iterations of the communication are also specified by the action. Apart from send action and call action, the action connected to a message can also be of other kinds, like create action and destroy action. In these cases, the communication will not raise a signal or invoke an operation, but cause a new instance to be created or an already existing instance to be destroyed. In the case of a create action, the receiver specified by the message is the role to be played by the instance, which is created when the action is performed. March 2003 OMG-Unified Modeling Language, v1.5 2-129 2 UML Semantics The stimuli being sent when an action is executed conforms to a message, implying that the sender and receiver instances of the stimuli are in conformance with the sender and the receiver roles specified by the message. Furthermore, the action dispatching the stimulus is the same as the action attached to the message. If the action connected to the message is a create action or destroy action, the receiver role of the message specifies the role to be played by the instance, or was played by the instance, respectively. The interaction specifies the activator and predecessors of each message. The activator is the message that invoked the procedure that in turn invokes the current message. Every message except the initial messages of an interaction thus has an activator. The predecessors are the set of messages that must be completed before the current message may be executed. The first message in a procedure of course has no predecessors. If a message has more than one predecessor, it represents the joining of two threads of control. If a message has more than one successor (the inverse of predecessor), it indicates a fork of control into multiple threads. Thus, the predecessor’s relationship imposes a partial ordering on the messages within a procedure, whereas the activator relationship imposes a tree on the activation of operations. Messages may be executed concurrently subject to the sequential constraints imposed by the predecessors and activator relationship. 2.10.5 Notes In UML, the term Pattern is a synonym for a collaboration template that describes the structure of a design pattern. This definition is not as powerful as the term is used in other contexts. In general, design patterns involve many nonstructural aspects, such as heuristics for their use and lists of advantages and disadvantages. Such aspects are not modeled by UML and may be represented as text or tables. 2.11 Use Cases 2.11.1 Overview The Use Cases package is a subpackage of the Behavioral Elements package. It specifies the concepts used for definition of the functionality of an entity like a system. The package uses constructs defined in the Foundation package of UML as well as in the Common Behavior package. The elements in the Use Cases package are primarily used to define the behavior of an entity, like a system or a subsystem, without specifying its internal structure. The key elements in this package are UseCase and Actor. Instances of use cases and instances of actors interact when the services of the entity are used. How a use case is realized in terms of cooperating objects, defined by classes inside the entity, can be specified with a Collaboration. A use case of an entity may be refined to a set of use cases of the elements contained in the entity. How these subordinate use cases interact can also be expressed in a Collaboration. The specification of the functionality of the system itself 2-130 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics is usually expressed in a separate use-case model; that is, a Model stereotyped «useCaseModel» (see Section 4.3, “Stereotypes and Notation,” on page 4-2). The use cases and actors in the use-case model are equivalent to those of the top-level package. The following sections describe the abstract syntax, well-formedness rules, and semantics of the Use Cases package. 2.11.2 Abstract Syntax The abstract syntax for the Use Cases package is expressed in graphic notation in Figure 2-21 on page 2-130. Figure 2-21 Use Cases The following metaclasses are contained in the Use Cases package. UseCaseInstance Actor Classifier (from Core) Instance (from Common Behavior) 1..* * +classifier 1..* * ModelElement (from Core) Include UseCase * 1 +include* +addition 1 * 1 * +base1 E xtensionP oint location : LocationReference*1 +extensionPoint *1 Extend condition : BooleanExpression 1 * +base1 * 1 * +extension 1 +extend * 1..* * +extensionPoint 1..* {ordered} * Relationship (from Core) March 2003 OMG-Unified Modeling Language, v1.5 2-131 2 UML Semantics 2.11.2.1 Actor An actor defines a coherent set of roles that users of an entity can play when interacting with the entity. An actor may be considered to play a separate role with regard to each use case with which it communicates. In the metamodel, Actor is a subclass of Classifier. An Actor has a Name and may communicate with a set of UseCases, and, at realization level, with Classifiers taking part in the realization of these UseCases. An Actor may also have a set of Interfaces, each describing how other elements may communicate with the Actor. An Actor may have generalization relationships to other Actors. This means that the child Actor will be able to play the same roles as the parent Actor, that is, communicate with the same set of UseCases, as the parent Actor. 2.11.2.2 Extend An extend relationship defines that instances of a use case may be augmented with some additional behavior defined in an extending use case. In the metamodel, an Extend relationship is a directed relationship implying that a UseCaseInstance of the base UseCase may be augmented with the structure and behavior defined in the extending UseCase. The relationship consists of a condition, which must be fulfilled if the extension is to take place, and a sequence of references to extension points in the base UseCase where the additional behavior fragments are to be inserted. Attributes Associations 2.11.2.3 ExtensionPoint An extension point references one or a collection of locations in a use case where the use case may be extended. In the metamodel, an ExtensionPoint has a name and one or a collection of descriptions of locations in the behavior of the owning use case, where a piece of behavior may be inserted into the owning use case. condition An expression specifying the condition that must be fulfilled if the extension is to take place. base The UseCase to be extended. extension The UseCase specifying the extending behavior. extensionPoint A sequence of extension-points in the base UseCase specifying where the additions are to be inserted. 2-132 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes 2.11.2.4 Include An include relationship defines that a use case contains the behavior defined in another use case. In the metamodel, an Include relationship is a directed relationship between two UseCases implying that the behavior in the addition UseCase is inserted into the behavior of the base UseCase. The base UseCase may only depend on the result of performing the behavior defined in the addition UseCase, but not on the structure; that is, on the existence of specific attributes and operations, of the addition UseCase. Associations 2.11.2.5 UseCase The use case construct is used to define the behavior of a system or other semantic entity without revealing the entity’s internal structure. Each use case specifies a sequence of actions, including variants, that the entity can perform, interacting with actors of the entity. In the metamodel, UseCase is a subclass of Classifier, specifying the sequences of actions performed by an instance of the UseCase. The actions include changes of the state and communications with the environment of the UseCase. The sequences can be described using many different techniques, like Operation and Methods, ActivityGraphs, and StateMachines. There may be Associations between UseCases and the Actors of the UseCases. Such an Association states that an instance of the UseCase and a user playing one of the roles of the Actor communicate. UseCases may be related to other UseCases by Extend, Include, and Generalization relationships. An Include relationship means that a UseCase includes the behavior described in another UseCase, while an Extend relationship implies that a UseCase may extend the behavior described in another UseCase, ruled by a condition. Generalization between UseCases means that the child is a more specific form of the parent. The child inherits all Features and Associations of the parent, and may add new Features and Associations. The realization of a UseCase may be specified by a set of Collaborations; that is, the Collaborations define how Instances in the system interact to perform the sequences of the UseCase. location A reference to one location or a collection of locations where an extension to the behavior of the use case may be inserted. addition The UseCase specifying the additional behavior. base The UseCase that is to include the addition. March 2003 OMG-Unified Modeling Language, v1.5 2-133 2 UML Semantics Associations 2.11.2.6 UseCaseInstance A use case instance is the performance of a sequence of actions specified in a use case. In the metamodel, UseCaseInstance is a subclass of Instance. Each method performed by a UseCaseInstance is performed as an atomic transaction; that is, it is not interrupted by any other UseCaseInstance. An explicitly described UseCaseInstance is called a scenario. 2.11.3 Well-formedness Rules The following well-formedness rules apply to the Use Cases package. 2.11.3.1 Actor 2.11.3.2 Extend extend A collection of Extend relationships to UseCases that the UseCase extends. extensionPoint Defines a collection of ExtensionPoints where the UseCase may be extended. include A collection of Include relationships to UseCases that the UseCase includes. [1] Actors can only have Associations to UseCases, Subsystems, and Classes and these Associations are binary. self.associations->forAll(a | a.connection->size = 2 and a.allConnections->exists(r | r.type.oclIsKindOf(Actor)) and a.allConnections->exists(r | r.type.oclIsKindOf(UseCase) or r.type.oclIsKindOf(Subsystem) or r.type.oclIsKindOf(Class))) [2] Actors cannot contain any Classifiers. self.contents->isEmpty [1] The referenced ExtensionPoints must be included in set of ExtensionPoint in the target UseCase. self.base.allExtensionPoints -> includesAll (self.extensionPoint) 2-134 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.11.3.3 ExtensionPoint 2.11.3.4 Include No extra well-formedness rules. 2.11.3.5 UseCase Additional operations [1] The name must not be the empty string. not self.name = ‘’ [1] UseCases can only have binary Associations. self.associations->forAll(a | a.connection->size = 2) [2] UseCases cannot have Associations to UseCases specifying the same entity. self.associations->forAll(a | a.allConnections->forAll(s, o| (s.type.specificationPath->isEmpty and o.type.specificationPath->isEmpty ) or (not s.type.specificationPath->includesAll( o.type.specificationPath) and not o.type.specificationPath->includesAll( s.type.specificationPath)) )) [3] A UseCase cannot contain any Classifiers. self.contents->isEmpty [4] The names of the ExtensionPoints must be unique within the UseCase. self.allExtensionPoints -> forAll (x, y | x.name = y.name implies x = y ) [1] The operation specificationPath results in a set containing all surrounding Namespaces that are not instances of Package. specificationPath : Set(Namespace) specificationPath = self.allSurroundingNamespaces->select(n | n.oclIsKindOf(Subsystem) or n.oclIsKindOf(Class)) [2] The operation allExtensionPoints results in a set containing all ExtensionPoints of the UseCase allExtensionPoints : Set(ExtensionPoint) allExtensionPoints = self.allSupertypes.extensionPoint -> union ( self.extensionPoint) March 2003 OMG-Unified Modeling Language, v1.5 2-135 2 UML Semantics 2.11.3.6 UseCaseInstance 2.11.4 Detailed Semantics This section provides a description of the semantics of the elements in the Use Cases package, and its relationship to other elements in the Behavioral Elements package. 2.11.4.1 Actor Figure 2-22 Actor Illustration Actors model parties outside an entity, such as a system, a subsystem, or a class that interact with the entity. Each actor defines a coherent set of roles users of the entity can play when interacting with the entity. Every time a specific user interacts with the entity, it is playing one such role. An instance of an actor is a specific user interacting with the entity. Any instance that conforms to an actor can act as an instance of the actor. If the entity is a system, the actors represent both human users and other systems. Some of the actors of a lower level subsystem or a class may coincide with actors of the system, while others appear inside the system. The roles defined by the latter kind of actors are played by instances of classifiers in other packages or subsystems; in the latter case the classifier may belong to either the specification part or the realization part of the subsystem. Since an actor is outside the entity, its internal structure is not defined but only its external view as seen from the entity. Actor instances communicate with the entity by sending and receiving message instances to and from use case instances and, at realization level, to and from objects. This is expressed by associations between the actor and the use case or the class. Furthermore, interfaces can be connected to an actor, defining how other elements may interact with the actor. [1] The Classifier of a UseCaseInstance must be a UseCase. self.classifier->forAll ( c | c.oclIsKindOf (UseCase) ) [2] A UseCaseInstance may not contain any Instances. self.contents->isEmpty Interface Generalization Association AssociationEnd Namespace Actor*1 * * * * 2-136 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Two or more actors may have commonalities; that is, communicate with the same set of use cases in the same way. The commonality is expressed with generalizations to another (possibly abstract) actor, which models the common role(s). An instance of a child can always be used where an instance of the parent is expected. 2.11.4.2 UseCase Figure 2-23 UseCase Illustration In the following text, the term entity is used when referring to a system, a subsystem, or a class and the terms model element and element denote a subsystem or a class. The purpose of a use case is to define a piece of behavior of an entity without revealing the internal structure of the entity. The entity specified in this way may be a system or any model element that contains behavior, like a subsystem or a class, in a model of a system. Each use case specifies a service the entity provides to its users; that is, a specific way of using the entity. The service, which is initiated by a user, is a complete sequence. This implies that after its performance the entity will in general be in a state in which the sequence can be initiated again. A use case describes the interactions between the users and the entity as well as the responses performed by the entity, as these responses are perceived from the outside of the entity. A use case also includes possible variants of this sequence (for example, alternative sequences, exceptional behavior, error handling, etc.). The complete set of use cases specifies all different ways to use the entity; that is, all behavior of the entity is expressed by its use cases. These use cases can be grouped into packages for convenience. From a pragmatic point of view, use cases can be used both for specification of the (external) requirements on an entity and for specification of the functionality offered by an (already realized) entity. Moreover, the use cases also indirectly state the requirements the specified entity poses on its users; that is, how they should interact so the entity will be able to perform its services. Since users of use cases always are external to the specified entity, they are represented by actors of the entity. Thus, if the specified entity is a system or a subsystem at the topmost level, the users of its use cases are modeled by the actors of the system. Those UseCase Attribute Operation UseCaseInstance AssociationEndAssociation Namespace Interface Include Extend ExtensionPoint * * * * * * * * * * March 2003 OMG-Unified Modeling Language, v1.5 2-137 2 UML Semantics actors of a lower level subsystem or a class that are internal to the system are often not explicitly defined. Instead, the use cases relate directly to model elements conforming to these implicit actors; that is, whose instances play the roles of these actors in interaction with the use cases. These model elements are contained in other packages or subsystems, where in the subsystem case they may be contained in the specification part or the realization part. The distinction between actor and conforming element like this is often neglected; thus, they are both referred to by the term actor. There may be associations between use cases and actors, meaning that the instances of the use case and the actor communicate with each other. One actor may communicate with several use cases of an entity; that is, the actor may request several services of the entity, and one use case communicates with one or several actors when providing its service. Note that two use cases specifying the same entity cannot communicate with each other since each of them individually describes a complete usage of the entity. Moreover, use cases always use signals when communicating with actors outside the system, while they may use other communication semantics when communicating with elements inside the system. The interaction between actors and use cases can be defined with interfaces. An interface of a use case defines a subset of the entire interaction defined in the use case. Different interfaces offered by the same use case need not be disjoint. A use case can be described in plain text, using operations and methods together with attributes, in activity graphs, by a state machine, or by other behavior description techniques, such as preconditions and postconditions. The interaction between a use case and its actors can also be presented in collaboration diagrams for specification of the interactions between the entity containing the use case and the entity’s environment. A use-case instance is a performance of a use case, initiated by a message instance from an instance of an actor. As a response, the use-case instance performs a sequence of actions as specified by the use case, like communicating with actor instances, not necessarily only the initiating one. The actor instances may send new message instances to the use-case instance and the interaction continues until the instance has responded to all input and does not expect any more input, when it ends. Each method performed by a use-case instance is performed as an atomic transaction; that is, it is not interrupted by any other use-case instance. In the case where subsystems are used to model the system’s containment hierarchy, the system can be specified with use cases at all levels, as use cases can be used to specify subsystems and classes. A use case specifying one model element is then refined into a set of smaller use cases, each specifying a service of a model element contained in the first one. The use case of the whole may be referred to as superordinate to its refining use cases, which, correspondingly, may be called subordinate in relation to the first one. The functionality specified by each superordinate use case is completely traceable to its subordinate use cases. Note, though, that the structure of the container element is not revealed by the use cases, since they only specify the functionality offered by the element. The subordinate use cases of a specific superordinate use case cooperate to perform the superordinate one. Their cooperation is specified by collaborations and may be presented in collaboration diagrams. A specific subordinate use case may appear in several collaborations; that is 2-138 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics play a role in the performances of several superordinate use cases. In each such collaboration, other roles specify the cooperation with this specific subordinate use case. These roles are the roles played by the actors of that subordinate use case. Some of these actors may be the actors of the superordinate use case, as each actor of a superordinate use case appears as an actor of at least one of the subordinate use cases. Furthermore, the interfaces of a superordinate use case are traceable to the interfaces of those subordinate use cases that communicate with actors that are also actors of the superordinate use case. The environment of subordinate use cases is the model element containing the model elements specified by these use cases. Thus, from a bottom-up perspective, an interaction between subordinate use cases results in a superordinate use case, that is, a use case of the container element. Use cases of classes are mapped onto operations of the classes, since a service of a class in essence is the invocation of the operations of the class. Some use cases may consist of the application of only one operation, while others may involve a set of operations, usually in a well-defined sequence. One operation may be needed in several of the services of the class, and will therefore appear in several use cases of the class. The realization of a use case depends on the kind of model element it specifies. For example, since the use cases of a class are specified by means of operations of the class, they are realized by the corresponding methods, while the use cases of a subsystem are realized by the elements contained in the subsystem. Since a subsystem does not have any behavior of its own, all services offered by a subsystem must be a composition of services offered by elements contained in the subsystem (i.e., eventually by classes). These elements will collaborate and jointly perform the behavior of the specified use case. One or a set of collaborations describes how the realization of a use case is made. Hence, collaborations are used for specification of both the refinement and the realization of a use case in terms of subordinate use cases. The usage of use cases at all levels imply not only a uniform way of specification of functionality at all levels, but also a powerful technique for tracing requirements at the system package level down to operations of the classes. The propagation of the effect of modifying a single operation at the class level all the way up to the behavior of the system package is managed in the same way. Commonalities between use cases can be expressed in three different ways: with generalization, include, and extend relationships. A generalization relationship between use cases implies that the child use case contains all the attributes, sequences of behavior, and extension points defined in the parent use case, and participates in all relationships of the parent use case. The child use case may also define new behavior sequences, as well as add additional behavior into and specialize existing behavior of the inherited ones. One use case may have several parent use cases and one use case may be a parent to several other use cases. An include relationship between two use cases means that the behavior defined in the target use case is included at one location in the sequence of behavior performed by an instance of the base use case. When a use-case instance reaches the location where the behavior of an another use case is to be included, it performs all the behavior described by the included use case and then continues according to its original use case. This March 2003 OMG-Unified Modeling Language, v1.5 2-139 2 UML Semantics means that although there may be several paths through the included use case due to (e.g., conditional statements), all of them must end in such a way that the use-case instance can continue according to the original use case. One use case may be included in several other use cases and one use case may include several other use cases. The included use case may not be dependent on the base use case. In that sense the included use case represents encapsulated behavior, which may easily be reused in several use cases. Moreover, the base use case may only be dependent on the results of performing the included behavior and not on structure, like Attributes and Associations, of the included use case. An extend relationship defines that a use case may be augmented with some additional behavior defined in another use case. One use case may extend several use cases and one use case may be extended by several use cases. The base use case may not be dependent of the addition of the extending use case. The extend relationship contains a condition and references a sequence of extension points in the target use case. The condition must be satisfied if the extension is to take place, and the references to the extension points define the locations in the base use case where the additions are to be made. Once an instance of a use case is to perform some behavior referenced by an extension point of its use case, and the extension point is the first one in an extends relationship’s sequence of references to extension points, the condition of the relationship is evaluated. If the condition is fulfilled, the sequence obeyed by the use- case instance is extended to include the sequence of the extending use case. The different parts of the extending use case are inserted at the locations defined by the sequence of extension points in the relationship -- one part at each referenced extension point. Note that the condition is only evaluated once: at the first referenced extension point, and if it is fulfilled all of the extending use case is inserted in the original sequence. An extension point may define one location or a set of locations in the behavior defined by the use case. However, if an extend relationship references a sequence of extension points, only the first one may define a set of locations. All other ones must define exactly one location each. Which of the locations of the first extension point to use is determined by where the extension is triggered. This is not possible for the other ones. In other words, once the extension has been triggered, all locations where to add the different part of the extending use case must be uniquely defined. Hence, all extension points, except for the first one, referenced by an extend relationship must define single locations. The description of the location references by an extension point can be made in several different ways, like textual description of where in the behavior the addition should be made, pre-or post conditions, or using the name of a state in a state machine. Note that the three kinds of relationships described above can only exist between use cases specifying the same entity. The reason for this is that the use cases of one entity specify the behavior of that entity alone; that is, all use-case instances are performed entirely within that entity. If a use case would have a generalization, include, or extend relationship to a use case of another entity, the resulting use-case instances would involve both entities, resulting in a contradiction. However, generalization, include, and extend relationships can be defined from use cases specifying one entity to use cases of another one if the first entity has a generalization to the second one, since the contents of both entities are available in the first entity. However, the contents of the second entity must be at least protected, so they become available inside the child entity. 2-140 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics As a first step when developing a system, the dynamic requirements of the system as a whole can be expressed with use cases. The entity being specified is then the whole system, and the result is a separate model called a use-case model, that is, a model with the stereotype «useCaseModel». Next, the realization of the requirements is expressed with a model containing a system package, probably a package hierarchy, and at the bottom a set of classes. If the system package, that is, a package with the stereotype «topLevelPackage» is a subsystem, its abstract behavior is naturally the same as that of the system. Thus, if use cases are used for the specification part of the system package, these use cases are equivalent to those in the use-case model of the system; that is, they express the same behavior but possibly slightly differently structured. In other words, all services specified by the use cases of a system package, and only those, define the services offered by the system. Furthermore, if several models are used for modeling the realization of a system (for example, an analysis model and a design model), the set of use cases of all system packages and the use cases of the use-case model must be equivalent. 2.11.5 Notes A pragmatic rule of use when defining use cases is that each use case should yield some kind of observable result of value to (at least) one of its actors. This ensures that the use cases are complete specifications and not just fragments. 2.12 State Machines 2.12.1 Overview The State Machine package is a subpackage of the Behavioral Elements package. It specifies a set of concepts that can be used for modeling discrete behavior through finite state-transition systems. These concepts are based on concepts defined in the Foundation package as well as concepts defined in the Common Behavior package. This enables integration with the other subpackages in Behavioral Elements. The state machine formalism described in this section is an object-based variant of Harel statecharts. It incorporates several concepts similar to those defined in ROOMcharts, a variant of statechart defined in the ROOM modeling language. The major differences relative to classical Harel statecharts are described on page 2.12.5.42-169. State machines can be used to specify behavior of various elements that are being modeled. For example, they can be used to model the behavior of individual entities (e.g., class instances) or to define the interactions (e.g., collaborations) between entities. In addition, the state machine formalism provides the semantic foundation for activity graphs. This means that activity graphs are simply a special form of state machines. The following sections describe the abstract syntax, well-formedness rules, and semantics of the State Machines package. Activity graphs are described in Section 2.13, “Activity Graphs,” on page 2-170. March 2003 OMG-Unified Modeling Language, v1.5 2-141 2 UML Semantics 2.12.2 Abstract Syntax The abstract syntax for state machines is expressed graphically in Figure 2-24 on page 2-141, which covers all the basic concepts of state machine graphs such as states and transitions. Figure 2-25 on page 2-142 describes the abstract syntax of events that can trigger state machine behavior. The specifications of the concepts defined in these two diagrams are listed in alphabetical order following the figures. Figure 2-24 State Machines - Main Pseudostate i n d : Pse udos t at e Kind SimpleSt at e Sy nchState bound : UnlimitedInteger StubState referenceState : Name FinalStateCompositeState SubmachineState ModelElement (from Cor e) Guard expression : BooleanExpression Event StateVertex 0..* 0.. 1 +subv ertex 0..* +c ont a i ner 0.. 1 StateMachine * 1 * +submachine 1 * 0..1 +behav ior * +context 0..1 State 0..* 0..* 0..* +def errableEv ent 0..* 1 ..1 +t op1 ..1 Procedure (f rom Common Behav ior) 0..1 0..1 0..1 +doActivity 0..1 0..1 0. . 1 0..1 +exit 0. . 1 0..1 0..10..1 +ent ry 0..1 Transition 1 0.. 1 1 +guard0.. 1 0. . 1 * +t r i gger0. . 1 * 1 * +source 1 +outgoing * 1 * +target 1 +i ncoming * * 0..1 transitions* 0..1 * 0..1 +internalTransition* 0..1 0..1 0..1 +effect0..1 0..1 2-142 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Figure 2-25 State Machines - Events 2.12.2.1 CallEvent A call event represents the reception of a request to synchronously invoke a specific operation. (Note that a call event instance is distinct from the call action that caused it.) The expected result is the execution of a sequence of actions which characterize the operation behavior at a particular state. Two special cases of CallEvent are the object creation event and the object destruction event. Associations operation Designates the operation whose invocation raised the call event TimeEvent when : TimeExpression ChangeEvent changeExpression : BooleanExpression Operation (from Core) CallEvent 1 * +operation 1 +occurrence * SignalEvent Signal (from Common Behavior) * 1 +oc c ur ren c e * +signal 1 Parameter (from Core) Event * 0..1 +parameter * {ordered} 0..1 ModelElement (from Core) March 2003 OMG-Unified Modeling Language, v1.5 2-143 2 UML Semantics Stereotypes 2.12.2.2 ChangeEvent A change event models an event that occurs when an explicit boolean expression becomes true as a result of a change in value of one or more attributes or associations. A change event is raised implicitly and is not the result of some explicit change event action. The change event should not be confused with a guard. A guard is only evaluated at the time an event is dispatched whereas, conceptually, the boolean expression associated with a change event is evaluated continuously until it becomes true. The event that is generated remains until it is consumed even if the boolean expression changes to false after that. Attributes 2.12.2.3 CompositeState A composite state is a state that contains other state vertices (states, pseudostates, etc.). The association between the composite and the contained vertices is a composition association. Hence, a state vertex can be a part of at most one composite state. Any state enclosed within a composite state is called a substate of that composite state. It is called a direct substate when it is not contained by any other state; otherwise it is referred to as a transitively nested substate. CompositeState is a child of State. Associations «create» Class Create is a stereotyped call event denoting that the instance receiving that event has just been created. For state machines, it triggers the initial transition at the topmost level of the state machine (and is the only kind of trigger that may be applied to an initial transition). «destroy» Class Destroy is a stereotyped call event denoting that the instance receiving the event is being destroyed. changeExpression The boolean expression that specifies the change event. subvertex The set of state vertices that are owned by this composite state. 2-144 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes 2.12.2.4 Event An event is a specification of a type of observable occurrence. The occurrence that generates an event instance is assumed to take place at an instant in time with no duration. Strictly speaking, the term “event” is used to refer to the type and not to an instance of the type. However, on occasion, where the meaning is clear from the context, the term is also used to refer to an event instance. Event is a child of ModelElement. Associations 2.12.2.5 FinalState A special kind of state signifying that the enclosing composite state is completed. If the enclosing state is the top state, then it means that the entire state machine has completed. A final state cannot have any outgoing transitions. FinalState is a child of State. 2.12.2.6 Guard A guard is a boolean expression that is attached to a transition as a fine-grained control over its firing. The guard is evaluated when an event instance is dispatched by the state machine. If the guard is true at that time, the transition is enabled, otherwise, it is disabled. Guards should be pure expressions without side effects. Guard expressions with side effects are ill formed. Guard is a child of ModelElement. isConcurrent A boolean value that specifies the decomposition semantics. If this attribute is true, then the composite state is decomposed directly into two or more orthogonal conjunctive components called regions (usually associated with concurrent execution). If this attribute is false, then there are no direct orthogonal components in the composite. isRegion A derived boolean value that indicates whether a CompositeState is a substate of a concurrent state. If it is true, then this composite state is a direct substate of a concurrent state. parameter The list of parameters defined by the event. March 2003 OMG-Unified Modeling Language, v1.5 2-145 2 UML Semantics Attributes 2.12.2.7 PseudoState A pseudostate is an abstraction that encompasses different types of transient vertices in the state machine graph. They are used, typically, to connect multiple transitions into more complex state transitions paths. For example, by combining a transition entering a fork pseudostate with a set of transitions exiting the fork pseudostate, we get a compound transition that leads to a set of concurrent target states. The following pseudostate kinds are defined: • An initial pseudostate represents a default vertex that is the source for a single transition to the default state of a composite state. There can be at most one initial vertex in a composite state. • deepHistory is used as a shorthand notation that represents the most recent active configuration of the composite state that directly contains this pseudostate; that is, the state configuration that was active when the composite state was last exited. A composite state can have at most one deep history vertex. A transition may originate from the history connector to the default deep history state. This transition is taken in case the composite state had never been active before. • shallowHistory is a shorthand notation that represents the most recent active substate of its containing state (but not the substates of that substate). A composite state can have at most one shallow history vertex. A transition coming into the shallow history vertex is equivalent to a transition coming into the most recent active substate of a state. A transition may originate from the history connector to the initial shallow history state. This transition is taken in case the composite state had never been active before. • join vertices serve to merge several transitions emanating from source vertices in different orthogonal regions. The transitions entering a join vertex cannot have guards. • fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards. • junction vertices are semantic-free vertices that are used to chain together multiple transitions. They are used to construct compound transition paths between states. For example, a junction can be used to converge multiple incoming transitions into a single outgoing transition representing a shared transition path (this is known as an merge). Conversely, they can be used to split an incoming transition into multiple outgoing transition segments with different guard conditions. This realizes a static conditional branch. (In the latter case, outgoing transitions whose guard conditions evaluate to false are disabled. A predefined guard denoted “else” may be defined for at most one outgoing transition. This transition is enabled if all the guards labeling the other transitions are false.) Static conditional branches are distinct from dynamic conditional branches that are realized by choice vertices (described below). expression The boolean expression that specifies the guard. 2-146 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics • choice vertices which, when reached, result in the dynamic evaluation of the guards of its outgoing transitions. This realizes a dynamic conditional branch. It allows splitting of transitions into multiple outgoing paths such that the decision on which path to take may be a function of the results of prior actions performed in the same run-to-completion step. If more than one of the guards evaluates to true, an arbitrary one is selected. If none of the guards evaluates to true, then the model is considered ill formed. (To avoid this, it is recommended to define one outgoing transition with the predefined “else” guard for every choice vertex.) Choice vertices should be distinguished from static branch points that are based on junction points (described above). PseudoState is a child of StateVertex. Attributes 2.12.2.8 SignalEvent A signal event represents the reception of a particular (asynchronous) signal. A signal event instance should not be confused with the action (e.g., send action) that generated it. SignalEvent is a child of Event. Associations 2.12.2.9 SimpleState A SimpleState is a state that does not have substates. It is a child of State. 2.12.2.10 State A state is an abstract metaclass that models a situation during which some (usually implicit) invariant condition holds. The invariant may represent a static situation such as an object waiting for some external event to occur. However, it can also model dynamic conditions such as the process of performing some activity (i.e., the model element under consideration enters the state when the activity commences and leaves it as soon as the activity is completed). State is a child of StateVertex. kind Determines the precise type of the PseudoState and can be one of: initial, deepHistory, shallowHistory, join, fork, junction, or choice. signal The specific signal that is associated with this event. March 2003 OMG-Unified Modeling Language, v1.5 2-147 2 UML Semantics Associations 2.12.2.11 StateMachine A state machine is a specification that describes all possible behaviors of some dynamic model element. Behavior is modeled as a traversal of a graph of state nodes interconnected by one or more joined transition arcs that are triggered by the dispatching of series of event instances. During this traversal, the state machine executes a series of actions associated with various elements of the state machine. StateMachine has a composition relationship to State, which represents the top-level state, and a set of transitions. This means that a state machine owns its transitions and its top state. All remaining states are transitively owned through the state containment hierarchy rooted in the top state. The association to ModelElement provides the context of the state machine. A common case of the context relation is where a state machine is used to specify the lifecycle of a classifier. Associations deferrableEvent A list of events that are candidates to be retained by the state machine if they trigger no transitions out of the state (not consumed). entry An optional procedure that is executed whenever this state is entered regardless of the transition taken to reach the state. If defined, entry actions are always executed to completion prior to any internal activity or transitions performed within the state. exit An optional procedure that is executed whenever this state is exited regardless of which transition was taken out of the state. If defined, exit actions are always executed to completion only after all internal activities and transition actions have completed execution. doActivity An optional activity that is executed while being in the state. The execution starts when this state is entered, and stops either by itself, or when the state is exited, whichever comes first. internalTransition A set of transitions that, if triggered, occur without exiting or entering this state. Thus, they do not cause a state change. This means that the entry or exit condition of the State will not be invoked. These transitions can be taken even if the state machine is in one or more regions nested within this state. context An association to the model element that whose behavior is specified by this state machine. A model element may have more than one state machine (although one is sufficient for most purposes). Each state machine is optionally owned by one model element. top Designates the top-level state that is the root of the state containment hierarchy. There is exactly one state in every state machine that is the top state. 2-148 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.12.2.12 StateVertex A StateVertex is an abstraction of a node in a statechart graph. In general, it can be the source or destination of any number of transitions. StateVertex is a child of ModelElement. Associations 2.12.2.13 StubState A stub state can appear within a submachine state and represents an actual subvertex contained within the referenced state machine. It can serve as a source or destination of transitions that connect a state vertex in the containing state machine with a subvertex in the referenced state machine. StubState is a child of State. Associations 2.12.2.14 SubmachineState A submachine state is a syntactical convenience that facilitates reuse and modularity. It is a shorthand that implies a macro-like expansion by another state machine and is semantically equivalent to a composite state. The state machine that is inserted is called the referenced state machine while the state machine that contains the submachine state is called the containing state machine. The same state machine may be referenced more than once in the context of a single containing state machine. In effect, a submachine state represents a “call” to a state machine “subroutine” with one or more entry and exit points. The entry and exit points are specified by stub states. SubmachineState is a child of State. transition The set of transitions owned by the state machine. Note that internal transitions are owned by their containing states and not by the state machine. outgoing Specifies the transitions departing from the vertex. incoming Specifies the transitions entering the vertex. container The composite state that contains this state vertex. referenceState Designates the referenced state as a pathname (a name formed by the concatenation of the name of a state and the successive names of all states that contain it, up to the top state). March 2003 OMG-Unified Modeling Language, v1.5 2-149 2 UML Semantics Associations 2.12.2.15 SynchState A synch state is a vertex used for synchronizing the concurrent regions of a state machine. It is different from a state in the sense that it is not mapped to a boolean value (active, not active), but an integer. A synch sate is used in conjunction with forks and joins to insure that one region leaves a particular state or states before another region can enter a particular state or states. SynchState is a child of StateVertex. Attributes 2.12.2.16 TimeEvent A TimeEvent models the expiration of a specific deadline. Note that the time of occurrence of a time event instance (i.e., the expiration of the deadline) is the same as the time of its reception. However, it is important to note that there may be a variable delay between the time of reception and the time of dispatching (e.g., due to queueing delays). The expression specifying the deadline may be relative or absolute. If the time expression is relative and no explicit starting time is defined, then it is relative to the time of entry into the source state of the transition triggered by the event. In the latter case, the time event instance is generated only if the state machine is still in that state when the deadline expires. Attributes 2.12.2.17 Transition A transition is a directed relationship between a source state vertex and a target state vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to a particular event instance. Transition is a child of ModelElement. submachine The state machine that is to be substituted in place of the submachine state. bound A positive integer or the value “unlimited” specifying the maximal count of the SynchState. The count is the difference between the number of times the incoming and outgoing transitions of the synch state are fired when Specifies the corresponding time deadline 2-150 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Associations 2.12.3 Well-formedness Rules The following well-formedness rules apply to the State Machines package. 2.12.3.1 CompositeState trigger Specifies the event that fires the transition. There can be at most one trigger per transition guard A boolean predicate that provides a fine-grained control over the firing of the transition. It must be true for the transition to be fired. It is evaluated at the time the event is dispatched. There can be at most one guard per transition. effect Specifies an optional procedure to be performed when the transition fires. source Designates the originating state vertex (state or pseudostate) of the transition. target Designates the target state vertex that is reached when the transition is taken. [1] A composite state can have at most one initial vertex. self.subvertex->select (v | v.oclIsKindOf(Pseudostate))-> select(p : Pseudostate | p.kind = #initial)->size <= 1 [2] A composite state can have at most one deep history vertex. self.subvertex->select (v | v.oclIsKindOf(Pseudostate))-> select(p : Pseudostate | p.kind = #deepHistory)->size <= 1 [3] A composite state can have at most one shallow history vertex. self.subvertex->select(v | v.oclIsKindOf(Pseudostate))-> select(p : Pseudostate | p.kind = #shallowHistory)->size <= 1 [4] There have to be at least two composite substates in a concurrent composite state. (self.isConcurrent) implies (self.subvertex->select (v | v.oclIsKindOf(CompositeState))->size >= 2) [5] A concurrent state can only have composite states as substates. (self.isConcurrent) implies self.subvertex->forAll(s | s.oclIsKindOf(CompositeState)) [6] The substates of a composite state are part of only that composite state. self.subvertex->forAll(s | (s.container->size = 1) and (s.container = self)) March 2003 OMG-Unified Modeling Language, v1.5 2-151 2 UML Semantics 2.12.3.2 FinalState 2.12.3.3 Guard 2.12.3.4 PseudoState [1] A final state cannot have any outgoing transitions. self.outgoing->size = 0 [1] A guard should not have side effects. self.transition->stateMachine->notEmpty implies post: (self.transition.stateMachine->context = self.transition.stateMachine->context@pre) [1] An initial vertex can have at most one outgoing transition and no incoming transitions. (self.kind = #initial) implies ((self.outgoing->size <= 1) and (self.incoming->isEmpty)) [2] History vertices can have at most one outgoing transition. ((self.kind = #deepHistory) or (self.kind = #shallowHistory)) implies (self.outgoing->size <= 1) [3] A join vertex must have at least two incoming transitions and exactly one outgoing transition. (self.kind = #join) implies ((self.outgoing->size = 1) and (self.incoming->size >= 2)) [4] All transitions incoming a join vertex must originate in different regions of a concurrent state. (self.kind = #join and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies self.incoming->forAll (t1, t2 | t1<>t2 implies (self.stateMachine.LCA(t1.source, t2.source). container.isConcurrent) [5] A fork vertex must have at least two outgoing transitions and exactly one incoming transition. (self.kind = #fork) implies ((self.incoming->size = 1) and (self.outgoing->size >= 2)) [6] All transitions outgoing a fork vertex must target states in different regions of a concurrent state. (self.kind = #fork and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies self.outgoing->forAll (t1, t2 | t1<>t2 implies (self.stateMachine.LCA(t1.target, t2.target). container.isConcurrent) 2-152 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.12.3.5 StateMachine [7] A junction vertex must have at least one incoming and one outgoing transition. (self.kind = #junction) implies ((self.incoming->size >= 1) and (self.outgoing->size >= 1)) [8] A choice vertex must have at least one incoming and one outgoing transition. (self.kind = #choice) implies ((self.incoming->size >= 1) and (self.outgoing->size >= 1)) [1] A StateMachine is aggregated within either a classifier or a behavioral feature. self.context.notEmpty implies (self.context.oclIsKindOf(BehavioralFeature) or self.context.oclIsKindOf(Classifier)) [2] A top state is always a composite. self.top.oclIsTypeOf(CompositeState) [3] A top state cannot have any containing states. self.top.container->isEmpty [4] The top state cannot be the source of a transition. (self.top.outgoing->isEmpty) [5] If a StateMachine describes a behavioral feature, it contains no triggers of type CallEvent, apart from the trigger on the initial transition (see OCL for Transition [8]). self.context.oclIsKindOf(BehavioralFeature) implies self.transitions->reject( source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind= #initial).trigger->isEmpty March 2003 OMG-Unified Modeling Language, v1.5 2-153 2 UML Semantics Additional Operations 2.12.3.6 SynchState 2.12.3.7 SubmachineState 2.12.3.8 Transition [1] The operation LCA(s1,s2) returns the state which is the least common ancestor of states s1 and s2. context StateMachine::LCA (s1 : State, s2 : State) : CompositeState result = if ancestor (s1, s2) then s1 else if ancestor (s2, s1) then s2 else (LCA (s1.container, s2.container)) [2] The query ancestor(s1, s2) checks whether s2 is an ancestor state of state s1. context StateMachine::ancestor (s1 : State, s2 : State) : Boolean result = if (s2 = s1) then true else if (s1.container->isEmpty) then true else if (s2.container->isEmpty) then false else (ancestor (s1, s2.container) [1] The value of the bound attribute must be a positive integer, or unlimited. (self.bound > 0) or (self.bound = unlimited) [2] All incoming transitions to a SynchState must come from the same region and all outgoing transitions from a SynchState must go to the same region. [1] Only stub states allowed as substates of a submachine state. self.subvertex->forAll (s | s.oclIsTypeOf(StubState)) [2] Submachine states are never concurrent. self.isConcurrent = false [1] A fork segment should not have guards or triggers. (self.source.oclIsKindOf(Pseudostate) and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies ((self.source.oclAsType(Pseudostate).kind = #fork) implies ((self.guard->isEmpty) and (self.trigger->isEmpty))) [2] A join segment should not have guards or triggers. 2-154 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.12.4 Detailed Semantics This section describes the execution semantics of state machines. For convenience, the semantics are described in terms of the operations of a hypothetical machine that implements a state machine specification. This is for reference purposes only. Individual realizations are free to choose any form that achieves the same semantics. In the general case, the key components of this hypothetical machine are: • an event queue which holds incoming event instances until they are dispatched • an event dispatcher mechanism that selects and de-queues event instances from the event queue for processing • an event processor which processes dispatched event instances according to the general semantics of UML state machines and the specific form of the state machine in question. Because of that, this component is simply referred to as the “state machine” in the following text. Although the intent is to define the semantics of state machines very precisely, there are a number of semantic variation points to allow for different semantic interpretations that might be required in different domains of application. These are clearly identified in the text. self.target.oclIsKindOf(Pseudostate) implies ((self.target.oclAsType(Pseudostate).kind = #join) implies ((self.guard->isEmpty) and (self.trigger->isEmpty))) [3] A fork segment should always target a state. (self.stateMachine->notEmpty and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies self.source.oclIsKindOf(Pseudostate) implies ((self.source.oclAsType(Pseudostate).kind = #fork) implies (self.target.oclIsKindOf(State))) [4] A join segment should always originate from a state. (self.stateMachine->notEmpty and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies self.target.oclIsKindOf(Pseudostate) implies ((self.target.oclAsType(Pseudostate).kind = #join) implies (self.source.oclIsKindOf(State))) [5] Transitions outgoing pseudostates may not have a trigger self.source.oclIsKindOf(Pseudostate) implies (self.trigger->isEmpty)) [6] An initial transition at the topmost level either has no trigger or it has a trigger with the stereotype “create.” self.source.oclIsKindOf(Pseudostate) implies (self.source.oclAsType(Pseudostate).kind = #initial) implies (self.source.container = self.stateMachine.top) implies ((self.trigger->isEmpty) or (self.trigger.stereotype.name = 'create')) March 2003 OMG-Unified Modeling Language, v1.5 2-155 2 UML Semantics The basic semantics of events, states, transitions, etc. are discussed first in separate subsections under the appropriate headings. The operation of the state machine as a whole are then described in the state machine subsection. 2.12.4.1 Event Event instances are generated as a result of some action either within the system or in the environment surrounding the system. An event is then conveyed to one or more targets. The means by which event instances are transported to their destination depend on the type of action, the target, the properties of the communication medium, and numerous other factors. In some cases, this is practically instantaneous and completely reliable while in others it may involve variable transmission delays, loss of events, reordering, or duplication. No specific assumptions are made in this regard. This provides full flexibility for modeling different types of communication facilities. An event is received when it is placed on the event queue of its target. An event is dispatched when it is dequeued from the event queue and delivered to the state machine for processing. At this point, it is referred to as the current event. Finally, it is consumed when event processing is completed. A consumed event is no longer available for processing. No assumptions are made about the time intervals between event reception, event dispatching, and consumption. This leaves open the possibility of different semantic models such as zero-time semantics. Any parameter values associated with the current event are available to all actions directly caused by that event (transition actions, entry actions, etc.). Event generalization may be defined explicitly by a signal taxonomy in the case of signal events, or implicitly defined by event expressions, as in time events. 2.12.4.2 State Active states A state can be active or inactive during execution. A state becomes active when it is entered as a result of some transition, and becomes inactive if it is exited as a result of a transition. A state can be exited and entered as a result of the same transition (e.g., self transition). State entry and exit Whenever a state is entered, it executes its entry action before any other action is executed. Conversely, whenever a state is exited, it executes its exit action as the final step prior to leaving the state. If defined, the activity associated with a state is forked as a concurrent activity at the instant when the entry action of the state is completed. Upon exit, the activity is terminated before the exit action is executed. 2-156 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Activity in state (do-activity) The activity represents the execution of a sequence of actions, that occurs while the state machine is in the corresponding state. The activity starts executing upon entering the state, following the entry action. If the activity completes while the state is still active, it raises a completion event. In case where there is an outgoing completion transition (see below) the state will be exited. If the state is exited as a result of the firing of an outgoing transition before the completion of the activity, the activity is aborted prior to its completion. Deferred events A state may specify a set of event types that may be deferred in that state. An event instance that does not trigger any transitions in the current state, will not be dispatched if its type matches one of the types in the deferred event set of that state. Instead, it remains in the event queue while another non-deferred message is dispatched instead. This situation persists until a state is reached where either the event is no longer deferred or where the event triggers a transition. 2.12.4.3 CompositeState Active state configurations When dealing with composite and concurrent states, the simple term “current state” can be quite confusing. In a hierarchical state machine more than one state can be active at once. If the state machine is in a simple state that is contained in a composite state, then all the composite states that either directly or transitively contain the simple state are also active. Furthermore, since some of the composite states in this hierarchy may be concurrent, the current active “state” is actually represented by a tree of states starting with the single top state at the root down to individual simple states at the leaves. We refer to such a state tree as a state configuration. Except during transition execution, the following invariants always apply to state configurations: • If a composite state is active and not concurrent, exactly one of its substates is active. • If the composite state is active and concurrent, all of its substates (regions) are active. Entering a non-concurrent composite state Upon entering a composite state, the following cases are differentiated: • Default entry: Graphically, this is indicated by an incoming transition that terminates on the outside edge of the composite state. In this case, the default transition is taken. If there is a guard on the transition it must be enabled (true). (A disabled initial transition is an ill-defined execution state and its handling is not defined.) The entry action of the state is executed before the action associated with the initial transition. March 2003 OMG-Unified Modeling Language, v1.5 2-157 2 UML Semantics • Explicit entry: If the transition goes to a substate of the composite state, then that substate becomes active and its entry code is executed after the execution of the entry code of the composite state. This rule applies recursively if the transition terminates on a transitively nested substate. • Shallow history entry: If the transition terminates on a shallow history pseudostate, the active substate becomes the most recently active substate prior to this entry, unless the most recently active substate is the final state or if this is the first entry into this state. In the latter two cases, the default history state is entered. This is the substate that is target of the transition originating from the history pseudostate. (If no such transition is specified, the situation is illegal and its handling is not defined.) If the active substate determined by history is a composite state, then it proceeds with its default entry. • Deep history entry: The rule here is the same as for shallow history except that the rule is applied recursively to all levels in the active state configuration below this one. Entering a concurrent composite state Whenever a concurrent composite state is entered, each one of its concurrent substates (regions) is also entered, either by default or explicitly. If the transition terminates on the edge of the composite state, then all the regions are entered using default entry. If the transition explicitly enters one or more regions (in case of a fork), these regions are entered explicitly and the others by default. Exiting non-concurrent state When exiting from a composite state, the active substate is exited recursively. This means that the exit actions are executed in sequence starting with the innermost active state in the current state configuration. Exiting a concurrent state When exiting from a concurrent state, each of its regions is exited. After that, the exit actions of the regions are executed. Deferred events An event that is deferred in a composite state is automatically deferred in all directly or transitively nested substates. 2.12.4.4 FinalState When the final state is active, its containing composite state is completed, which means that it satisfies the completion condition. If the containing state is the top state, the entire state machine terminates, implying the termination of the entity associated with the state machine. If the state machine specifies the behavior of a classifier, it implies the “termination” of that instance. 2-158 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.12.4.5 SubmachineState A submachine state is a convenience that does not introduce any additional dynamic semantics. It is semantically equivalent to a composite state and may have entry and exit actions, internal transitions, and activities. 2.12.4.6 Transitions High-level transitions Transitions originating from the boundary of composite states are called high-level or group transitions. If triggered, they result in exiting of all the substates of the composite state executing their exit actions starting with the innermost states in the active state configuration. Note that in terms of execution semantics, a high-level transition does not add specialized semantics, but rather reflects the semantics of exiting a composite state. Compound transitions A compound transition is a derived semantic concept, represents a “semantically complete” path made of one or more transitions, originating from a set of states (as opposed to pseudo-state) and targeting a set of states. The transition execution semantics described below, refer to compound transitions. In general, a compound transition is an acyclical unbroken chain of transitions joined via join, junction, choice, or fork pseudostates that define path from a set of source states (possibly a singleton) to a set of destination states, (possibly a singleton). For self-transitions, the same state acts as both the source and the destination set. A (simple) transition connecting two states is therefore a special common case of a compound transition. The tail of a compound transition may have multiple transitions originating from a set of mutually orthogonal concurrent regions that are joined by a join point. The head of a compound transition may have multiple transitions originating from a fork pseudostate targeted to a set of mutually orthogonal concurrent regions. In a compound transition multiple outgoing transitions may emanate from a common junction point. In that case, only one of the outgoing transition whose guard is true is taken. If multiple transitions have guards that are true, a transition from this set is chosen. The algorithm for selecting such a transition is not specified. Note that in this case, the guards are evaluated before the compound transition is taken. In a compound transition where multiple outgoing transitions emanate from a common choice point, the outgoing transition whose guard is true at the time the choice point is reached, will be taken. If multiple transitions have guards that are true, one transition from this set is chosen. The algorithm for selecting this transition is not specified. If no guards are true after the choice point has been reached, the model is ill formed. March 2003 OMG-Unified Modeling Language, v1.5 2-159 2 UML Semantics Internal transitions An internal transition executes without exiting or re-entering the state in which it is defined. This is true even if the state machine is in a nested state within this state. Completion transitions and completion events A completion transition is a transition without an explicit trigger, although it may have a guard defined. When all transition and entry actions and activities in the currently active state are completed, a completion event instance is generated. This event is the implicit trigger for a completion transition. The completion event is dispatched before any other queued events and has no associated parameters. For instance, a completion transition emanating from a concurrent composite state will be taken automatically as soon as all the concurrent regions have reached their final state. If multiple completion transitions are defined for a state, then they should have mutually exclusive guard conditions. Enabled (compound) transitions A transition is enabled if and only if: • All of its source states are in the active state configuration. • The trigger of the transition is satisfied by the current event. An event instance satisfies a trigger if it matches the event specified by the trigger. In case of signal events, since signals are generalized concepts, a signal event satisfies a signal event associated with the same signal or a generalization of thereof. • If there exists at least one full path from the source state configuration to either the target state configuration or to a dynamic choice point in which all guard conditions are true (transitions without guards are treated as if their guards are always true). Since more than one transition may be enabled by the same event instance, being enabled is a necessary but not sufficient condition for the firing of a transition. Guards In a simple transition with a guard, the guard is evaluated before the transition is triggered. In compound transitions involving multiple guards, all guards are evaluated before a transition is triggered, unless there are choice points along one or more of the paths. The order in which the guards are evaluated is not defined. If there are choice points in a compound transition, only guards that precede the choice point are evaluated according to the above rule. Guards downstream of a choice point are evaluated if and when the choice point is reached (using the same rule as above). In other words, for guard evaluation, a choice point has the same effect as a state. Guards should not include expressions causing side effects. Models that violate this are considered ill formed. 2-160 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Transition execution sequence Every transition, except for internal transitions, causes exiting of a source state, and entering of the target state. These two states, which may be composite, are designated as the main source and the main target of a transition. The least common ancestor (LCA) state of a transition is the lowest composite state that contains all the explicit source states and explicit target states of the compound transition. In case of junction segments, only the states related to the dynamically selected path are considered explicit targets (bypassed branches are not considered). If the LCA is not a concurrent state, the main source is a direct substate of the least common ancestor that contains the explicit source states, and the main target is a substate of the least common ancestor that contains the explicit target states. In case where the LCA is a concurrent state, the main source and main target are the concurrent state itself. The reason is that if a concurrent region is exited, it forces exit of the entire concurrent state. Examples: 1. The common simple case: A transition t between two simple states s1 and s2, in a composite state s. Here least common ancestor of t is s, the main source is s1 and the main target is s2. 2. A more esoteric case: An unstructured transition from one region to another. Figure 2-26 Unstructured transition among regions Here least common ancestor of t is s, the main source is s and the main target is s, since s is a concurrent state as specified above. Once a transition is enabled and is selected to fire, the following steps are carried out in order: • The main source state is properly exited. • Actions are executed in sequence following their linear order along the segments of the transition: The closer the action to the source state, the earlier it is executed. s s1 s2 t March 2003 OMG-Unified Modeling Language, v1.5 2-161 2 UML Semantics • If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path whose guards are true is selected. Entry and exit actions are executed for states entered and exited by the transition into the choice point. • The main target state is properly entered. 2.12.4.7 StateMachine Event processing - run-to-completion step Events are dispatched and processed by the state machine, one at a time. The order of dequeuing is not defined, leaving open the possibility of modeling different priority- based schemes. The semantics of event processing is based on the run-to-completion assumption, interpreted as run-to-completion processing. Run-to-completion processing means that an event can only be dequeued and dispatched if the processing of the previous current event is fully completed. Run-to-completion may be implemented in various ways. For active classes, it may be realized by an event-loop running in its own concurrent thread, and that reads events from a queue. For passive classes it may be implemented as a monitor. The processing of a single event by a state machine is known as an run-to-completion step. Before commencing on a run-to-completion step, a state machine is in a stable state configuration with all actions (but not necessarily activities) completed. The same conditions apply after the run-to-completion step is completed. Thus, an event will never be processed while the state machine is in some intermediate and inconsistent situation. The run-to-completion step is the passage between two state configurations of the state machine. The run-to-completion assumption simplifies the transition function of the state machine, since concurrency conflicts are avoided during the processing of event, allowing the state machine to safely complete its run-to-completion step. When an event instance is dispatched, it may result in one or more transitions being enabled for firing. If no transition is enabled and the event is not in the deferred event list of the current state configuration, the event is discarded and the run-to-completion step is completed. In the presence of concurrent states it is possible to fire multiple transitions as a result of the same event — as many as one transition in each concurrent state in the current state configuration. In case where one or more transitions are enabled, the state machine selects a subset and fires them. Which of the enabled transitions actually fire is determined by the transition selection algorithm described below. The order in which selected transitions fire is not defined. 2-162 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Each orthogonal region in the active state configuration that is not decomposed into concurrent regions (i.e., “bottom-level” region) can fire at most one transition as a result of the current event. When all orthogonal regions have finished executing the transition, the current event instance is fully consumed, and the run-to-completion step is completed. During a transition, a number of actions may be executed. If these actions are synchronous, then the transition step is not completed until the invoked objects complete their own run-to-completion steps. An event instance can arrive at a state machine that is blocked in the middle of a run- to-completion step from some other object within the same thread, in a circular fashion. This event instance can be treated by orthogonal components of the state machine that are not frozen along transitions at that time. Run-to-completion and concurrency It is possible to define state machine semantics by allowing the run-to-completion steps to be applied concurrently to the orthogonal regions of a composite state, rather than to the whole state machine. This would allow the event serialization constraint to be relaxed. However, such semantics are quite subtle and difficult to implement. Therefore, the dynamic semantics defined in this document are based on the premise that a single run-to-completion step applies to the entire state machine and includes the concurrent steps taken by concurrent regions in the active state configuration. In case of active objects, where each object has its own thread of execution, it is very important to clearly distinguish the notion of run to completion from the concept of thread pre-emption. Namely, run-to-completion event handling is performed by a thread that, in principle, can be pre-empted and its execution suspended in favor of another thread executing on the same processing node. (This is determined by the scheduling policy of the underlying thread environment — no assumptions are made about this policy.) When the suspended thread is assigned processor time again, it resumes its event processing from the point of pre-emption and, eventually, completes its event processing. Conflicting transitions It was already noted that it is possible for more than one transition to be enabled within a state machine. If that happens, then such transitions may be in conflict with each other. For example, consider the case of two transitions originating from the same state, triggered by the same event, but with different guards. If that event occurs and both guard conditions are true, then only one transition will fire. In other words, in case of conflicting transitions, only one of them will fire in a single run-to-completion step. Two transitions are said to conflict if they both exit the same state, or, more precisely, that the intersection of the set of states they exit is non-empty. Only transitions that occur in mutually orthogonal regions may be fired simultaneously. This constraint guarantees that the new active state configuration resulting from executing the set of transitions is well formed. March 2003 OMG-Unified Modeling Language, v1.5 2-163 2 UML Semantics An internal transition in a state conflicts only with transitions that cause an exit from that state. Firing priorities In situations where there are conflicting transitions, the selection of which transitions will fire is based in part on an implicit priority. These priorities resolve some transition conflicts, but not all of them. The priorities of conflicting transitions are based on their relative position in the state hierarchy. By definition, a transition originating from a substate has higher priority than a conflicting transition originating from any of its containing states. The priority of a transition is defined based on its source state. The priority of joined transitions is based on the priority of the transition with the most transitively nested source state. In general, if t1 is a transition whose source state is s1, and t2 has source s2, then: • If s1 is a direct or transitively nested substate of s2, then t1 has higher priority than t2. • If s1 and s2 are not in the same state configuration, then there is no priority difference between t1 and t2. Transition selection algorithm The set of transitions that will fire is a maximal set of transitions that satisfies the following conditions: • All transitions in the set are enabled. • There are no conflicting transitions within the set. • There is no transition outside the set that has higher priority than a transition in the set (that is, enabled transitions with highest priorities are in the set while conflicting transitions with lower priorities are left out). This can be easily implemented by a greedy selection algorithm, with a straightforward traversal of the active state configuration. States in the active state configuration are traversed starting with the innermost nested simple states and working outwards toward the top state. For each state at a given level, all originating transitions are evaluated to determine if they are enabled. This traversal guarantees that the priority principle is not violated. The only non-trivial issue is resolving transition conflicts across orthogonal states on all levels. This is resolved by terminating the search in each orthogonal state once a transition inside any one of its components is fired. 2.12.4.8 Synch States Synch states provide a means of synchronizing the execution of two concurrent regions. Specifically, a synch state has incoming transitions from a fork (or forks) in one region, the source region, and outgoing transitions to a join (or joins) in another, the target region. These forks and joins are called synchronization forks and joins. The 2-164 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics synch state itself is contained by the least common ancestor of the two regions being synchronized. The synchronized regions do not need to be siblings in state decomposition, but they must have a common ancestor state. When the source region reaches a synchronization fork, the target states of that fork become active, including the synch state. Activation of the synch state is an indication that the source region has completed some activity. This region can continue performing its remaining activities in parallel. When the target region reaches the corresponding synchronization join, it is prevented from continuing unless all the states leading into the synchronization join are active, including the synch states. A synch state may have multiple incoming and outgoing transitions, used for multiple synchronization points in each region. Alternatively, it may have single incoming and outgoing transitions where the incoming transition is fired multiple times before the outgoing one is fired. To support these applications, synch states keep count of the difference between the number of times their incoming and outgoing transitions are fired. When an incoming transition is fired, the count is incremented by one, unless its value is equal to the value defined in the bound attribute. In that case, the count is not incremented. When an outgoing transition is fired, the count is decremented by one. An outgoing transition may fire only if the count is greater than zero, which prevents the count from becoming negative. The count is automatically set to zero when its container state is exited. The bound attribute is for limiting the number of times outgoing transitions fire from a synch state. For a state, to realize the equivalent of a binary semaphore, the bound should be set to one. In this case multiple incoming transitions may fire before the outgoing transition does, whereupon the outgoing transition can only fire once. 2.12.4.9 StubStates Stub states are pseudostates signifying either entry points to or exit points from a submachine. Since a submachine is encapsulated and represented as a submachine state, multi-level (“deep”) transitions may logically connect states in separate state machines. This is facilitated by stub state, representing real states in a referenced machine to or form transitions in the referencing machine are incoming/outgoing. stub states are therefore can only be defined within a submachine state, and are the only potential subvertices of a submachine state. March 2003 OMG-Unified Modeling Language, v1.5 2-165 2 UML Semantics 2.12.5 Notes 2.12.5.1 Protocol State Machines One application area of state machines is in specifying object protocols, also known as object life cycles. A 'protocol state machine' for a class defines the order (i.e. sequence) in which the operations of that Class can be invoked. The behavior of each of these operations is defined by an associated method, rather than through actions on transitions. A transition in a protocol state machine has as its trigger a call event that references an operation of the class, and no actions. Such a transition indicates that if the call event occurs when an object of the class is in the source state of the transition and the guard on the transition is true, then the method associated with the operation of the call event will be executed (if one exists), and the object will enter the target state. Semantically, the invocation of the method does not lead to a new call event being raised. If a call event arrives when the state machine is not in an appropriate state to handle the event, the event is discarded, conform the general RTC semantics. Strictly speaking, from the caller's point of view this means that the call is completed. If instead the semantics are required that the caller should 'hang' (potentially infinitely) if the receiver's state machine is not able to process the call event immediately, then the event must be deferred explicitly. This can be done for all call events in a protocol state machine by deferring them at a superstate level. In any practical application, a protocol state machine is made up exclusively of 'protocol' transitions, and the entry and exit actions of its states are empty (i.e. no action specifications exist other than for the methods). However, formally it is not prohibited to mix this kind of transition with transitions with explicit actions (as it does not seem worth the effort to prohibit this, and there may be some applications that might benefit from 'mixing'). Figure 2-27 Example of a Protocol State Machine for a Class ‘Account’. Open Closedclose() withdraw(amount) [amount <= balance+overdraft] deposit (amount) 2-166 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.12.5.2 Example: Modeling Class Behavior In the software that is implemented as a result of a state modeling design, the state machine may or may not be actually visible in the (generated or hand-crafted) code. The state machine will not be visible if there is some kind of run-time system that supports state machine behavior. In the more general case, however, the software code will contain specific statements that implement the state machine behavior. A C++ example is shown below: class bankAccount { private: int balance; public: void deposit (amount) { if (balance > 0) balance = balance + amount’ // no change else balance = balance + amount - 1; // transaction fee } void withdrawal (amount) { if (balance>0) balance = balance - amount; } } In the above example, the class has an abstract state manifested by the balance attribute, controlling the behavior of the class. This is modeled by the state machine in Figure 2-28. Figure 2-28 State Machine for Modeling Class Behavior 2.12.5.3 Example: State machine refinement Note – The following discussion provides some potentially useful heuristics on how state machines can be refined. These techniques are all based on practical experience. However, readers are reminded that this topic is still the subject of research, and that it is likely that other approaches may be defined either now or in the future. credit debit withdrawal deposit/balance +=amount deposit [amount>-balance]/ balance+=amount-1 else/balance -= amount else/balance += amoun t-1 [amount>balance]/ balance -= amount March 2003 OMG-Unified Modeling Language, v1.5 2-167 2 UML Semantics Since state machines describe behaviors of generalizable elements, primarily classes, state machine refinement is used capture the relationships between the corresponding state machines. State machines use refinement in three different mappings, specified by the mapping attribute of the refinement meta-class. The mappings are refinement, substitution, and deletion. To illustrate state machine refinement, consider the following example where one state machine attached to a class denoted ‘Supplier,’ is refined by another state machine attached to a class denoted as ‘Client.’ Figure 2-29 State Machine Refinement Example In the example above, the client state (Sa(new)) in the subclass substitutes the simple substate (Sa1) by a composite substate (Sa1(new)). This new composite substate has a component substate (Sa11). Furthermore, the new version of Sa1 deletes the substate Sa2 and also adds a new substate Sa4. Substate Sa3 is inherited and is therefore common to both versions of Sa. For clarity, we have used a gray shading to identify components that have been inherited from the original. (This is for illustration purposes and is not intended as a notational recommendation.) It is important to note that state machine refinement as defined here does not specify or favor any specific policy of state machine refinement. Instead, it simply provides a flexible mechanism that allows subtyping, (behavioral compatibility), inheritance (implementation reuse), or general refinement policies. We provide a brief discussion of potentially useful policies that can be implemented with the state machine refinement mechanism. Subtyping The refinement policy for subtyping is based on the rationale that the subtype preserves the pre/post condition relationships of applying events/operations on the type, as Supplier (refined) Client (refined) Sa Sa (new) Sa1 Sa2 Sa3 - Sa1 refined - Sa2 deleted - Sa4 added into composite Sa1 (new) Sa11 Sa4 Sa3 2-168 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics specified by the state machine. The pre/post conditions are realized by the states, and the relationships are realized by the transitions. Preserving pre/post conditions guarantee the substitutability principle. States and transitions are only added, not deleted. Refinement is interpreted as follows: • A refined state has the same outgoing transitions, but may add others, and a different set of incoming transitions. It may have a bigger set of substates, and it may change its concurrency property from false to true. • A refined transition may go to a new target state which is a substate of the state specified in the base class. This comes to guarantee the post condition specified by the base class. • A refined guard has the same guard condition, but may add disjunctions. This guarantees that pre-conditions are weakened rather than strengthened. • A refined procedure contains the same actions (in the same sequence), but may have additional actions. The added actions should not hinder the invariant represented by the target state of the transition. Strict Inheritance The rationale behind this policy is to encourage reuse of implementation rather than preserving behavior. Since most implementation environment utilize strict inheritance (i.e. features can be replaced or added, but not deleted), the inheritance policy follows this line by disabling refinements which may lead to non-strict inheritance once the state machine is implemented. States and transitions can be added. Refinement is interpreted as follows: • A refined state has some of the same incoming transitions (i.e., drop some, add some) but a greater or bigger set of outgoing transitions. It may have more substates, and may change its concurrency attribute. • A refined transition may go to a new target state but should have the same source. • A refined guard may have a different guard condition. • A refined procedure contains some of the same actions (in the same sequence), and may have additional actions. General Refinement In this most general case, states and transitions can be added and deleted (i.e., ‘null’ refinements). Refinement is interpreted without constraints (i.e., there are no formal requirements on the properties and relationships of the refined state machine element and the refining element): • A refined state may have different outgoing and incoming transitions (i.e., drop all, add some). • A refined transition may leave from a different source and go to a new target state. • A refined guard has may have a different guard condition. March 2003 OMG-Unified Modeling Language, v1.5 2-169 2 UML Semantics • A refined procedure need not contain the same actions (or it may change their sequence), and may have additional actions. The refinement of the composite state in the example above is an illustration of general refinement. It should be noted that if a type has multiple supertype relationships in the structural model, then the default state machine for the type consists of all the state machines of its supertypes as orthogonal state machine regions. This may be explicitly overridden through refinement if required. 2.12.5.4 Comparison to classical statecharts The major difference between classical (Harel) statecharts and object state machines result from the external context of the state machine. Object state machines, such as ROOMcharts, primarily come to represent behavior of a type. Classical statechart specify behaviors of processes. The following list of differences result from the above rationale: • Events carry parameters, rather than being primitive signals. • Call events (operation triggers) are supported to model behaviors of types. • Event conjunction is not supported, and the semantics is given in respect to a single event dispatch, to better match the type context as opposed to a general system context. • Classical statecharts have an elaborated set of predefined actions, conditions and events which are not mandated by object state machines, such as entered(s), exited(s), true(condition), tr!(c) (make true), fs!(c). • Operations are not broadcast but can be directed to an object-set. • The notion of activities (processes) does not exist in object state machines. Therefore all predefined actions and events that deal with activities are not supported, as well as the relationships between states and activities. • Transition compositions are constrained for practical reasons. In classical statecharts any composition of pseudostates, simple transitions, guards and labels is allowed. • Object state machine support the notion of synchronous communication between state machines. • Actions on transitions are executed in their given order. • Classical statecharts do not support dynamic choice points. • Classical statecharts are based on the zero-time assumption, meaning transitions take zero time to execute. The whole system execution is based on synchronous steps where each step produces new events that will be processed at the next step. In object-oriented state machines, these assumptions are relaxed and replaced with these of software execution model, based on threads of execution and that execution of actions may take time. antics. 2-170 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.13 Activity Graphs 2.13.1 Overview The Activity Graphs package defines an extended view of the State Machine package. State machines and activity graphs are both essentially state transition systems, and share many metamodel elements. This section describes the concepts in the State Machine package that are specific to activity graphs. It should be noted that the activity graphs extension has few semantics of its own. It should be understood in the context of the State Machine package, including its dependencies on the Foundation package and the Common Behavior package. An activity graph is a special case of a state machine that is used to model processes involving one or more classifiers. Its primary focus is on the sequence and conditions for the actions that are taken, rather than on which classifiers perform those actions. Most of the states in such a graph are action states that represent atomic actions (i.e., states that invoke actions and then wait for their completion). Transitions into action states are triggered by events, which can be • the completion of a previous action state (completion events), • the availability of an object in a certain state, • the occurrence of a signal, or • the satisfaction of some condition. By defining a small set of additional subtypes to the basic state machine concepts, the well-formedness of activity graphs can be defined formally, and subsequently mapped to the dynamic semantics of state machines. In addition, the activity specific subtypes eliminate ambiguities that might otherwise arise in the interchange of activity graphs between tools. 2.13.2 Abstract Syntax The abstract syntax for activity graphs is expressed in graphic notation in Figure 2-30 on page 2-171. March 2003 OMG-Unified Modeling Language, v1.5 2-171 2 UML Semantics Figure 2-30 Activity Graphs 2.13.2.1 ActionState An action state represents the execution of an atomic action, typically the invocation of an operation. CallState ActionState isDynamic : Boolean dynamicArguments : ArgListsExpression dynamicMultiplicity : Multiplicity SimpleState ( from State Machi nes) SubactivityState isDynamic : Boolean dynamicArguments : ArgListsExpression dynamicMultiplicity : Multiplicity SubmachineState (from State Machines) CompositeState isConcurrent : Boolean ActivityGraph Partition 1 0..*1 +partition 0..* ModelElement (from Core) * * +contents* * StateMachine (from State Machines) 0..1* +context 0..1 +behavior * State (from State Machi nes) 0..1 1 0..1 +top 1 ClassifierInState 0..* 1..* 0..* +inState 1..* Parameter (from Core) Classifier (from Core) 1 * +type1 * ObjectFlowState isSynch : Boolean * * +parameter * +state * 1* +type 1* 2-172 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics An action state is a simple state with an entry action whose only exit transition is triggered by the implicit event of completing the execution of the entry action. The state therefore corresponds to the execution of the entry action itself and the outgoing transition is activated as soon as the action has completed its execution. An ActionState may perform more than one action as part of its entry action. An action state may not have an exit action, do activity, or internal transitions. Attributes Associations 2.13.2.2 ActivityGraph An activity graph is a special case of a state machine that defines a computational process in terms of the control-flow and object-flow among its constituent activities. It does not extend the semantics of state machines in a major way but it does define shorthand forms that are convenient for modeling control-flow and object-flow in organizational processes. The primary purpose of activity graphs is to describe the states of an activity or process involving one or more classifiers. Activity graphs can be attached to packages, classifiers (including use cases) and behavioral features. As in any state machine, if an outgoing transition is not explicitly triggered by an event then it is implicitly triggered by the completion of the contained actions. A subactivity state represents a nested activity that has some duration and internally consists of a set of actions or more subactivities. That is, a subactivity state is a “hierarchical action” with an embedded activity subgraph that ultimately resolves to individual actions. Junctions, forks, joins, and synchs may be included to model decisions and concurrent activity. Activity graphs include the concept of Partitions to organize states according to various criteria, such as the real-world organization responsible for their performance. dynamicArguments An ArgListsExpression that determines at runtime the number of parallel executions of the actions of the state. The value must be a set of lists of objects, each list serving as arguments for one execution. This attribute is ignored if the isDynamic attribute is false. dynamicMultiplicity A Multiplicity limiting the number of parallel executions of the actions of state. This attribute is ignored if the isDynamic attribute is false. isDynamic A boolean value specifying whether the state's actions might be executed concurrently. It is used in conjunction with the dynamicArguments attribute. entry (Inherited from State) Specifies the invoked actions. March 2003 OMG-Unified Modeling Language, v1.5 2-173 2 UML Semantics Activity graphing can be applied to organizational modeling for business process engineering and workflow modeling. In this context, events often originate from inside the system, such as the finishing of a task, but also from outside the system, such as a customer call. Activity graphs can also be applied to system modeling to specify the dynamics of operations and system level processes when a full interaction model is not needed. Associations 2.13.2.3 CallState A call state is an action state that calls a single operation. It is useful in object flow modeling to reduce notational ambiguity over which action is taking input or providing output. 2.13.2.4 ClassifierInState A classifier-in-state characterizes instances of a given classifier that are in a particular state or states. In an activity graph, it may be used to specify input and/or output to an action through an object flow state. ClassifierInState is a child of Classifier and may be used in static structural models and collaborations (e.g., it can be used to show associations that are only relevant when objects of a class are in a given state). Associations 2.13.2.5 ObjectFlowState An object flow state defines an object flow between actions in an activity graph. An instance of a particular classifier, possibly in a particular state, is available when an object flow state is occupied. The generation of an object by an action in an action state may be modeled by an object flow state that is triggered by the completion of the action state. The use of the object in a subsequent action state may be modeled by connecting the output transition of the object flow state as an input transition to the action state. Generally each action places the object in a different state that is modeled as a distinct object flow state. partition A set of Partitions each of which contains some of the model elements of the model. type Designates a classifier for the ClassifierInState to characterize the instances of. inState Designates a state that characterizes instances of the classifier of the ClassifierInState. The state must be a valid state of the corresponding classifier. This may have multiple states when referring to an object in orthogonal states. 2-174 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes Associations Stereotypes 2.13.2.6 Partition A partition is a mechanism for dividing the states of an activity graph into groups. Partitions often correspond to organizational units in a business model. They may be used to allocate characteristics or resources among the states of an activity graph. It should be noted that Partitions do not impact the dynamic semantics of the model but they help to allocate properties and actions for various purposes. Associations 2.13.2.7 SubactivityState A subactivity state represents the execution of a non-atomic sequence of steps that has some duration (i.e., internally it consists of a set of actions and possibly waiting for events). That is, a subactivity state is a “hierarchical action,” where an associated subactivity graph is executed. A subactivity state is a submachine state that executes a nested activity graph. When an input transition to the subactivity state is triggered, execution begins with the nested activity graph. The outgoing transitions of a subactivity state are enabled when the final state of the nested activity graph is reached (i.e., when it completes its execution), or when the trigger events occur on the transitions. The semantics of a subactivity state are equivalent to the model obtained by statically substituting the contents of the nested graph as a composite state replacing the subactivity state. isSynch A boolean value indicating whether an object flow state is used as a synch state. type Designates a classifier that specifies the classifier of the object. It may be a classifier-in-state to specify the state and classifier of the object. parameter Designates parameters which provide the object as output or take it as input. «signalflow» Class Signalflow is a stereotype of ObjectFlowState with a Signal as its type. contents Specifies the states that belong to the partition. They need not constitute a nested region. March 2003 OMG-Unified Modeling Language, v1.5 2-175 2 UML Semantics Attributes Associations 2.13.2.8 Transition Transition is inherited from state machines. Tagged Values 2.13.3 Well-formedness Rules ActivityGraph [1] An ActivityGraph specifies the dynamics of (i) a Package, or (ii) a Classifier (including UseCase), or dynamicArguments An ArgListsExpression that determines the number of parallel executions of the submachines of the state. The value must be a set of lists of objects, each list serving as arguments for one execution. This attribute is ignored if the isDynamic attribute is false. dynamicMultiplicity A Multiplicity limiting the number of parallel executions of the actions of state. This attribute is ignored if the isDynamic attribute is false. isDynamic A boolean value specifying whether the state's subactivity might be executed concurrently. It is used in conjunction with the dynamicArguments attribute. submachine (Inherited from SubmachineState) This designates an activity graph that is conceptually nested within the subactivity state. The subactivity state is conceptually equivalent to a composite state whose contents are the states of the nested activity graph. The nested activity graph must have an initial state and a final state. usage Association Usage applies only to transitions leading into or out of an object flow state. It has a value of uses or modifies. A value of uses indicates that the action of the state at the other end of the transition from the object flow state uses but does not modify the object represented by the object flow state. A value of modifies indicates that the action of the state at the other end of the transition from the object flow state modifies and may use the object represented by the object flow state. 2-176 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics (iii) a BehavioralFeature. (self.context.oclIsTypeOf(Package) xor self.context.oclIsKindOf(Classifier) xor self.context.oclIsKindOf(BehavioralFeature)) 2.13.3.1 ActionState 2.13.3.2 CallState 2.13.3.3 ClassifierInState [1] An action state has a non-empty entry action. self.entry->size > 0 [2] An action state does not have an internal transition, exit action, or a do activity. self.internalTransition->size = 0 and self.exit->size = 0 and self.doActivity->size = 0 [3] Transitions originating from an action state have no trigger event. self.outgoing->forAll(t | t.trigger->size = 0) [1] The entry action of a call state is a single call action. let a : Set = self.entry.action.allNestedActions in a->size() = 1 and a->asSequence()->first().oclIsKindOf(CallOperationAction) [1] Classifiers-in-state have no namespace contents. self.allContents->size = 0 March 2003 OMG-Unified Modeling Language, v1.5 2-177 2 UML Semantics 2.13.3.4 ObjectFlowState Additional operations [1] Parameters of an object flow state must have a type and direction compatible with classifier or classifier-in-state of the object flow state. let ofstype : Classifier = (if self.type.IsKindOf(ClassifierInState) then self.type.type else self.type); self.parameter->forAll(parameter | parameter.type = ofstype or (parameter.kind = #in and ofstype.allSupertypes->includes(type)) or ((parameter.kind = #out or parameter.kind = #return) and type.allSupertypes->includes(ofstype)) or (parameter.kind = #inout and ( ofstype.allSupertypes->includes(type) or type.allSupertypes->includes(ofstype)))) [2] Downstream states have entry actions that accept input conforming to the type of the classifier or classifier-in-state. The entry actions use the input parameters of the object flow state. Valid downstream states are calculated by traversing outgoing transitions transitively, skipping pseudo states, and entering and exiting subactivity states, looking for regular states. If the object flow state has no parameters, then the target of downstream actions must conform to the type of the classifier or classifier-in-state. self.allNextLeafStates.size > 0 and self.allNextLeafStates->forAll(s | self.isInputAction(s.entry)) [3] Upstream states have entry actions that provide output or return values conforming to the type of the classifier or classifier-in-state. The entry actions use the output or return parameters of the object flow state. Valid upstream states are calculated by traversing incoming transitions transitively, skipping pseudo states, entering and exiting subactivity states, looking for regular states. self.allPreviousLeafStates.size > 0 and self.allPreviousLeafStates->forAll(s | self.isOutputAction(s.entry)) [1] The operation allNextLeafStates results in the set of states immediately downstream of the object flow state that have the next actions that will be executed. [2] The operation allPreviousLeafStates results in the set of states immediately upstream of the object flow state that have the next actions that were last executed. [3] The operation isInputAction takes a procedure as input and results in a boolean telling whether it has an argument compatible with the object flow state. [4] The operation isOutputAction takes a procedure as input and results in a boolean telling whether it has a result compatible with the object flow state. 2-178 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.13.3.5 PseudoState 2.13.3.6 SubactivityState 2.13.4 Detailed Semantics 2.13.4.1 ActivityGraph The dynamic semantics of activity graphs can be expressed in terms of state machines. This means that the process structure of activities formally must be equivalent to orthogonal regions (in composite states). That is, transitions crossing between parallel paths (or threads) are not allowed, except for transitions used with synch states. As such, an activity specification that contains ‘unconstrained parallelism’ as is used in general activity graphs is considered ‘incomplete’ in terms of UML. All events that are not relevant in a state must be deferred so they are consumed when they become relevant. This is facilitated by the general deferral mechanism of state machines. 2.13.4.2 ActionState As soon as the incoming transition of an ActionState is triggered, its entry action starts executing. Once the entry action has finished executing, the action is considered completed. When the action is complete then the outgoing transition is enabled. [1] In activity graphs, transitions incoming to (and outgoing from) join and fork pseudostates have as sources (targets) any state vertex. That is, joins and forks are syntactically not restricted to be used in combination with composite states, as is the case in state machines. self.stateMachine.oclIsTypeOf(ActivityGraph) implies ((self.kind = #join or self.kind = #fork) implies (self.incoming->forAll(t | t.source.oclIsKindOf(State) or source.oclIsTypeOf(PseudoState)) and (self.outgoing->forAll(t | t.source.oclIsKindOf(State) or source.oclIsTypeOf(PseudoState))))) [2] All of the paths leaving a fork must eventually merge in a subsequent join in the model. Furthermore, multiple layers of forks and joins must be well nested, with the exception of forks and joins leading to or from synch state. Therefore the concurrency structure of an activity graph is in fact equally restrictive as that of an ordinary state machine, even though the composite states need not be explicit. [1] A subactivity state is a submachine state that is linked to an activity graph. self.submachine.oclIsKindOf(ActivityGraph) March 2003 OMG-Unified Modeling Language, v1.5 2-179 2 UML Semantics The isDynamic attribute of an action state determines whether multiple invocations of state might be executed concurrently, depending on runtime information. This means that the normal activities of an action state, namely its actions, may execute multiple times in parallel. If isDynamic is true, then the dynamicArguments attribute is evaluated at the time the state is entered. The size of the resulting set determines the number of parallel executions of the state. Each element of the set is a list, which is used as arguments for an execution. These arguments can be referred to within actions (e.g. by “object[i]” denoting the ith object in a list). If the isDynamic attribute is false, dynamicArguments is ignored. If the dynamicArguments expression evaluates to the empty set, then the state behaves as if it had no actions. It is an error if the dynamicArguments expression evaluates to a set with fewer or more elements than the number allowed by the dynamicMultiplicity attribute. The behavior is not defined in this case. Dynamic states may be nested. In this case, you can't access the outer set of arguments in the inner nesting. If this should be necessary, arguments can be passed explicitly from the outer to the inner dynamic state. 2.13.4.3 ObjectFlowState The activation of an object flow state signifies that an instance of the associated classifier is available, perhaps in a specified state (i.e., a state change has occurred as a result of a previous operation). This may enable a subsequent action state that requires the instance as input. As with all states in activity graphs, if the object flow state leads into a join pseudostate, then the object flow state remains activated until the other predecessors of the join have completed. Unless there is an explicit ‘fork’ that creates orthogonal object states, only one of an object flow state’s outgoing transitions will fire as determined by the guards of the transitions. The invocation of the action state may result in a state change of the object, resulting in a new object flow state. An object flow state may specify the parameter of an operation that provides the flowing object as output, and the parameter of an operation that takes the flowing object as input. The operations must be called in actions of states immediately preceding and succeeding the object flow state, respectively, although pseudostates, final states, synch states, and stub states may be interposed between the object flow state and the acting state. For example, an object flow state may transition to a subactivity state, which means at runtime the object is passed as input to the first state after the initial state of the subactivity graph. If no parameter is specified to take the flowing object as input, then it is used as an action target instead. Call actions are particularly suited to be used in conjunction with this technique because they invoke exactly one operation. Object flow states may be used as synch states, indicated by the isSynch attribute being set to true. In this case, outgoing transitions can fire only if an object has arrived on the incoming transitions. Instead of a count, the state keeps a list of objects that arrive on the incoming transitions. These objects are pulled from the list as outgoing transitions 2-180 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics are fired. No outgoing transitions can fire if the list is empty. All objects in the list conform to the classifier and state specified by the object flow state. The list is not bounded as the count may be in synch states. For applications requiring that actions or activities bring about an event as their result, use an object flow state with a signal as a classifier. This means the action or activity must return an instance of a signal. For multiple resulting events, transition the action or activity to a fork, and target the fork transitions at multiple object flow states. 2.13.4.4 SubactivityState The isDynamic, dynamicArguments, and dynamicMultiplicity attributes of a subactivity state have a similar meaning to the same attributes of action states. They provide for executing the submachine of the subactivity state multiple times in parallel. See semantics of ActionState. 2.13.4.5 Transition In activity graphs, transitions outgoing from forks may have guards. This means the region initiated by a fork transition might not start, and therefore not be required to complete at the corresponding join. Forks and joins must be well-nested in the model to use this feature (see rule #2 for PseudoState in Activity Graphs). The following mapping shows the state machine meaning for such an activity graph: Figure 2-31 State Machine - Activity Graph If a conditional region synchronizes with another region using a synch state, and the condition fails, then these synch states have their counts set to infinity to prevent other regions from deadlocking. [guard] Conditional Activity Model Thread Activity Model Thread 1 [guard][~guard] Conditional State Machine Fragment Activity diagram notation Equivalent state machine notation Thread 1 March 2003 OMG-Unified Modeling Language, v1.5 2-181 2 UML Semantics 2.13.5 Notes Object flow states in activity graphs are a specialization of the general dataflow aspect of process models. Object-flow activity graphs extend the semantics of standard dataflow relationships in three areas: 1. The operations in action states in activity graphs are operations of classifiers or types (e.g., ‘Trade’ or ‘OrderEntryClerk’). They are not hierarchical ‘functions’ operating on a dataflow. 2. The ‘contents’ of object flow states are typed. They are not unstructured data definitions as in data stores. 3. The state of the object flowing as input and output between operations may be defined explicitly. The event of the availability of an object in a specific state may form a trigger for the operation that requires the object as input. Object flow states are not necessarily stateless as are data stores. 2.14 Actions See “Part 5 - Actions” on page 2-199. Part 4 - General Mechanisms This section defines the mechanisms of general applicability to models. This version of UML contains one general mechanisms package, Model Management. The Model Management package specifies how model elements are organized into models, packages, subsystems, and UML profiles. 2.15 Model Management 2.15.1 Overview The Model Management package is dependent on the Foundation package. It defines Model, Package, and Subsystem, which all serve as grouping units for other ModelElements. Models are used to capture different views of a physical system. Packages are used within a Model to group ModelElements. A Subsystem represents a behavioral unit in the physical system. UML Profiles are packages dedicated to group UML extensions. In this section it is necessary to clearly distinguish between the physical system being modeled; that is, the subject of the model and the model element that represent the physical system in the model. For this reason, we consistently use the term physical system when we want to indicate the former, and the term (top-level) subsystem when we want to indicate the latter. An example of a physical system is a credit card service, which includes software, hardware, and wetware (people). The UML model for this physical system might consist of a top-level subsystem called CreditCardService, which is decomposed into subsystems for Authorization, Credit, and Billing. An 2-182 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics analogy with the construction of houses would be that the house would correspond to the physical system, while a blueprint would correspond to a model, and an element used in a blueprint would correspond to a model element. The following sections describe the abstract syntax, well-formedness rules, and semantics of the Model Management package. 2.15.2 Abstract Syntax The abstract syntax for the Model Management package is expressed in graphic notation in Figure 2-32. Figure 2-32 Model Management 2.15.2.1 Dependency (as extended) Dependencies have specific extensions for modeling UML profiles. ElementImport visibility : VisibilityKind alias : Name isSpecification : Boolean GeneralizableElement (from Core) Subsystem isInstantiable : Boolean Model ElementOwnership (from Core) Namespace (from Core) Package ModelElement (from Core) * 0..1 +ownedElement * +namespace 0..1 * * * +importedElement * Classifier (from Core) March 2003 OMG-Unified Modeling Language, v1.5 2-183 2 UML Semantics Stereotypes 2.15.2.2 ElementImport An element import defines the visibility and alias of a model element included in the namespace within a package, as a result of the package importing another package. In the metamodel, an ElementImport reifies the relationship between a Package and an imported ModelElement. It allows redefinition of the name and the visibility for the imported ModelElement; that is, the ModelElement may be given another name (an alias) and/or a new visibility to be used within the importing Package. The default is no alias (the original name will be used) and private visibility relative to the importing Package. Attributes 2.15.2.3 Model A model captures a view of a physical system. It is an abstraction of the physical system, with a certain purpose. This purpose determines what is to be included in the model and what is irrelevant. Thus the model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the appropriate level of detail. «modelLibrary» Class This dependency means that the supplier package is being used as a model library associated with a profile. The client is a package that is stereotyped as a profile and the supplier is a non-profile package that contains shared model elements, such as classes and data types. «appliedProfile» Class This dependency is used to indicate which profiles are applicable to a package. Typically, the client is an ordinary package or a model (but could be any other kind of package), while the supplier is a profile package. This means that the profile applies transitively to the model elements contained in the client package, including the client package itself. alias The alias defines a local name of the imported ModelElement, to be used within the Package. isSpecification Specifies whether the ownedElement is part of the specification for the containing namespace (in cases where specification is distinguished from the realization). Otherwise the ownedElement is part of the realization. In cases in which the distinction is not made, the value is false by default. visibility An imported ModelElement is either public, protected, or private relative to the importing Package. 2-184 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics In the metamodel, Model is a subclass of Package. It contains a containment hierarchy of ModelElements that together describe the physical system. A Model also contains a set of ModelElements that represents the environment of the system, typically Actors, together with their interrelationships, such as Dependencies, Generalizations, and Constraints. Different Models can be defined for the same physical system, where each model represents a view of the physical system defined by its purpose and abstraction level (for example, an analysis model, a design model, an implementation model). Typically different models are complementary and defined from the perspectives (viewpoints) of different system stakeholders. For example, a use-case model may be defined from the viewpoint of a business analyst stakeholder. Each Model is a complete description of the physical system. When Models are nested, the container Model represents the comprehensive view of the physical system given by the different views defined by the contained Models. Stereotypes 2.15.2.4 Package A package is a grouping of model elements. In the metamodel, Package is a subclass of Namespace and GeneralizableElement. A Package contains ModelElements like Packages, Classifiers, and Associations. A Package may also contain Constraints and Dependencies between ModelElements of the Package. Each ModelElement of a Package has a visibility relative to the Package stating if the ModelElement is available to ModelElements in other Packages with a Permission («access» or «import») or Generalization relationship to the Package. An «access» or «import» Permission from one Package to another allows public ModelElements in the target Package to be referenced by ModelElements in the source Package. They differ in that all public ModelElements in imported Packages are added to the Namespace within the importing Package, whereas the Namespace within an accessing Package is not affected at all. The ModelElements available in a Package are those in the contents of the Namespace within the Package, which consists of owned and imported ModelElements, together with public ModelElements in accessed Packages. «systemModel» Class A systemModel is a stereotyped model that contains a collection of models of the same physical system. A systemModel also contains all relationships and constraints between model elements contained in different models. «metamodel» Class A metamodel is a stereotyped model denoting that the model is an abstraction of another model; that is, it is a model of a model. Hence, if M2 is a model of the model M1, then M2 is a metamodel of M1. It follows then that classes in M1 are instances of metaclasses in M2. The stereotype can be recursively applied, as in the case of a 4-layer metamodel architecture. March 2003 OMG-Unified Modeling Language, v1.5 2-185 2 UML Semantics Associations Stereotypes importedElement The namespace defined by a package is extended by model elements in other, imported packages. «facade» Class A facade is a stereotyped package that contains references to model elements owned by another package. It is used to provide a ‘public view’ of some of the contents of a package. A facade does not contain any model elements of its own. «framework» Class A framework is a stereotyped package that contains model elements that specify a reusable architecture for all or part of a system. Frameworks typically include classes, patterns, or templates. When frameworks are specialized for an application domain, they are sometimes referred to as application frameworks. «modelLibrary» Class A model library is a stereotyped package that contains model elements that are intended to be reused by other packages. A model library differs from a profile in that a model library does not extend the metamodel using stereotypes and tagged definitions. A model library is analogous to a class library in some programming languages. «profile» Class A profile is a stereotyped package that contains model elements that have been customized for a specific domain or purpose using extension mechanisms, such as stereotypes, tagged definitions, and constraints. A profile may also specify model libraries on which it depends and the metamodel subset that it extends. (The latter is specified via an applicableSubset tag definition.) «stub» Class A stub is a stereotyped package that represents only the public parts of another package. «topLevel» Class TopLevel is a stereotyped package that denotes the highest level package in a containment hierarchy. The topLevel stereotype defines the outer limit for looking up names, as namespaces “see” outwards. A topLevel subsystem is the top of a subsystem containment hierarchy; that is, it is the model element that represents the boundary of the entire physical system being modeled. 2-186 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Tag Definitions 2.15.2.5 Subsystem A subsystem is a grouping of model elements that represents a behavioral unit in a physical system. A subsystem offers interfaces and has operations. In addition, the model elements of a subsystem are partitioned into specification and realization elements, where the former, together with the operations of the subsystem, are realized by the latter. In the metamodel, Subsystem is a subclass of both Package and Classifier. As such it may have a set of Features, which are constrained to be Operations and Receptions, and Associations. The contents of a Subsystem are divided into two subsets: specification elements and realization elements. The former subset provides, together with the Operations of the Subsystem, a specification of the behavior contained in the Subsystem, while the ModelElements in the latter subset jointly provide a realization of the specification. Any kind of ModelElement can be a specification element or a realization element. The relationships between the specification elements and the realization elements can be defined in different ways (for example, with Collaborations or «realize» dependencies). Attributes 2.15.3 Well-formedness Rules The following well-formedness rules apply to the Model Management package. {applicableSubset} This tag definition, which only applies to profile packages, lists the metaelements that are used by the associated profile. The value associated with this tag definition is a set of strings, where each string represents the name of an applicable metaelement. Note that the use of applicable subset does not necessarily exclude the use of any metaelements, but clearly identifies which ones are referenced from the associated profile. Further note that the tag definition applies only to the immediately associated profile. If a profile combines several other profiles using import or generalizations, the applicable subset only applies to the immediately associated profile. The absence of an applicable subset tag definition means that the whole UML metamodel is applicable. isInstantiable States whether a Subsystem is instantiable or not. If false, the Subsystem represents a unique part of the physical system; otherwise, there may be several system parts with the same definition. March 2003 OMG-Unified Modeling Language, v1.5 2-187 2 UML Semantics 2.15.3.1 ElementImport No extra well-formedness rules. 2.15.3.2 Model No extra well-formedness rules. 2.15.3.3 Package [1] No imported element (excluding Association) may have the same name or alias as any element owned by the Package or one of its supertypes. self.allImportedElements->reject( re | re.oclIsKindOf(Association) )->forAll( re | (re.elementImport.alias <> ’’ implies not (self.allContents - self.allImportedElements)-> reject( ve | ve.oclIsKindOf (Association) )->exists ( ve | ve.name = re.elementImport.alias)) and (re.elementImport.alias = ’’ implies not (self.allContents - self.allImportedElements)-> reject ( ve | ve.oclIsKindOf (Association) )->exists ( ve | ve.name = re.name) ) ) [2] Imported elements (excluding Association) may not have the same name or alias. self.allImportedElements->reject( re | not re.oclIsKindOf (Association) )->forAll( r1, r2 | (r1.elementImport.alias <> ’’ and r2.elementImport.alias <> ’’ and r1.elementImport.alias = r2.elementImport.alias implies r1 = r2) and (r1.elementImport.alias = ’’ and r2.elementImport.alias = ’’ and r1.name = r2.name implies r1 = r2) and (r1.elementImport.alias <> ’’ and r2.elementImport.alias = ’’ implies r1.elementImport.alias <> r2.name)) 2-188 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics [3] No imported element (Association) may have the same name or alias combined with the same set of associated Classifiers as any Association owned by the Package or one of its supertypes. self.allImportedElements->select( re | re.oclIsKindOf(Association) )->forAll( re | (re.elementImport.alias <> ’’ implies not (self.allContents - self.allImportedElements)-> select( ve | ve.oclIsKindOf(Association) )->exists( ve : Association | ve.name = re.elementImport.alias and ve.connection->size = re.connection->size and Sequence {1..re.connection->size}->forAll( i | re.connection->at(i).participant = ve.connection->at(i).participant ) ) ) and (re.elementImport.alias = ’’ implies not (self.allContents - self.allImportedElements)-> select( ve | not ve.oclIsKindOf(Association) )->exists( ve : Association | ve.name = re.name and ve.connection->size = re.connection->size and Sequence {1..re.connection->size}->forAll( i | re.connection->at(i).participant = ve.connection->at(i).participant ) ) ) ) [4] Imported elements (Association) may not have the same name or alias combined with the same set of associated Classifiers. March 2003 OMG-Unified Modeling Language, v1.5 2-189 2 UML Semantics self.allImportedElements->select ( re | re.oclIsKindOf (Association) )->forAll ( r1, r2 : Association | (r1.connection->size = r2.connection->size and Sequence {1..r1.connection->size}->forAll ( i | r1.connection->at (i).participant = r2.connection->at (i).participant and r1.elementImport.alias <> ’’ and r2.elementImport.alias <> ’’ and r1.elementImport.alias = r2.elementImport.alias implies r1 = r2)) and (r1.connection->size = r2.connection->size and Sequence {1..r1.connection->size}->forAll ( i | r1.connection->at (i).participant = r2.connection->at (i).participant and r1.elementImport.alias = ’’ and r2.elementImport.alias = ’’ and r1.name = r2.name implies r1 = r2)) and (r1.connection->size = r2.connection->size and Sequence {1..r1.connection->size}->forAll ( i | r1.connection->at (i).participant = r2.connection->at (i).participant and r1.elementImport.alias <> ’’ and r2.elementImport.alias = ’’ implies r1.elementImport.alias <> r2.name))) [5] A Package may only own or reference Packages, Classifiers, Associations, Generalizations, Dependencies, Comments, Constraints, Collaborations, StateMachines, Stereotypes, and TaggedValues. self.contents->forAll ( c | c.oclIsKindOf(Package) or c.oclIsKindOf(Classifier) or c.oclIsKindOf(Association or c.oclIsKindOf(Generalization) or c.oclIsKindOf(Dependency) or c.oclIsKindOf(Comment) or c.oclIsKindOf(Constraint) or c.oclIsKindOf(Collaboration or c.oclIsKindOf(StateMachine) or c.oclIsKindOf(TaggedValue) or c.oclIsKindOf(Stereotype)) 2-190 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Additional Operations 2.15.3.4 Profile 2.15.3.5 Subsystem [1] The operation contents results in a Set containing the ModelElements owned by or imported by the Package. contents : Set(ModelElement) contents = self.ownedElement->union(self.importedElement) [2] The operation allImportedElements results in a Set containing the ModelElements imported by the Package or one of its parents. allImportedElements : Set(ModelElement) allImportedElements = self.importedElement->union( self.parent.oclAsType(Package).allImportedElements->select( re | re.elementImport.visibility = #public or re.elementImport.visibility = #protected)) [3] The operation allContents results in a Set containing the ModelElements owned by or imported by the Package or one of its ancestors. allContents : Set(ModelElement); allContents = self.contents->union( self.parent.allContents->select(e | e.elementOwnership.visibility = #public or e.elementOwnership.visibility = #protected)) [1] The base classes of all stereotypes in a profile must be part of the applicable subset of this profile. self.applicableSubset-> includesAll(self.stereotypes->collect(baseClass)) [2] A profile package can only contain tag definitions, stereotypes, constraints and data types. self.contents->forAll(e | e.oclIsKindOf(Stereotype) or e.oclIsKindOf(Constraint) or e.oclIsKindOf(TagDefinition) or e.oclIsKindOf (DataType)) [1] For each Operation in an Interface offered by a Subsystem, the Subsystem itself or at least one contained specification element must have a matching Operation. self.specification.allOperations->forAll(interOp | self.allOperations->union (self.allSpecificationElements->select(specEl| specEl.oclIsKindOf(Classifier))->forAll(c| c.allOperations))->exists ( op | op.hasSameSignature(interOp) ) ) March 2003 OMG-Unified Modeling Language, v1.5 2-191 2 UML Semantics Additional Operations [2] For each Reception in an Interface offered by a Subsystem, the Subsystem itself or at least one contained specification element must have a matching Reception. let allReceptions : set(Reception) = self.allFeatures->select(f | f.oclIsKindOf(Reception)) in self.specification.allReceptions->forAll(interRec | self.allReceptions->union (self.allSpecificationElements->select(specEl| specEl.oclIsKindOf(Classifier))->forAll(c| c.allReceptions))->exists ( rec | rec.hasSameSignature(interRec) ) ) [3] The Features of a Subsystem may only be Operations or Receptions. self.feature->forAll(f | f.oclIsKindOf(Operation) or f.oclIsKindOf(Reception)) [4] A Subsystem may only own or reference Packages, Classes, DataTypes, Interfaces, UseCases, Actors, Subsystems, Signals, Associations, Generalizations, Dependencies, Constraints, Collaborations, StateMachines, and Stereotypes. self.contents->forAll ( c | c.oclIsKindOf(Package) or c.oclIsKindOf(Class) or c.oclIsKindOf(DataType) or c.oclIsKindOf(Interface) or c.oclIsKindOf(UseCase) or c.oclIsKindOf(Actor) or c.oclIsKindOf(Subsystem) or c.oclIsKindOf(Signal) or c.oclIsKindOf(Association) or c.oclIsKindOf(Generalization) or c.oclIsKindOf(Dependency) or c.oclIsKindOf(Constraint) or c.oclIsKindOf(Collaboration) or c.oclIsKindOf(StateMachine) or c.oclIsKindOf(Stereotype) ) [1] The operation allSpecificationElements results in a Set containing the Model Elements specifying the behavior of the Subsystem allSpecificationElements : Set(ModelElement) allSpecificationElements = self.allContents->select(c | c.elementOwnership.isSpecification) [2] The operation contents results in a Set containing the ModelElements owned by or imported by the Subsystem. contents : Set(ModelElement) contents = self.ownedElement->union(self.importedElement) 2-192 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.15.4 Semantics 2.15.4.1 Package Figure 2-33 Package illustration - shows Package and its environment in the metamodel by flattening the inheritance hierarchy. The purpose of the package construct is to provide a general grouping mechanism. A package cannot be instantiated, thus it has no runtime semantics. In fact, its only semantics is to define a namespace for its contents. The package construct can be used for organizing elements for any purpose; the criteria to use for grouping elements together into one package are not defined within UML. A package owns a set of model elements, with the implication that if the package is removed from the model, so are the elements owned by the package. Elements with names, such as classifiers, that are owned by the same package must have unique names within the package, although elements in different packages may have the same name. There may be relationships between elements contained in the same package, and between an element in one package and an element in a surrounding package at any level. In other words, elements “see” all the way out through nested levels of packages. (Note that a package with the stereotype «topLevel» defines the outer limit of this outward visibility.) Elements in peer packages, however, are encapsulated and are not a priori visible to each other. The same goes for elements in contained packages; that is, packages do not see “inwards.” There are two ways of making elements in other packages available: by importing/accessing these other packages, and by defining generalizations to them. An import dependency (a Permission dependency with the stereotype «import») from one package to another means that the first package imports all the elements with sufficient visibility in the second package. Imported elements are not owned by the package; however, they may be used in associations, generalizations, attribute types, and other relationships owned by the package. A package defines the visibility of its contained elements to be private, protected, or public. Private elements are not available at all outside the containing package. Protected elements are available only to packages with generalizations to the package owning the elements, and public elements are available also to importing and accessing packages. Note that the visibility mechanism does not restrict the availability of an element to peer elements in the same package. When an element is imported by a package it extends the namespace of that package. It is possible to give an imported element an alias to avoid name conflicts with the names of the other elements in the namespace, including other imported elements. The alias will then be the name of that element in the namespace; the element will not appear under both the alias and its original name. An imported element is by default * * ModelElement * Package * * * Generalization * * March 2003 OMG-Unified Modeling Language, v1.5 2-193 2 UML Semantics private to the importing package. It may, however, be given a more permissive visibility relative to the importing package; that is, the local visibility may be defined as protected or public. A package with an import dependency to another package imports all the public contents of the namespace defined by the supplier package, including elements of packages imported by the supplier package that are given public visibility in the supplier. The access dependency (a Permission dependency with the stereotype «access») is similar to the import dependency in that it makes elements in the supplier package available to the client package. However, in this case no elements in the supplier package are included in the namespace of the client. They are simply referred to by their full pathname when referenced in the accessing package. Clearly, they are not visible to packages in turn accessing or importing this package. A package can have generalizations to other packages. This means that the public and protected elements owned or imported by a package are also available to its children, and can be used in the same way as any element owned or imported by the children themselves. Elements made available to another package by the use of a generalization are referred to by the same name in the child as they are in the parent. Moreover, they have the same visibility in the child as they have in the parent package. Relationships between the ancestor package and other model elements are also inherited by the child package. A package can be used to define a framework, specifying a reusable architecture for all or part of a system. Frameworks may include reusable classes, patterns or templates. When frameworks are specialized for an application domain, they are sometimes referred to as application frameworks. 2.15.4.2 Profile A profile stereotype of Package contains one or more related extensions of standard UML semantics (refer to Section 2.6, “Extension Mechanisms,” on page 2-73). These are normally intended to customize UML for a particular domain or purpose. Profiles can contain stereotypes, tag definitions, and constraints. They can also contain data types that are used by tag definitions for informally declaring the types of the values that can be associated with tag definitions. In addition, a profile package can specify a related model library and identify a subset of the UML metamodel that is applicable for the profile. In principle, profiles merely refine the standard semantics of UML by adding further constraints and interpretations that capture domain-specific semantics and modeling patterns. They do not add any new fundamental concepts. Relationships between profiles A profile package can have the usual relationships with other packages such as generalization, import, and access. These have the usual semantics. They are useful to profile designers who may want to import elements from one profile into another, or to combine two or more profiles. However, care should be taken to combine these in a 2-194 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics consistent way. For example, extensions from different profiles may be incompatible and their respective constraints may contradict each other. In this revision of UML, no formal mechanisms are defined to verify that a combination of two or more profiles is mutually consistent. Profile generalization Generalization of profiles is a relationship between a profile and a more general profile. The more specific profile must be fully consistent with the more general profile; that is, it has all the same tag definitions, stereotypes, and constraints, and may add further refinements, which must not contradict its parent. Note that the subset of UML defined as applicable by a profile is not inherited by specializing profiles, whereas relationships to model libraries are. Access and import dependencies between profiles Profiles can have access and import dependencies with the usual semantics. This allows elements in one profile to access or use elements in the related profiles. An applied profiles dependency will allow a client package to use all stereotypes and tag definitions accessible by the supplier package. As in all other types of packages, a profile can own other profiles with standard semantics of ownership and accessibility. Applying a profile to a package A UML model can be based on a number of different UML profiles. The applicable profiles are identified by specially stereotyped «appliedProfile» dependencies from the UML model package to the appropriate profile packages. This declaration enables the UML model to access the stereotypes and tag definitions of these profiles. 2.15.4.3 Subsystem Figure 2-34 Subsystem illustration - shows Subsystem and its environment in the metamodel by flattening the inheritance hierarchy. The purpose of the subsystem construct is to provide a grouping mechanism for specifying a behavioral unit of a physical system. Apart from defining a namespace for its contents, a subsystem serves as a specification unit for the behavior of its contained model elements. The contents of a subsystem are defined in the same way as for a package, thus it consists of owned elements and imported elements, with unique names or aliases within the subsystem. The contents of a subsystem are divided into two subsets: 1) specification elements and 2) realization elements. The specification elements, together with the InterfaceBehavioralFeature * * Generalization *Subsystem ** * ModelElement * * SubsystemInstance March 2003 OMG-Unified Modeling Language, v1.5 2-195 2 UML Semantics operations and receptions of the subsystem, are used for giving an abstract specification of the behavior offered by the realization elements. The collection of realization elements model the interior of the behavioral unit of the physical system. Consequently, subsystems contained in the realization part represent subordinate subsystems; that is, subsystems at the level below in the containment hierarchy, hence owned by the current subsystem. The specification of a subsystem thus consists of the specification elements together with the subsystem’s features (operations and receptions). It specifies the behavior performed jointly by instances of classifiers in the realization subset, without revealing anything about the contents of this subset. The specification is typically made in terms of model elements such as use cases and/or operations, although other kinds of model elements like classes, interfaces, constraints, relationships between model elements, state machines may also be used. Use cases are used to specify complete sequences performed by the subsystem; that is, by instances of its contained classifiers interacting with its surroundings. Operations are suitable to represent simpler subsystem services that are used independently of each other; that is, not in any particular order. A subsystem has no behavior of its own. All behavior defined in the specification of the subsystem is jointly offered by the elements in the realization subset of the contents. In general, since subsystems are classifiers, they can appear anywhere a classifier is expected. It follows that, since the subsystem itself has no behavior of its own, the requirements posed on the subsystem in the context where it occurs are fulfilled by the realization of the subsystem. The correspondence between the specification and the realization of a subsystem can be specified in several ways, including collaborations and «realize» dependencies. A collaboration specifies how instances of the realization elements cooperate to jointly perform the behavior specified by a use case, an operation, etc. in the subsystem specification; that is, how the higher level of abstraction is transformed into the lower level of abstraction. A stimulus received by an instance of a use case (higher level of abstraction) corresponds to an instance conforming to one of the classifier roles in the collaboration receiving that stimulus (lower level of abstraction). This instance communicates with other instances conforming to other classifier roles in the collaboration, and together they perform the behavior specified by the use case. All stimuli that can be received and sent by instances of the use cases are also received and sent by the conforming instances, although at a lower level of abstraction. Similarly, application of an operation of the subsystem actually means that a stimulus is sent to a contained instance that performs a method. There are two ways of communicating with a subsystem, either by sending stimuli to the subsystem itself to be re-directed to the proper recipient inside the subsystem, or by sending stimuli directly to the recipient inside the subsystem. In the first case, an association is defined with the subsystem itself to enable stimuli sending. (In the abstract syntax, this is handled by a single subsystem instance being connected by links corresponding to this association, receiving stimuli sent to the subsystem, and re- directing them to instances within the subsystem instance. Hence the subsystem instance is the “runtime representative” of the subsystem. Note that this subsystem 2-196 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics instance still does not perform any of the behavior specified in the subsystem specification.) How stimuli sent to the subsystem are re-directed to internal instances is not defined but left as a semantic variation point. Communicating with a subsystem by sending stimuli directly to instances within the subsystem requires that the classifiers of these instances are available within the sender’s namespace so that they can be connected by associations. This can be achieved by import or access permissions. Importing and accessing subsystems is done in the same way as with packages, using the visibility property to define whether elements are public, protected, or private to the subsystem. Both the specification part and the realization part of a subsystem may include imported elements. A subsystem can have generalizations to other subsystems. This means that the public and protected elements in the contents of a subsystem as well as operations and receptions are also available to its heirs. Furthermore, relationships between an ancestor subsystem and other model elements are inherited by specializing subsystems. In a concrete (non-abstract) subsystem all elements in the specification, including elements from ancestors, are completely realized by cooperating realization elements, as specified with, for example, a set of collaborations. This may not be true for abstract subsystems. A subsystem may offer a set of interfaces. This implies that for each operation defined in an interface, the subsystem offering the interface must have a matching operation, either as a feature of the subsystem itself or of a specification element. The relationship between interface and subsystem is not necessarily one-to-one. Interfaces of a subsystem are usually contained in the same namespace as the subsystem itself, but may also be contained in the specification of the subsystem. In the latter case, elements using these interfaces must have an import or access relationship with the subsystem to gain access to the interfaces. In cases when the physical system has several parts with the same definition, the subsystem is specified to be instantiable. The parts are then instances of this subsystem. Note, however, that all behavior specified for the subsystem is still performed by instances contained in the subsystem instances, not by the subsystem instances themselves. 2.15.4.4 Model Figure 2-35 Model illustration - shows Model and its environment in the metamodel by flattening the inheritance hierarchy. A model is a description of a physical system with a certain purpose, such as to describe logical or behavioral aspects of the physical system to a certain category of readers. Examples of different kinds of models are ‘use case,’ ‘analysis,’ ‘design,’ and ‘implementation,’ or ‘computational,’ ‘engineering,’ and ‘organizational’ each representing one view of a physical system. PackageModelElement Model ** March 2003 OMG-Unified Modeling Language, v1.5 2-197 2 UML Semantics Thus, a model is an abstraction of a physical system. It specifies the physical system from a certain vantage point (or viewpoint); that is, for a certain category of stakeholders (for example, designers, users, or orderers of the system), and at a certain level of abstraction, both given by the purpose of the model. A model is complete in the sense that it covers the whole physical system, although only those aspects relevant to its purpose; that is, within the given level of abstraction and vantage point, are represented in the model. Furthermore, it describes the physical system only once; that is, there is no overlapping; no part of the physical system is captured more than once in a model. A model consists of a containment hierarchy where the top-most package or subsystem represents the boundary of the physical system. This package/subsystem may be given the stereotype «topLevel» to emphasize its role within the model. It is possible to have more than one containment hierarchy within a model; that is, the model contains a set of top-most packages/subsystems each being the root of a containment hierarchy. In this case there is no single package/subsystem that represents the physical system boundary. The model may also contain model elements describing relevant parts of the system’s environment. The environment is typically modeled by actors and their interfaces. As these are external to the physical system, they reside outside the package/subsystem hierarchy. They may be collected in a separate package, or owned directly by the model. These model elements and the model elements representing the physical system may be associated with each other. A model may be a specialization of another model via a generalization relationship. This implies that all public and protected elements in the ancestor are also available in the specialized model under the same name and interrelated as in the ancestor. A model may import or access another model. The semantics is the same as for packages. However, some of the actors of the supplier model may be internal to the client. This is the case, for example, when the imported model represents a lower layer of the physical system than the client model represents. Then some of the actors of the lower layer model represent the upper layer. The conformance requirement is that there must be classifiers in the client whose instances may play the roles of such actors. The contents of a model is the transitive closure of its owned model elements, like packages, classifiers, and relationships, together with inherited and imported elements. There may be relationships between model elements in different models, such as refinement and trace. A trace; that is, an abstraction dependency with the stereotype «trace» indicates that the connected (sets of) model elements represent the same concept. Trace is used for tracing requirements between models, or tracing the impact on other models of a change to a model element in one model. Thus traces are usually non-directional dependencies. Relationships between model elements in different models have no impact on the model elements’ meaning in their containing models because of the self-containment of models. Note, though, that even if inter-model relationships do not express any semantics in relation to the models, they may have semantics in relation to the reader or in deriving model elements as part of the overall development process. 2-198 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Models may be nested (for example, several models of the same physical system may be collected in a model with the stereotype «systemModel»). The models contained in the «systemModel» all describe the physical system from different viewpoints, the viewpoints not necessarily disjoint. The «systemModel» also contains all inter-model relationships. A «systemModel» constitutes a comprehensive specification of the physical system. A large physical system may be composed by a set of subordinate physical systems together making up the large physical system. In this case each subordinate physical system is described by its own set of models collected in a separate «systemModel». This is an alternative to having each part of the physical system defined as a subsystem. 2.15.5 Notes In UML, there are three different ways to model a group of elements contained in another element; by using a package, a subsystem, or a class. Some pragmatics on their use include: • Packages are used when nothing but a plain grouping of elements is required. • Subsystems provide grouping suitable for top-down development, since the requirements on the behavior of their contents can be expressed before the realization of this behavior is defined. Furthermore, from a bottom-up perspective, the specification of a subsystem may also be seen as a provider of “high level APIs” of the subsystem. • Classes are used when the container itself should have instances, so that it is possible to define composite objects. As Subsystem and Model, both are Packages. In the metamodel, all three constructs can be combined arbitrarily to organize a containment hierarchy. For example, a Subsystem may be defined using a set of Models, in which case these Models are contained in the Subsystem. Another example is a set of components defined by Subsystems, collected in a Package defining a reuse library. It is a tool issue to decide how many of the imported elements must be explicitly referenced by the importing package; that is, how many ElementImport links to actually implement. For example, if all elements have the default visibility (private) and their original names in the importing package, the information can be retrieved directly from the imported package. If a tool does not support the separation of specification and realization elements for Subsystem, then the value of the isSpecification attribute for ElementOwnership should be false by default. See the Core package, where ElementOwnership is defined, for details. The issue of how to represent the runtime presence of a Subsystem has been solved by introducing SubsystemInstance, even for a non-instantiable Subsystem. An alternative, less intuitive, solution would be to have the metaclass Subsystem inherit the metaclass Instance, thus getting the desired characteristics. March 2003 OMG-Unified Modeling Language, v1.5 2-199 2 UML Semantics Because this is a logical model of the UML, distribution or sharing of models between tools is not described. It is expected that tools will manage presentation elements, in particular diagrams, that are attached to model elements. Part 5 - Actions This section defines the syntax and semantics of executable actions and procedures, including their run-time semantics. This part contains one package, Actions. The Actions package defines the various kinds of actions that may compose a procedure. 2.16 Action Package The action package structure is shown in Figure 2-36. Figure 2-36 Action package See Section 2.17.3, “The Actions,” on page 2-204 for the description of packages. Composite Action s Computation Action s Action Foundation Mes s aging Actions Collection Actions Jump Actions Read Write Action s Association Actions (from Read Write Actio...) Attribute Actions (from Read Write Actio...) Object Actions (from Read Write Actio...) Other Actions (from Read Write Actio...) Variable Actions (from Read Write Actio...) Filter (from Collection Actions) Iterate (from Collection Actions) Map (from Collection Actions) Re duce (from Collection Actions) 2-200 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.17 Actions Overview The section provides an overview of the actions that will be used by modelers. 2.17.1 Action Metamodel The classes defined in this package play the same role as the classes in the remainder of the UML metamodel. Just as the classes Class and Attribute provide a definition for the meaning of these concepts and the relationships between them, so a class CreateObjectAction in the action metamodel provides a precise definition for the concept of creating an object. Figure 2-37 shows a portion of the action metamodel that deals with creating, destroying and reclassifying objects. It shows several subclasses of the general class Action that are related to other classes in the UML metamodel to form a whole that a modeler can use to build complete, executable specifications. Figure 2-37 A fragment of the metamodel for actions One role of the action metamodel specifically is to define all the actions that a modeler can use. Figure 2-37 shows the actions CreateObjectAction, DestroyObjectAction, and ReclassifyObjectAction, each of which is defined in detail in the action package. The metamodel further asserts that a CreateObjectAction requires the specification of a classifier, the one to be created, and that the action also produces a single result, OutputPin. This class captures the concept of the result of the CreateObjectAction, which can then be manipulated by other actions. The action metamodel then, together with its supporting class descriptions and well-formedness rules, declares what actions exist and how they relate to other concepts required to support actions. A user model uses instances of classes from the metamodel. The name “customer” describes an instance of Class. A user model also contains anonymous instances of actions. A modeler can create an instance of a metamodel class, such as “customer” as Prim itiveAction (from A ction Foundation) DestroyObjectAction InputP in (from Action Foundation) ReclassifyObjectAction OutputPin (from Action Foundation) Classifier (from Core) CreateObjectAction 1 0..1 +/input 1 0..1 +/input 1 0..1 1 0..1 0..*0..* +newClassifier 0..*0..* 0..* +oldClassifier 0..*0..* 0..* 1 0..1 +/result 1 0..1 1 0..* +classifier 1 0..* March 2003 OMG-Unified Modeling Language, v1.5 2-201 2 UML Semantics an instance of “Class,” using an interactive graphical tool or other means. Similarly, a complier can create instances of actions from a user model expressed in a surface programming language. Figure 2-37 shows an instance diagram for a statement such as “Customer := new Customer” in a developer model. Execution of the statement creates an instance of class Customer and binds the new instance to a variable called “customer.” To designate the result of the action, the developer model attaches an instance of OutputPin to an instance of the CreateObjectAction. An instance of DataFlow connects the users of a value (InputPins) to the producer of a value (OutputPin) within the user model. In summary, the metaclasses in the Action Package play the same role and have the same properties as classes in other packages comprising UML. 2.17.2 Design Principles and Rationale The section outlines the design principles that animate the specification, thus providing the design rationale. 2.17.2.1 Interface to Other UML Packages This package defines the interface to other UML packages in terms of a procedure. A procedure is a group of actions caused to execute as a unit. Examples include the body of a method of a class, a group of transition actions, and so on. This package relies on the rest of UML to define the semantics for state machines and other uses of procedures, and therefore to define when a procedure executes. The action semantics defines the behavior of the actions in the procedure and exactly what data is accessible to the procedure once triggered. 2.17.2.2 Undefined Semantics When this package leaves semantics “undefined,” this means that it leaves the semantics to be defined by other packages in UML, or if UML does not define it, to the implementation. There are several cases where semantics may be left undefined by this package: • There is no general agreed-upon meaning. • The meaning is ambiguous in the part of UML that should define it. • The action or execution foundation is not able to support the desired semantics yet. An example of the first case is that no semantics is defined for using a create-object action to instantiate an abstract class. An example of second is using a write-attribute action on an ordered attribute without specifying an insertion point. An example of the third is a target scope of “classifier” for attributes and association ends. These cases of undefined semantics are described by well-formedness rules applying to the user model, and the execution rules applying to runtime execution. The fact that no semantics is given for these situations does not mean that users cannot define their own. Even though this package sometimes uses the value-laden term “ill formed” for these models, it is a purely technical term and should not be taken to mean 2-202 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics this specification excludes semantics from ever being defined for these cases. For example, some users might want to instantiate abstract classes for purposes of testing the root classes of their model. Or some may want the lack of insertion point in write- attribute action to mean that the value is inserted at the end. Finally, some users may even want to extend the action semantic foundation to support the “classifier” target scope. These users could agree on semantics among themselves that covers their needs and does not conflict with this specification. That is perfectly consistent with the action semantics and UML in general. 2.17.2.3 Specification and Software Structure At the very simplest, actions need access to data, they need to transform and test data, and actions may require sequencing. A simple, sequential model could be adequate relative to a sequential computing environment, but it is not adequate today because it is unreasonably costly to map to today’s distributed computing environments. Consequently, the specification language has to include concepts of distributed, concurrent execution. This specification therefore allows for several (logical) threads of control executing at once and synchronization mechanisms to ensure that procedures execute in a specified order. Semantics based on concurrent execution can then be mapped easily into a distributed implementation. On the other hand, the fact that a specification language allows for concurrently executing objects does not necessarily imply a distributed software structure. Some implementations may group together objects into a single task and execute sequentially—so long as the behavior of the implementation is the same as the specification. The implication is that the action semantics do not require the specification of software components, such as tasking structures, or of different forms of transfer of control, such as remote procedure calls vs. messages. Indeed the specification language need not actually specify class structure: the data and behavior of a “class” in the specification may not be rendered as a class in the implementation at all. In short, the modeler can define concurrent, distributed abstract behavior using actions, but not software structure. 2.17.2.4 Mappings There are potentially many ways of implementing the same specification, and any implementation that preserves the information content and behavior of the specification is acceptable. Because the implementation can have a different structure from that of the specification, there is a mapping between the specification and its implementation. A one-to-one mapping would implement each class as a class and each state machine directly. But the mapping need not be one-to-one: an implementation may not use classes, or it might choose a different set of classes from the original specification. The mapping may be carried out by hand by overlaying physical models of computers and tasks for implementation purposes, or the mapping could be carried out automatically. This specification neither provides the overlays, nor does it provide for code generation explicitly, but the specification makes both approaches possible. March 2003 OMG-Unified Modeling Language, v1.5 2-203 2 UML Semantics 2.17.2.5 Primitives The action semantics defines simple, primitive constructs. These primitive actions are defined in such a way as to enable the maximum range of mappings. Specifically, we define the primitive actions so that they either carry out a computation or access object memory, and never both. This approach enables clean mappings to a physical model, even those with data organizations different from that suggested by the specification. In addition, any re-organization of the data structure will leave the specification of the computation unaffected. A particular action language could implement each semantic construct one-to-one, or it could define higher-level, composite constructs to offer the modeler both power and convenience. These higher-level constructs do not need to be defined as a part of the semantics, because they already exist as composites of primitives. Primitive actions may be grouped into composite actions, including control actions such as conditionals, loops, etc. In addition, a surface language may map higher-level constructs to lower-level action model constructs. For example, in a composition association where the deletion of an instance implies the deletion of all its components, the specification defines the delete action to remove only the single instance, and the specification requires further deletions for each of the component instances. A surface language could choose to define a delete-composition operation as a single unit as a shorthand for several deletions that cascade across other associations. This specification, then, expresses the fundamental semantics in terms of primitive behavioral concepts that are conceptually simple to implement. The semantics do not define any “magic” that takes place behind the scenes. Modelers can work in terms of higher-level constructs as provided by their chosen surface language or notation. 2.17.2.6 Execution Engines The semantic primitives are defined to enable the construction of multiple execution engines, each of which may have different performance characteristics. A model compiler builder can optimize the structure of the software to meet specific performance requirements, so long as the semantic behavior of the specification and the implementation remain the same. For example, one engine might be fully sequential within a single task, while another may separate the classes into different processors based on potential overlapping of processing, and yet others may separate the classes in a client-server, or even a three-tier model. The modeler can provide “hints” to the execution engine when the modeler has special knowledge of the domain solution that could be of value in optimizing the execution engine. For example, instances could—by design—be partitioned to match the distribution selected, so tests based on this partitioning can be optimized on each processor. The execution engines are not required to check or enforce such hints. An execution engine can either assume that the modeler is correct, or just ignore it. An execution engine is not required to verify that the modeler’s assertion is true. 2-204 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.17.3 The Actions This section provides an overview of the various actions that can be included in developer models. Related actions are organized into sections that correspond to subsequent chapters. 2.17.3.1 Foundation Traditional programming languages overspecify sequence because actions, even within the same procedure, can potentially execute concurrently on different machines. For example, some execution engines might rely on a file server, and execute all data accesses on that separate machine, but over-specifying sequence inhibits such re- organization of the actions. The issue here is not concurrency of actions per se, but rather the requirement to be able to re-organize the actions for an efficient implementation. This specification therefore treats all actions as executing concurrently unless explicitly sequenced by a flow of data or control. In addition, each action is defined so that it is free of any context that describes how it is used, so that data access and other computations are two separate primitive actions connected together when required, and each action is unaware of the source or destination of the data. To meet these goals, this specification defines the concept of a data flow. A data flow carries data between two actions and in so doing effectively sequences the actions. Hence, we may execute a read action to access some data, flow that data to a computation action that computes the square, and then flow that result to a write action. The three actions have to execute in this order because each one cannot execute until the previous one produces its data. The technical reasons for this choice are first that data flow makes this form of sequencing explicit. Second, because data flows are produced only once (as a result of a specific execution of an action), we may make assertions about the values on the data flow for verification and translation purposes. A data flow connects to other components via pins. Each data flow has a source that is the output pin of some other element, typically an action, and each data flow has a destination that is an input pin to some other element. This specification also provides the ability to read and write variables local to the procedure for upward compatibility with existing languages. Finally, the specification provides for control flows between actions for explicit sequencing that does not rely on data flow. 2.17.3.2 Composite Actions This specification provides for conditionals and iteration. In both cases, there is a need to group actions together so they may be executed (or not) as unit. Such groupings may be nested, and may accept and receive control flows. Data flows are routed transparently to the actions involved. The presence of concurrency also affects how these traditional structures operate. March 2003 OMG-Unified Modeling Language, v1.5 2-205 2 UML Semantics A conditional action comprises a group of clauses that execute concurrently, subject to optional execution ordering constraints among them. Each clause has two parts: a test and a body. A test produces a Boolean value. If the value is true, the associated body may be executed. If the value is false, the body is not executed and clauses dependent on the given clause may execute their tests. If there are no constraints among a set of clauses, they may be tested concurrently. Potentially more than one test may produce a true value during execution, but only one body is executed. If more than one clause yields a true test, the body of exactly one of them is nondeterministically chosen for execution. The modeler may, of course, constrain the sequencing of the tests so that when one test evaluates to true, no further tests are evaluated, and the structure then behaves like a conventional if-then-else. The modeler may also assert that only one test is ever true by design of the tests (that is, they are mutually exclusive), so once a test has evaluated to true, no further tests need to be evaluated (even in the absence of explicit sequencing). An execution engine is not required to verify explicitly a modeler’s assertion of mutual exclusion. Some kinds of iteration require sequential execution, for example, a regression that takes the outputs of one cycle and feeds it as inputs to the next. This kind of iteration is managed by the loop action. It comprises a single clause that, in turn, comprises a test and a body. The body is executed repetitively while the test is true. The body of a loop accepts a set of input values and produces a set of output values. The output values of one iteration of the body become the input values for the next iteration of the loop. These values are known as the loop variables. (Iterations that scan the elements of a collection are handled by collection actions. These include both concurrent scans and sequential scans. See below.) 2.17.3.3 Read and Write Actions Objects, attributes, links, and variables have values that are available to actions. Objects have classifiers and objects can be created and destroyed; attributes and variables have values; links may be created and destroyed, and they have link ends, and qualifier values; all of which are available to actions. Read actions get values, while write actions modify values and create and destroy objects and links. Read and write actions share the structures for identifying the attributes, links, and variables that they are accessing. Read actions do not modify the values they access, while write actions, as a general policy, have the most minimal effect possible. For example, creating an object does not execute constructors. Languages requiring additional semantics can define higher-level actions on the primitive ones given here. Unlike read actions, write actions may leave semantics unspecified in some cases. No semantics is usually given when an action violates those aspects of static UML modeling that constrain runtime behavior. For example, no semantics is given for creating an instance of an abstract class. The only exception is minimum multiplicity, which is given a semantics equivalent to the lower multiplicity being zero. Modelers of language bindings can assign their own semantics for undefined cases. 2-206 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.17.3.4 Computation Actions Computation actions transform a set of input values to produce a set of output values. These actions work directly on values and produce values; they embody mathematical functions. They do not interact with object memory: they do not read or write attribute or link values. They do not interact with other objects or other executions, so their control is entirely self-contained. These actions supply the primitive functions out of which computations are constructed. This specification allows for the incorporation of primitive functions, such as mathematical functions or string manipulations, that may be gathered together to form a profile for specific uses, but it does not define a set of primitive functions as a part of the specification. This allows the actions to be extensible. 2.17.3.5 Collection Actions Collection actions permit the application of an action to a set of data elements, possibly in parallel. They avoid the need for explicit indexing and extracting of elements from collections, avoiding the overspecification of control that would otherwise be necessary. Each collection action contains a subaction, an embedded action that is executed once for each element in the input collection. There are four kinds of collection action. The map action applies a subaction in parallel to each of the elements of a collection of data, resulting in an output that is a collection of the same size and shape. The filter action selects a subset of the elements in a collection into a new collection of the same shape, based on a boolean result of the subaction applied to each element. The iterate action applies a subaction repeatedly to each of the elements in a collection, accumulating the effects in loop variables. The reduce action repeatedly applies a binary subaction to pairs of adjacent elements in a collection, implicitly replacing a pair of elements by the result, until the final result is a single element of the type in the collection. The binary subaction must be associative, therefore it may be applied in parallel to many pairs of elements, because the exact order of application will not affect the final result. For example, summation or matrix multiplication are reduction operators. There is also a separate loop action that carries out actions repetitively subject to an arbitrary test. The iteration action can be regarded as a specialization of the loop in which a separate element of the collection is selected for input to each iteration and the while-test fails when all elements have been processed. 2.17.3.6 Messaging Actions These actions exchange messages among objects. An initial message from one object to another is called a request. The sender of a request may simply continue execution immediately without concern for the behavior invoked by the request (an asynchronous request, or send), or it may choose to suspend execution until the activity invoked by the request reaches a well-defined point and sends a reply message back to the requestor, with optional return values (a synchronous request, or call). If the request is synchronous, the behavior of the receiver must have a well-defined reply point; if the March 2003 OMG-Unified Modeling Language, v1.5 2-207 2 UML Semantics request is asynchronous, a reply is optional and will be ignored. The receiver may handle a request in various ways based on its organization, including procedure execution and triggering a state machine. The requestor need not be aware of how the request will be handled. The messaging model covers a wide range of ways to match behavior to requests, including state machine triggers, fixed procedures, class-based method lookup, method combination (such as before-after methods), object-based delegation (as in self), and so on. In all cases, the effect is processed by a distinct context from the context of the requestor and the messaging information is transmitted among requestor and target by value. This messaging model fully supports distributed processing without special mechanisms. This model unifies operations and signals into a single concept. 2.17.3.7 Jump Actions All flow of control for a procedure could use Dijkstra-style, fully nested flow-of- control constructs, but this style can be awkward and obscure when dealing with unusual or secondary conditions that do not follow the main line. Programming languages include constructs such as break, continue, and exceptions for dealing with these situations. When a non-mainline situation occurs, the normal flow of control is abandoned and a different flow of control, specified in the program, is taken. The UML jump construct unifies these nonlinear flow-of-control mechanisms while providing the functionality found in most modern programming languages. 2UML Semantics 2.18 Action Conventions This describes the structure and conventions applied in the chapters that describe actions. 2.18.1 Chapter Structure Each chapter begins with a brief introduction that outlines the content of the chapter, the theme behind it, and any high-level design decisions or criteria that guide the chapter. The following several sections in each chapter introduce the key abstractions for readers. The material is organized for understanding, not for detailed reference. The purpose is to give the reader an intuitive feel for the concepts, and, particularly, to show how they work together and the reason that they are needed. These sections strive for clarity at the expense of detail, and they are not normative. Examples, diagrams, and partial models help present concepts. The normative specifications appear in the precise descriptions of classes in subsequent chapters. Metamodel diagrams of the actions are included in these conceptual sections. These are normative and are the basis of the interchange format. 2-208 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics The final sections of each chapter (with titles “... Classes”) define the actions in alphabetical order. Each class section covers the semantics of the class, including its attributes and associations, inputs and outputs, static well-formedness rules, and additional OCL operations. These sections are normative. The format used is the subject of the next section of this chapter. 2.18.2 Description of a Class The formal class descriptions begin with the technical meaning of the class. If it is an action, it describes what the action does. It calls out all semantic features, unless detailed aspects are given in the semantic section. The following subsections are lists with specific formats for their contents. • Attributes • Associations • Inputs • Outputs • Well-formedness rules • Additional operations A subsection is omitted if it has no elements, except for Inputs and Outputs, which are included for all concrete action classes and omitted for abstract action classes. 2.18.2.1 Attributes This subsection lists all attributes of the class, including their types and multiplicity. For enumerations that are used as the type of only one attribute, a list of enumeration literals may follow, one to a line. • name: type [multiplicity] A description of the attribute. For enumerations: foo—description of the literal bar—description of the literal Inherited attributes are omitted. 2.18.2.2 Associations This subsection lists all associations that have end names opposite from the class being described. If an association has no opposite end name, it is omitted. All associations are described in at least one direction. For example: • endName: TargetClassName [multiplicity] Description of the association in the target direction March 2003 OMG-Unified Modeling Language, v1.5 2-209 2 UML Semantics Inherited associations ends are omitted unless they are derived. Associations are sometimes derived from more general ones to limit the kinds of classes that can participate. The parent and association end from which an end is derived are given at the beginning of the description: • derivedEndName : TargetClassName [multiplicity] First, in parentheses, give the name of the parent class and association end using the notation Class:endName. Then describe the association. The following is an example from CreateLinkObjectAction: • result [1..1] : OutputPin [1..1] (Derived from Action:outputPin) Gives the output pin on which the result is put. 2.18.2.3 Inputs In describing an action, it is necessary to refer to the values that are delivered to the action on its input pins and sent by the action on its output pins. The action metamodel in Section 2.19, “Action Foundation,” on page 2-211, defines the association of an abstract action with a set of input pins and a set of output pins. Each kind of action requires a specific set of inputs and produces a specific set of outputs. For example, a read-attribute action has a single pin to which the object to be read is supplied and a single output pin that holds the value that is read. For clarity, the action metamodel contains derived associations that delineate the specific set of input and output pins required for an action. These are listed in the Associations section. For additional clarity, the input and output pins are also listed in separate sections that give information normally spread out in the metamodel and well-formedness rules. This section lists the pins by the name of the corresponding derived association end. For each derived pin association, the multiplicity is given resulting from combining the multiplicity of the association at the pin end and the multiplicity of the pin itself. The type of the pin itself is not always constant, so is not given. The description gives any static constraints on the typing of the input pins that are in the well-formedness rules. This is an example from AddAttributeValueAction: • value : RuntimeInstance [1..1] (Inherited from WriteAttributeAction) Value of attribute to add. Its type is the same as the type of the attribute. Inherited pins are included and the parent class from which they are inherited is given at the beginning of the description in parentheses. • inputName : type [multiplicity] ( Inherited from Foo) Description of inherited pin. Here’s the more general format: • inputName [multiplicity] : type First, in parentheses, give the name of the parent class from which the pin is inherited, if any. Then describe the pin, including any constraints on the type given in the well-formedness rules. 2-210 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Sometimes getting to a pin from an action requires navigating more than one association. In this case, the entire navigation path is given using the OCL dot operator. The multiplicity of the association at the pin end in this case should actually be a combination of all the multiplicities navigating from the action to the pin, and reflect well-formedness constraints on those multiplicities that do not depend on the user model. Here’s an example from CreateLinkAction: • endData.qualifier.value : RuntimeInstance [0..*] (Inherited from LinkAction) Gives the qualifier value of an association end if the end is qualified. It is the same type as the qualifier attribute. See LinkEndData. In the above example, the qualifier value is reached from a CreateLinkAction by navigating through the endData association, then the qualifier association, then the value association. The order in which the input pins are listed specifies the order in which pins must be linked to the action. This represents well formed rules on the action model. For example, suppose an action has two input pins with derived association end names “object” and “value.” If the pins are listed in that order, then the corresponding well- formedness rules on the action model are: [1] self.object = self.inputPin.at(1) [2] self.value = self.inputPin.at(2) The well-formedness formally specify derivation of the pin associations. This subsection is included for concrete action classes even if there are no input pins, with the text “None.” It is not included for abstract action classes. 2.18.2.4 Outputs This subsection lists the output pins using the same format as input pins. The well- formedness rules represented by the listing order are also the same, except they apply to output pins instead of input pins. 2.18.2.5 Well-formedness Rules This subsection lists static constraints on user models. The constraints are expressed first in English, then in OCL. The constraints do not cover aspects already expressed in the model, such as association multiplicity. Well-formedness rules defined for a class are inherited by all its subclasses. 2.18.2.6 Additional Operations This section defines additional OCL operations that apply to the class. These also apply to all the descendants of the class. March 2003 OMG-Unified Modeling Language, v1.5 2-211 2 UML Semantics 2.18.2.7 Semantics This section contains more detailed specification of semantics, if needed. It is primarily for actions that go through intermediate states of execution. 2.19 Action Foundation This section describes the structure of procedures and actions in the UML metamodel. The foundational concepts discussed in this chapter apply to all kinds of actions. The details of specific kinds of actions are described in subsequent chapters. 2.19.1 Action Specification An action is the fundamental unit of behavior specification. An action takes a set of inputs and converts them into a set of outputs, though either or both sets may be empty. In addition, some actions modify the state of the system in which the action executes. The inputs to an action may be obtained from the results of other actions, and the outputs of the action may be provided as inputs to other actions, some of which have the sole purpose of reading or writing object memory. Figure 2-38 Action foundation model ModelElement PrimitiveAction Classifier Pin multiplicity : Multiplicity ordering : OrderingKind 0..10..* +type 0..10..* ModelElement DataFlow ControlFlow Procedure language : Name body : String isList : Boolean InputPin 1 1 +destination 1 +flow 1 0..* 0..1 +result 0..* {ordered} +procedure 0..1 Output Pin 1 0..* +source 1 +flow0..* 0..* 0..1 +argument 0..* {ordered} + p roc ed ure 0..1 Action isReadOnly : Boolean 0..* 1 +consequent 0..* +predecessor 1 1 0..* +successor 1 +antecedent0..* 1 0..1 +action 1 0..1 0..* 0..1 +inputPin 0..* {ordered} +action 0..1 0..* 0..* +/availableInput 0..* 0..* 0..1 0..* +action 0..1 +outputPin 0..*{ordered} 0..*0..* +/availableOutput 0..*0..* 2-212 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.19.1.1 Pins An action takes some input values, possibly accesses the state of the containing system, performs some processing, possibly modifies the state of the system, and produces some set of output values. The required inputs and outputs of an action are specified as pins of the action. A pin specifies the type and multiplicity of values that may be held by the pin. A pin may hold multiple values, subject to the specified multiplicity. Each of the values held by a pin must conform to the type specified for the pin. This type conformance is determined as follows. • If the specified type is a primitive type, then the pin can only hold primitive values of the given type. • If the specified type is an enumeration type, then the pin can only hold enumeration values of the given type. • If the specified type is a data type other than a primitive or enumeration type, then the pin can hold values of the given type or any specialization of the given type. • If the specified type is a classifier other than a data type, then the pin can hold object identities that have the given type or a specialization of the given type. Input pins are the connection points for delivering the input values to actions. Output pins are the connection points for obtaining the output values from actions. The types and multiplicities of the input and output pins of an action are constrained by the form of the action. For example, an action that reads a certain attribute has an output pin with the type and multiplicity of that attribute, while an action that writes to an attribute has an input pin with the type and multiplicity of that attribute. An action that calls an operation has (possibly empty) sets of input and output pins with types and multiplicities corresponding to the input and output parameters of the operation. The entire context for an action is represented in its pins, including the “current object” that is also passed to an action on a pin. There is no “back door” by which an action can access objects implicitly. Note – The types of the input and output pins of an action form the input and output “signature” of the action. The signature is modeled by derivation from the types of the input and output pins; it is not modeled explicitly. Some actions impose constraints on the types of some of their pins. 2.19.1.2 Data Flow A data flow from an output pin to an input pin indicates that an output value of one action is used as an input value of another action. Data flows link chains of actions without having to store values temporarily. March 2003 OMG-Unified Modeling Language, v1.5 2-213 2 UML Semantics A single output pin can be connected to zero or more input pins, but each input pin can have at most one connection. Thus, input pins are “single assignment” data holders—once they receive a value, this value does not change. In other words, normal dataflow connections allow “fan out,” but not “fan in.” The input pin that is the destination of a data flow must conform to the output pin that is the source of the flow: the type of the output pin is the same as or a descendant of the type of the input pin, and all cardinalities allowed by the multiplicity of the output pin are allowed by the multiplicity of the input pin. For example, if the type of the output pin is money, and the type of the input pin is real, and money is a descendant of real, then the types conform. 2.19.1.3 Control Flow A control flow indicates an ordering constraint between a predecessor action and a successor action without explicit data flow. A predecessor action must complete execution before its successor action can execute. Such control constraints are often required for actions that affect object memory, such as when a value written to an attribute by one action is to be read by a subsequent action. Control flow specifies the order of actions that require such constraints. Other actions create or destroy objects, communicate among objects, or have external effects outside the system. Control flow is used to order these actions as well. Control flow represents an implicit potential communications path among actions—through object memory, by signal transmission, or outside of the system. Traditional programming languages have implicit control flows between each statement, but they overspecify execution order. The model defined here permits control flows, data flows, and concurrent actions as needed. A data flow implies a control dependency in the sense that an executing action cannot consume an input value during execution until it has been produced by the source action. Control sequencing is implicit between actions connected by data flows; it is unnecessary to include explicit control flows between such actions. The network of actions connected by data and control flows forms an acyclic directed graph because an action cannot be both a predecessor and successor of another at the same time. 2.19.1.4 Primitive Actions A primitive action is one that cannot be decomposed into other actions. Primitive actions include purely mathematical functions, such as arithmetic and string functions; actions that work on object memory, such as read actions and write actions; and actions related to object interaction, such as messaging actions. Each kind of primitive action has a form that specifically defines sets of input and output pins. The details of the various kinds of primitive actions are discussed in later chapters in this part. 2-214 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.19.1.5 Procedures Within a user model, actions may be nested at various levels. The highest-level such grouping is the procedure. A procedure is a set of actions that may be attached as a unit to other parts of the user model, for example, as the body of a method. Conceptually a procedure takes a single request object as argument and produces a single reply object as result. Both the type and the attributes of the request object and the reply object may convey information. As a convenience, if the isList flag is true, the procedure may be written with multiple arguments and results; the attributes of the request object are automatically unmarshalled into a list of arguments, and a list of results are automatically marshalled into a reply object; the type of the request and reply objects are implicitly generated for each such procedure. All uses of procedures may have an argument (or arguments, if the isList flag is true), corresponding to the input parameters. Procedures executed as the result of synchronous calls may have a result (or results, if the isList flag is true); procedures executed as a result of asynchronous invocations do not have results (or rather, if they do have result pins, the results are ignored). See Section 2.24, “Messaging Actions,” on page 2-311. The arguments supply values to the action by output pins within the procedure, and each one may be connected to zero or more inputs of the action. Similarly, the results are represented as input pins within the procedure, and each one must be connected to exactly one output of the action. The data flow connections then follow the normal connection rules for input and output pins. The types of the actual arguments to a procedure can be descendants of the declared types. The types of the actual results of a procedure can be descendants of the declared types. As with any action, the pins on a procedure action must match the types and multiplicities of the corresponding parameters supplied to the method, or the supplemental data items on the triggering event. Procedures can have a textual specification entered in the body attribute, with the kind of specification given in the language attribute. 2.19.2 Action Execution Model An action execution corresponds to an individual execution of a particular action. Similarly, a procedure execution is an individual run-time execution of a procedure. Each action in a procedure may execute zero, one, or more times for each procedure execution, depending on the use of composite and collection actions. Execution is not instantaneous, but takes place over a period of time. Procedures and other groupings of actions must be executed in a number of steps, including control of the execution of nested actions. Thus, procedure and action executions, in general, require the maintenance of state information over time. March 2003 OMG-Unified Modeling Language, v1.5 2-215 2 UML Semantics 2.19.2.1 Pin Values Both procedures and actions have pins that get values during procedure and action execution. A pin value represents the value of a single pin at a specific point in the execution of a procedure or action. There may actually be a collection of instance values associated with a pin value, consistent with the multiplicity of the corresponding pin. 2.19.2.2 Action Execution The action semantics place no restriction on the relative execution order of two or more actions, unless they are explicitly constrained by data flow or control flow relationships. Hence every action within a procedure may execute at once, though a specific execution engine may actually perform the executions sequentially or in parallel. The execution of an action proceeds through a life cycle whose stages are as follows. These stages can be understood in terms of the constraints they place on the action execution at various points in its history. • Waiting - An action execution may be created at any time after the procedure execution for its containing procedure is created. On creation, an action execution has the status waiting and no pin values. • Ready - An action execution with status waiting becomes ready on the completion of the execution of all prerequisite actions (that is all actions that are the sources of data flows or predecessors of control flows into the action becoming ready). This synchronization captures the ordering in time between the completion of prerequisite action executions and the readying of their target. The values of the input pins of the target action execution are determined by the values of the output pins from the prerequisite action executions for actions that are the sources of data flows. (Enclosing composite actions may also place constraints on the execution of nested actions—for instance, conditional execution.) • Executing - Once it is ready, an action execution eventually begins executing. An action need not begin executing immediately upon being ready and the action semantics do not determine the specific time delay (if any) between becoming ready and actually executing. For a primitive action, there will be only one executing step in the history of the execution. However, a composite action may require several steps to complete execution. • Complete - When it has finished executing, the action execution becomes complete. The action execution then has pin values for all output pins of the action as well as all input pins. The specific semantics of each kind of action determine how these output pin values are computed. After the output values from a completed execution have been copied, there is no longer any way for another execution to access the completed execution. Because a completed execution is inaccessible, the action semantics does not supply any clean up or garbage collection rules, as they cannot affect the outcome of the computation. This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-39 on page 2-217. 2-216 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.19.2.3 Procedure Execution A procedure execution also has four statuses. • Ready - A procedure execution begins with status ready. Input parameters are passed to the procedure as values of its argument pins. These are captured as pin values that must be associated with the procedure execution on its creation. (Procedure executions are generally created as the direct or indirect result of messaging actions.) • Executing - Once it is ready, a procedure execution eventually beings executing. A procedure need not begin executing immediately upon being ready and the action semantics do not determine the specific time delay (if any) between becoming ready and actually executing. When a procedure beings executing, it causes the start of the execution of the nested action. • Returning - When its nested action has completed execution, it transitions to the status returning. At this point the procedure execution has pin values for all the result pins of the procedure. In the specification of the procedure, the result pins are connected by data flows to the output pins of actions within the procedure. This specification and the procedural context of completed action executions within the procedure execution then determine the values for the result pins. If the procedure execution was triggered by a messaging action, then it may package its results for transmission back to the invoker. • Complete - Once the procedure execution has completed returning, it becomes complete. This life cycle may be depicted informally using a statechart diagram, as shown in Figure 2-39. March 2003 OMG-Unified Modeling Language, v1.5 2-217 2 UML Semantics Figure 2-39 Life cycle for action execution A procedure execution acts as a context for all action executions nested directly or indirectly within it. This contextual information includes the following. • Host - A procedure may execute as the result of the invocation of a method or an event occurrence triggering a transition. The host of the execution is the instance that owns the invoked method or the state machine for the transition. The host remains frozen throughout the execution. (There is no host instance for procedures associated with a method with classifier scope or for procedures acting as expressions.) • Action executions - A procedure is the root of a tree of current action executions. Each of these action executions can reference its parent action execution. However, it is generally not possible to determine statically which actions within the procedure will actually execute, or even at all. The current set of action executions waiting ready executing complete / start execution when( all prerequisites are satisfied ) when( execution complete ) Behavior while executing is de te rm in e d by ea c h kind of action. 2-218 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics nested within a procedure execution will generally change over time. Nevertheless, this set provides the ability to map from the specification of an action within a procedure to the specific, current execution of that action within the context of a given procedure execution (if, of course, that action is currently executing at all). Figure 2-40 The life cycle for procedure execution Note – A UML constraint contains an expression that can be modeled using a procedure with a Boolean result. However, when such procedures should be executed and what should be done when they fail is not a simple question. Some apply at all times, but most can be violated during the actions of a transition. Some may be valid after certain actions. Currently, the action semantics specification does not attempt to verify or enforce user-defined constraints that are made invalid by actions. In effect, such constraints are considered to be design statements and the system implementer is obliged to ensure that they are not violated. Ready Executing Returning Complete / start execution of nested action when( nested action execution is complete ) / copy output values to results when( return is com plete ) March 2003 OMG-Unified Modeling Language, v1.5 2-219 2 UML Semantics 2.19.3 Action Foundation Classes 2.19.3.1 Action An action is the fundamental unit of behavior specification. An action takes a set of input values and uses them to produce a set of output values, though either or both sets may be empty. If both inputs and outputs are missing, the action must have some kind of fixed, nonparameterized effect on the system state, or be performing some effect external to the system. Actions may access or modify accessible, mutable objects. A reference to an object to read or write is an input of the action. Composite actions may include data-transformation actions as well as object-access actions. An action may have a set of incoming data flows as well as a set of explicit control flow dependencies on predecessor actions. An action will not begin execution until all of its input values (if any) have been produced by preceding actions and all predecessor actions have completed. The completion of the execution of an action may enable the execution of a set of successor actions and actions that take their inputs from the outputs of the action. Actions come in various kinds, each of which has its own formation rules. An action must be one of those kinds. Attributes • isReadOnly : Boolean If true, then this action must not make any changes to variables outside the action or to object memory. (This is an assertion, not an executable property. It may be used by an execution engine to optimize model execution. If the assertion is violated by the action, then the model is ill formed.) Associations • antecedent : ControlFlow [0..*] The set of control flows that must be enabled before this action can execute. • availableInput : InputPin [0..*] (Derived from Action::inputPin) The set of all input pins available to be the destinations of data flows entering the action. Such pins must not have data flows from pins within the action. The derivation rule is defined for each kind of action. • availableOutput : OutputPin [0..*] (Derived from Action::outputPin) The set of all output pins available to be the sources of data flows leaving the action. These pins may also be connected by data flows to input pins within the action. The derivation rule is defined for each kind of action. • consequent : ControlFlow [0..*] The set of control flows that are enabled when this action finishes executing. • inputPin : InputPin [0..*] The ordered set of input pins owned by the action, which act as connection points for providing values consumed by the action. 2-220 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics • outputPin : OutputPin [0..*] The ordered set of output pins owned by the action, which act as connection points for obtaining values generated by the action. Well-formedness Rules Note – This is a necessary but not sufficient condition to prevent ill formed control cycles. There are additional conditions related to conditional and loop actions that are handled as well-formedness rules for those kinds of actions. Additional Operations [1] There must be no cycles in the graph of actions and flows, where a cycle is defined as a path that begins and ends at the same action and a path is constructed from directed edges between actions, with control flows traversed from predecessor action to successor action and data flows traversed from the action of the source pin to the action of the destination pin. A control flow from or to a group action is treated as being a set of control flows from or to each action within the group action. not self.allSuccessors()->includes(self) [1] This operation returns the set of all immediately nested actions of this action. The actual set returned is defined in concrete descendants of Action. nestedActions() : Set(Action) [2] This operation returns all nested actions of an action, nested to any depth. allNestedActions() : Set(Action) allNestedActions() = self.nestedActions()->union(self.nestedActions().allNestedActions()) [3] This operation returns the set of immediate subactions of this action, whose output pins may be directly connected to the input pins of actions outside this action. The actual set returned is defined in concrete descendants of Action. (This is only intended to include subactions that are “visible” through a “porous” boundary, which currently includes only the subactions of GroupAction). subactions() : Set(Action) [4] This operation returns all subactions of an action, nested to any depth. allSubactions() : Set(Action) allSubactions() = self.subactions()->union(self.subactions().allSubactions()) [5] This operation returns the set of all input and output pins of an action. allPins() : Set(Pin) allPins() = self.inputPin->union(self.outputPin)->asSet() March 2003 OMG-Unified Modeling Language, v1.5 2-221 2 UML Semantics Semantics An action execution represents the general run-time behavior of executing an action within a specific context. Action is an abstract class; therefore all action executions may be executions of specific kinds of actions. 1. An action execution is created with status waiting with no pin values initialized. The action has the same procedural context as the action execution that created it. For the top-level action execution in a procedure, a procedural context is created with empty slots for all of the variable values or data flow values that may be created during an execution of a procedure. All action executions within a procedural execution share the same procedural context, that is, they share access to the same set of variable and data flow values. 2. An action execution that is waiting becomes ready when all its data flow and control flow prerequisites have satisfied, at which point it obtains input pin values from each of its data-flow sources. After all the values have been obtained, the action execution begins executing. 3. An action continues executing until it has completed. Details of execution are given under the description of each particular kind of action. 4. When completed, an action execution produces values on all its output pins and terminates execution. The action execution satisfies control flow or data flow prerequisites for any other potential action executions that depend on it or one of its data values. [6] This operation returns true if the action is a subaction, at any depth, of another given action. isSubaction(otherAction: Action):Boolean isSubaction(otherAction) = otherAction.allSubactions()->includes(self) [7] This operation returns the set of actions whose execution must complete before this action can execute: the source actions in data flows and predecessor actions in control flows. prerequisites() : Set(Action) prerequisites() = self.inputPin.flow.source.action->union(self.antecedent.predecessor) [8] This operation returns all the actions which are destinations of data flows or successors of control flows leaving an action. A control flow from or to a group action is treated as being a set of control flows from or to each action within the group action. successors() : Set(Action) successors() = self.outputPin.flow.destination.action ->union((self.consequent.successor->union(self.group.consequent.successor)) ->collect(a : Action | a.subactions()->including(a)))->asSet() [9] This operation returns the transitive closure of all data-flow and control-flow successors (defined as above) of an action. allSuccessors() : Set(Action) allSuccessors() = self.successors()->union(self.successors().allSuccessors()->asSet() 2-222 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.19.3.2 ControlFlow A control flow is a sequencing dependency between two actions. The successor action of the flow may not execute until the predecessor action has completed execution. Associations • predecessor : Action [1..1] The action that must finish executing before the successor can execute. • successor : Action [1..1] The action that cannot execute until the predecessor completes execution. Semantics An action execution has a control flow prerequisite on each action execution in the same procedural context for which the respective actions have a successor-predecessor relationship. The prerequisite is satisfied when the predecessor action execution has completed execution. 2.19.3.3 DataFlow A data flow carries values from a source output pin to a destination input pin. When a value is generated on the source pin, it is copied to the destination pin. The source pin must therefore conform in type and multiplicity to the destination pin. Associations • destination : InputPin [1..1] The input pin that receives the data carried by the flow. • source : OutputPin [1..1] The output pin that provides the data carried by the flow. Well-formedness Rules Note – Since UML does not provide any standard classifier that is the ancestor of all other classifiers, untyped pins can be used for the purpose of accepting input of “any” type. . [1] The type of the source pin must be the same as or a descendant of the type of the destination pin. An untyped pin has a type that is an ancestor of any classifier. self.destination.type->isEmpty() or (self.source.type->notEmpty() and (self.source.type = self.destination.type or self.destination.type.allParents()->includes(self.source.type))) March 2003 OMG-Unified Modeling Language, v1.5 2-223 2 UML Semantics Note – The operation “allParents” is defined for GeneralizableElement. Semantics An action execution e corresponding to action a has a data flow prerequisite on each output pin p for which the output pin p is connected to any input pin of a. The prerequisite is satisfied when the output pin p holds a value within the same procedural context as the action execution e. 2.19.3.4 InputPin An input pin holds input values to be consumed by an action. An input pin may be the destination for exactly one data flow. The input pin receives its values from the source output pin of the data flow. Associations • action : Action [0..1] The action that owns the pin as an input. This value only applies to Actions. • flow : DataFlow [1..1] The data flow for which this input pin is the destination. • procedure : Procedure [0..1] The procedure that owns the pin as a result. This value only applies to Procedures. Well-formedness Rules Semantics An input pin holds a potential value within each procedural context holding an execution of the action to which the pin is an input. When the procedural context is created, all input values are initially empty. Input values are initialized just before the execution of their action. 2.19.3.5 OutputPin An output pin holds output values generated by an action. A single output pin may have several data-flow connections to several input pins. In this case, the output pin provides a copy of its value to each of the associated input pins. [1] All cardinalities allowed by the multiplicity of the source pin must be allowed by the multiplicity of the destination pin. self.source.multiplicity.compatibleWith(self.destination.multiplicity) [1] An input pin must be owned by either an action or a procedure but not both. self.action->size() + self.procedure->size() = 1 2-224 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Associations • action : Action [0..1] The action that owns the pin as an output. This value only applies to Actions. • flow : DataFlow [1] The data flow for which this output pin is the source. • loop : LoopAction [0..1] The loop action that owns the pin as a loop variable (see the discussion under Composite Actions). This value only applies if the pin is a loop variable. • procedure : Procedure [0..1] The procedure that owns the pin as an argument. This value only applies to Procedures. Well-formedness rules Semantics An output pin holds a potential value within each procedural context holding an execution of the action to which the pin is an output. When the procedural context is created, all output values are initially empty, except those output values initialized as parameters of the overall procedure. Output values are initialized at the completion of execution of their action. 2.19.3.6 Pin A pin is a connection point for delivering input values to or obtaining output values from an action. Any values passing through the pin must conform to the type of the pin and have cardinalities allowed by the multiplicity of the pin. (A pin without a type specification can hold any value.) Pin is completely specialized into input and output pins. Attributes • multiplicity : Multiplicity [1..1] A specification of the number of values a pin may hold at any one time. • ordering : OrderingKind [1..1] Indicates whether the set of values held by this pin is to be considered ordered or not. Associations • type : Classifier [0..1] A classifier specifying the allowed classifiers of values passing through the pin. The actual classifier of a value must conform to the type specification of the pin. [1] An output pin must be owned by exactly one of an action (as an input), a loop action (as a loop variable), or a procedure (as a result). self.action->size() + self.loop->size() + self.procedure->size() = 1 March 2003 OMG-Unified Modeling Language, v1.5 2-225 2 UML Semantics Semantics See InputPin and OutputPin. 2.19.3.7 PrimitiveAction A primitive action is one that does not contain any nested actions, so all available inputs and outputs of the action are pins directly owned by the action. Well-formedness Rules Note – PrimitiveAction is really only defined as a convenience to provide a common definition of these well-formedness rules for all kinds of primitive actions. Additional Operations Semantics See Action for the general rules of starting and finishing execution. See the particular kind of action for the rules of executing the action and producing output values. 2.19.3.8 Procedure A procedure is a set of actions that may be attached as a unit to other parts of the user model. The behavior of the procedure is specified using an action, which is usually composite. When it is activated, a procedure execution receives a request object from the caller; during its execution it produces a reply object that is returned to the caller as the result. The procedure has a single input pin for the request object and a single result pin for the reply object. If the isList flag is set in the action, the procedure may have multiple argument and result pins; the request object is broken apart into an ordered list of arguments, one per attribute of the request object; and the reply object is composed from an ordered list of results, one per attribute of the reply object. This option presents the inputs and outputs to the procedure in the traditional fashion as a list of explicit parameters, although they are composed into a request object and a reply object for use by the invocation action. [1] The available inputs of a primitive action are the input pins of the action. self.availableInput = self.inputPin->asSet() [2] The available outputs of a primitive action are the output pins of the action. self.availableOutput = self.outputPin->asSet() [1] A primitive action has no subactions. (The subactions operation is defined for each kind of action.) subactions() : Set(Action) subactions() = Set{} 2-226 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Pins of procedures have two directions: in and out, while method and operation parameters have direction in, out, inout, and return. Since parameters and pins are ordered on methods and procedures respectively, the parameters of methods can be matched to pins on procedures unambiguously, assuming the last output pin is matched to the return parameter. Parameters of kind in and inout match input pins, while parameters of kind out, inout, and return match output pins. Attributes • body : String A textual representation of the procedure in the named surface language. (Presumably the procedure is the result of parsing this representation, though that correspondence cannot be guaranteed by the rules of the metamodel.) • language : Name The name of the language in which the textual procedure body is represented. (This language name should follow the conventions for language names in UML, as described for the language attribute of Expression.) • isList: Boolean If true, the request is presented to the procedure as a list of zero or more separate argument pins and the result is delivered as a list of zero or more separate result pins. If false, there is a single argument pin that receives the request object and a single result pin that receives the reply object. Associations • action : Action [1..1] The action that provides the behavioral specification of the procedure. • argument : OutputPin [0..*] if isList is true: The ordered set of output pins representing procedure arguments. if isList is false: One output pin representing the request object. Any extra pins are ignored. • result : InputPin [0..*] if isList is false: The ordered set of input pins representing procedure results. if isList is true: One input pin representing the reply object. Any extra pins are ignored. Well-formedness Rules [1] All available inputs of the action of a procedure must be the destinations of flows, the sources of which are arguments of the procedure. self.argument->includesAll(self.action.availableInput.flow.source) [2] All results of a procedure must be the destination of flows, the sources of which are available outputs of the action of the procedure. March 2003 OMG-Unified Modeling Language, v1.5 2-227 2 UML Semantics Semantics A procedure execution is a single execution of a procedure as a result of its invocation by a call, the firing of a state machine transition, or some other means that might be defined in the future. A procedure in a user model may correspond to many procedure executions over time or at the same time. Each is an independent execution of the procedure. A procedure execution maintains the context for all action executions within the procedure execution. It ties together all of the action executions and values corresponding to a single execution of a procedure. It represents a logical memory space with slots for variable values, data flow values, and action execution states. A procedure execution could be implemented in many different ways; the reader should not assume that it must be implemented directly as described. 1. When a procedure is invoked, a procedure execution is created. For each argument pin of the procedure, an output pin value in the procedure execution is initialized with a value copied from the corresponding argument value in the invocation. All other input and output pins and variables in the procedure are initialized to empty values. For each action in the procedure, the procedure execution contains an action execution in the waiting state. 2. After a procedure execution has been initialized, the execution of its nested action is placed in the ready state and begins execution. The effects of this execution eventually work their way through the entire procedure. When all of the subordinate actions have completed, the execution of the top-level nested action will be complete. 3. When the execution of the top-level nested action is complete, the procedure execution must wrap up: • If the procedure invocation was asynchronous and not repliable, the execution is complete. • If the procedure invocation was asynchronous and repliable, the (possibly empty set of) output values corresponding to result output pins of the procedure are formed into a result object that is transmitted to the object whose action invoked the procedure. • If the procedure invocation was synchronous, the (possibly empty set of) output values corresponding to result output pins of the procedure are formed into a result object that is returned to the action execution that invoked the procedure. self.action.availableOutput->includesAll(self.result.flow.source) [3] If the arguments/results are presented as request/reply objects, there must be exactly one argument pin and exactly one result pin. self.isList implies (self.argument->size = 1 and self.result->size = 1 2-228 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.20 Composite Actions Composite actions are recursive structures that permit complex actions to be composed from simpler actions. A composite action can contain other composites as well as primitive actions. The leaves of the tree of action decomposition are primitive actions. The composite actions discussed in this section also provide for control structures beyond explicit data flows and control flows. 2.20.1 Composite Action Specification This section gives a schematic description of the structure and behavior of composite actions. Figure 2-41 shows the model for these actions. Section 2.20.3, “Composite Action Classes provides the formal definitions of all the classes shown in Figure 2-41. Figure 2-41 Composite actions metamodel ModelElement (from Core) ConditionalAction isDeterminate : Boolean OutputPin (from Action Foundation) LoopAction 0..* 0..1 +loopVariable 0..* {ordered} +loop0..1 Claus e 1..* 0..1 +clause1..* 0..1 1 0..* +testOutput 1 0..* 0..* 0..* +bodyOutput0..* {ordered} 0..* 1 0..1 +clause1 0..1 0..* 0..* +predecessorClause 0..* +success orClause 0..* Action (from Action Foundation) 1 0..1 +body 1 0..1 1 0..1 +test 1 0..1 GroupAction mustIsolate : Boolean 0..* 0..1 +subaction 0..* +group 0..1 Variable multiplicity : Multiplicity ordering : OrderingKind 1 0..* +scope 1 +variable 0..* Classifier (from Core)0..* 0..10..* +type 0..1 Element (from Core) xor March 2003 OMG-Unified Modeling Language, v1.5 2-229 2 UML Semantics There are three kinds of composite action, each of which is treated in turn in the following subsections. Group actions group actions into larger units for use in procedures, conditionals, and loops. Conditional actions provide for contingent execution of subactions depending on a run-time test. All branches must have the same outputs. Loop actions permit the repeated execution of a subaction depending on a repeated run-time test, with outputs of one iteration used as inputs for the next iteration. 2.20.1.1 Available Inputs and Outputs A composite action may have input and output pins of its own that allow data flows to be connected directly to the composite action as a whole. However, composite actions may also allow some data flow connections to “cross the boundary” of the composite action and connect directly to pins on subactions within the composite. This allows the subactions so connected to access values computed in the context of the composite action, similar to the way in which scoped languages in an inner scope to access variables defined in an enclosing scope. The union of the set of input pins owned by a composite action and the set of input pins of subactions that may be the destination of data flows with sources outside the composite is called the set of available inputs of the composite action. Similarly, the union of the set of output pins owned by a composite action and the set of output pins of subactions that may be the source of data flows with destinations outside the composite is called the set of available outputs of the composite. The specification of each kind of composite action defines what the available inputs and outputs are for that kind of action. The concept of available inputs and outputs is important because when a composite action is viewed from the outside as a black box, it is the complete sets of available inputs and outputs that provide the allowable connection points to the action for data flows. Thus, the available inputs and outputs for a composite are generally defined in terms of the available inputs of its subactions, without any need to “look inside” the subactions if they are themselves composites. By definition, the available inputs and outputs of a primitive action are simply the input and output pins owned by that action. 2.20.1.2 Group Action The simplest form of composite action is the group action. A group action composes a set of subordinate actions into a higher-level unit. The actions may form a sequence, a concurrent set, or some combination of both. A group action does not own any pins of its own. Data flows are not connected to a group action, instead they may “cross the boundary” of a group action to connect to input and output pins of actions within the group, making the boundary of the group action “porous.” A group action does not encapsulate its contents, rather this approach to grouping focuses on convenience in organizing a computation, not encapsulation or decomposition. 2-230 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Since an input pin may be the destination of only one data flow, the available inputs of a group action are just the available inputs of its subactions that are not connected to other actions within the same group. Output pins, however, may be the source for multiple data flows, so the available outputs of a group action include all the available outputs of all the subactions. Group actions as a whole can be predecessors and successors in control flows, so they provide the ability to synchronize the execution of groups of actions. A control flow whose destination is a group action requires that the predecessor must complete before any action within the group action may begin. A control flow whose source is a group action requires that all actions within the group action must complete before the successor may begin. Control flows may also cross the boundary of a group action. These control flows are in addition to any control flows to or from the group action itself. A subordinate action may execute if it has all of its data inputs and all of its control flow inputs and if the group action itself has all of its control flow inputs. Similarly, an external successor of a subordinate action must wait until the subordinate action is complete, but it need not wait for the entire group action to complete (unless it is also a successor of the group action as a whole). 2.20.1.3 Conditional Action A conditional action provides the conditional execution of contained actions depending on the result of test actions. A conditional action consists of some number of clauses, each of which has an embedded test action and body action. Each clause designates an output pin of its test action as the test output. If it evaluates to true, the body is executed. Each clause designates a bank of output pins from its body that have conforming types and multiplicities to the output pins of the conditional action. In this way, the conditional action will produce the same types of output values, regardless of which clause body executes. If the body of a specific clause executes, then the values of the bank of output pins designated by the clause become the values of the output pins of the overall conditional action. Conditional actions provide the only points of “fan in” of data flow. This fan in within a conditional action does not violate the single assignment principle, since only one of the body actions can execute during any execution of the conditional action, so that each conditional output pin will receive only one value. Also, since exactly one body action must execute, each conditional output pin will always receive a value. A conditional action has no explicit input pins of its own. However, the inputs for all test actions must come from outside the conditional action. The inputs for a body action may come from either outside the conditional action, or from the outputs of the test action in the same clause (there are no data flows allowed between test and body actions in different clauses). The different test and body actions may or may not use the same input values. Thus, the available inputs of a conditional action include all available inputs of all test actions and the available inputs of body actions that are not already connected to the outputs of test actions. March 2003 OMG-Unified Modeling Language, v1.5 2-231 2 UML Semantics The output pins of a body action may not be directly connected to input pins outside the body action. The output pins of test actions may not be connected to input pins outside the clause. There are no explicit data flows from the output pins of the clauses to the output pins of the overall conditional action (since data flows can only connect output to input pins). The connection is implicit in the structure of the conditional action itself. Thus the only available outputs of a conditional action are the output pins explicitly owned by the conditional. The clauses of a conditional action may have noncyclic predecessor-successor relationships among them. Clauses with no predecessor-successor relationships may execute their test actions concurrently. If more than one of these is true, only one body action will execute, but its selection is indeterminate. If the tests are not guaranteed to be exhaustive, the user may provide a default action with a test of “true” as a successor of all other tests. A conditional is not required to have an explicit “else” clause, but the modeler must ensure that at least one test action is true or the model is incorrect. Note – One exception is allowed to the “exactly one body action must execute” rule. In the case that the conditional action has no output pins, then it is allowable for no body actions to execute (i.e., for all test actions to fail). In this case, any effect of the conditional action is by affecting object memory or the external world. This is equivalent to providing an “else” clause with an empty body. In cases when the tests in a conditional will be both exhaustive and mutually exclusive by design, the conditional action can be explicitly tagged as being “determinate.” In this case, exactly one concurrent test action must evaluate to true. Determinism is an assertion by the designer—if it is not correct, the model is ill formed. It can be achieved either by complete, explicit sequencing of the test actions or through the designer’s knowledge that tests that are not sequenced are mutually exclusive. The latter case does not imply a need for the run-time system to test that the other tests do indeed evaluate to false—the developer has the responsibility to guarantee mutual exclusion. 2.20.1.4 Loop Action The final kind of composite action is the loop action. The loop action provides for repeated execution of a contained action so long as a test action results in an appropriate value. A loop action contains a single clause with a test action and a body action. The body action is executed repeatedly as long as the test action yields “true.” The test and the body actions have access to the values of a set of “loop variables,” which are represented as an ordered set of output pins owned by the loop action. The loop variables may be connected to input pins of the test and body actions, thus providing the “current values” of the loop variables during a loop iteration. The clause designates a set of output pins within its body subaction. The types of these pins must conform to the types and multiplicities of corresponding loop variables. At the completion of execution of the body action, the values of these pins become the values of the loop variable pins for the next iteration of the loop. 2-232 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics The loop action also has a list of input pins and a list of output pins. Both lists must conform to the loop variable pins and the body output pins. Before the first execution of the loop clause, the values of the loop inputs become the values of the loop variables. During each iteration, the test action of the clause is executed. If its designated test output pin is false, then the values of the loop variable pins become the values of the output pins of the loop action, and the execution of the loop is complete. If the test value is true, the body action of the clause is executed. When it is complete, the body output values become the new values of the loop variables. The loop variables are not explicitly “reassigned” in the body action. Instead, the input and output pins for the body action hold the “old values” and the “new values” of the loop variables, respectively, during a single iteration. This preserves the single- assignment principle. There are no explicit dataflow connections from the loop input pins to the loop variable pins, from the body output pins to the loop variable pins, or from the loop variable pins to the loop output pins. The dataflow is implicit, based on the structure of the loop action itself. During execution of a loop action, the test action and the body action have access to output pins outside the loop action. For any one execution of the loop, the value on one of these pins will be fixed during all the iterations of the loop. Thus, the available inputs of a loop action include the input pins explicitly owned by the loop action, the available inputs of the test action that are not connected to loop variables and the available inputs of the body action that are not connected to loop variables or output pins of the test action. The output pins of the body action may not be directly connected to input pins outside the body action. The output pins of test actions may not be connected to input pins outside the single clause of the loop action. There are no explicit data flows from the output pins of the clause to the loop variables (since data flows can only connect output to input pins). The connection is implicit in the structure of the loop action itself. Thus the only available outputs of a loop action are the output pins explicitly owned by the loop. 2.20.1.5 Local Variables In addition to data flows, it is also possible to pass data between actions using local variables. A local variable is a slot for values shared by the actions within a group but not accessible outside it. The output of one action may be written to a variable and used as the input to a subsequent action, providing an indirect communication path. The inclusion of variables supports both traditional imperative programming and data- flow programming, as well as mixtures of the two styles. In an imperative style, the result of an action is placed in an object attribute or a local variable, and a subsequent action retrieves it. Because there is no explicit relationship between the actions, they must be sequenced by a control flow. And because there may be many reads and writes to a particular attribute or variable, there is a danger of conflict that must be considered and prevented by the specifier. March 2003 OMG-Unified Modeling Language, v1.5 2-233 2 UML Semantics In a purely imperative style in which each action is considered to operate on local variables, the UML action model uses data flows to connect read-variable or write- variable actions to the action actually performing the computation on these variables. The data flows in this case can be considered purely formal, and the different actions are otherwise disconnected and communicate by values in variables. In such an imperative style, local variables can also be used instead of data-flow outputs from conditional actions or loop variables in loop actions. For instance, the body of each clause of a conditional would update the variables that it changes and leave the others unchanged. Since there are no data-flow results from any clause, or from the conditional as a whole, all clauses automatically meet the conditional of having outputs consistent with the conditional outputs. 2.20.1.6 Isolation Because of the concurrent nature of the execution of actions within and across procedures, it can be difficult to guarantee the consistent access and modification of object memory. For example, suppose the temperature and pressure attributes of a tank object are being periodically updated by consistent sensor readings. Another procedure may involve reading these attributes in order to compute some current properties of the contents of the tank. But reading both attributes requires two separate read actions. It is possible that a concurrent update of the tank attributes could be interleaved with the two reads, resulting in the temperature and pressure values read not being consistent. As another example, consider reading a list of account balances, adding a fee amount to each one and then updating each balance. Any concurrent change to a balance before the fee update is complete could result in an inconsistent state. Further, concurrent accesses to the list could result in inconsistencies, with some balances updated but not others. In order to avoid these problems, it is necessary to isolate the effects of a group of actions from the effects of actions outside the group. This is indicated by setting the mustIsolate attribute to “true” on a group action. If a group action is isolated, then any object used by an action within the group cannot be accessed by any action outside the group until the group action as a whole completes. Any concurrent actions that would result in accessing such objects are required to have their execution deferred until the completion of the group action. In the first example above, if the read actions on the temperature and pressure attributes are wrapped in a group action with mustIsolate set to “true,” then the temperature and pressure values read are assured to be consistent, since no changes can intervene between the two reads. Similarly, if an isolated group is used for the second action, then the update is assured to be consistent, since no action outside the group can change the list until the update is complete. 2-234 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Note – The term “isolation” is used here in the sense used in traditional transaction terminology. An execution engine may achieve any required isolation using locking mechanisms, or it may simply sequentialize execution to avoid concurrency conflicts. Isolation is different than the property of “atomicity,” which is the guarantee that a group of actions either all complete successfully or have no effect at all. Atomicity generally requires a rollback mechanism to prevent committing partial results. This is beyond the scope of what can be guaranteed by the basic action semantics. 2.20.2 Composite Action Execution 2.20.2.1 Clause Execution Figure 2-42 shows the life cycle for the execution of a clause. Unlike an action, a clause does not have prerequisites, but it may have other predecessor clauses, which must be clauses in the same conditional action (a loop action has only one clause, which therefore may not have any predecessors). If a clause has one or more predecessors, then it must wait for these to complete. However, a clause only moves out of this waiting status if all of its predecessor clauses have completed with “false” outputs. If all the predecessor clauses of a clause complete with “false” outputs, then the clause’s test action is executed (assuming all data-flow prerequisites of the test action are satisfied). Once the test action has completed, then the clause either passes or fails the test, depending on the result of the test-action execution. The body of a clause is not automatically executed if the clause passes, since multiple clauses may pass in a conditional, but only one body is executed. The execution of clauses is separately modeled to capture the above special behavior associated with clause predecessors. Since only a clause in a conditional action may have other clauses as predecessors, clause execution need only be explicitly modeled for conditional actions. For loop actions, clauses simply provide a convenient syntactic grouping of the test and body actions of the loop and have no semantic significance. March 2003 OMG-Unified Modeling Language, v1.5 2-235 2 UML Semantics Figure 2-42 Life cycle for clause execution 2.20.2.2 Conditional Action Execution Figure 2-43 on page 2-237 shows the life cycle for the execution of a conditional action. As with a group action, a conditional action may only have control-flow prerequisites. Once these are satisfied, the clauses of the conditional action may begin executing. Once the clauses have completed execution, then the body of exactly one clause with status passed is executed, and the outputs of this body action become the outputs of the conditional action. (The one exception is in the case of a conditional action that has no outputs, in which case it is allowable for no clauses to pass.) We need to interpret “clause execution complete” carefully, as the tests of some clauses may never be executed, because one of its predecessors was successful or one or more of its predecessors never executed tests themselves. Thus, clause execution may be considered complete when every clause satisfies one of the following: • The clause has the status passed. • The clause has the status failed. waiting testing passed failed [ testOutput is true ] [ testOutput is false ] ready when( Test action execution is complete ) when( All predecessors have failed ) / Execute test action 2-236 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics • The clause has the status waiting and at least one predecessor with the status passed or waiting. (A clause with no predecessor clauses cannot meet this condition and therefore must execute in the “first wave.”) Since the execution of the clause tests must complete before a body is executed, there will be multiple steps in the history of a conditional execution in which it has the status executing. These correspond to the similarly named substates of the state executing shown in Figure 2-43. March 2003 OMG-Unified Modeling Language, v1.5 2-237 2 UML Semantics Figure 2-43 Life cycle for conditional-action execution waiting re a d y executing executingClauses executingBody testingClauses complete when( All prerequisites are satisfied ) executingClauses / Start clause executions executingBody when( Body execution complete ) / Copy the outputs of the body to the conditional outputs testingClauses when( Clause executions complete ) [ No clauses passed and the conditional has no outputs ] [ At least one clause passed ] / Execute the body of one of the clauses that passed 2-238 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.20.2.3 Loop Action Execution Figure 2-44 on page 2-239 shows the life cycle for the execution of a loop action. A loop action may have both control-flow and data-flow prerequisites, since a loop action may directly own input pins. Once these prerequisites have been satisfied, the values of the loop-action input pins are copied to the loop variables as their initial values and the loop test is executed. If the test output is “true:,” then the loop body is executed, its outputs are copied to the loop variables and the test is executed again. This continues until the loop test fails, in which case the loop variables are copied to the loop outputs and the loop is complete The iterative nature of a loop execution potentially results in a whole sequence of steps in its execution history in which it has the status executing. A loop execution with this status will cycle between the substatuses executingTest, testing, and executingBody (corresponding to the states in Figure 2-44) until the test fails, at which point it will move to status complete. March 2003 OMG-Unified Modeling Language, v1.5 2-239 2 UML Semantics Figure 2-44 The life cycle for loop-action execution 2.20.3 Composite Action Classes 2.20.3.1 Clause A clause is a part of a conditional or loop action. A clause contains a test action and a body action. Both are arbitrary actions (usually group actions) subject to connectivity constraints described under the various composite actions. The execution of the body action is contingent on the corresponding test action producing a “true” value. The waiting ready executing executingTest executingBody testing complete when( All prerequisites are satisfied ) executingTest executingBody / Copy loop inputs to loop variables; Execute clause test testing when( Body execution complete ) / Copy body outputs to loop variables; Execute clause test when( Test execution complete ) [ testOutput is true ] / Execute body [ testOutput is false ] / Copy loop variables to loop outputs 2-240 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics clause specifies one output pin of the test action, which must have type Boolean; the body action is only executed if this output produces the value “true” after execution of the test action. (Additionally, for a conditional, only one clause body is executed even if more than one of their tests is true.) The outputs of a clause are an ordered subset of the outputs of the body action. No other output of the body action may be connected outside the clause. Clauses within a conditional action may be linked by a set of (noncyclic) predecessor/successor relationships. The test action of a clause may not execute unless all the predecessors of the clause not only have completed execution, but have also “failed.” These relationships thus act, in effect, as specialized kinds of control flows. Neither the test or body actions of a clause can participate in any normal, explicit control flows. During execution of an enclosing loop action, a test action may not execute for the first time unless all predecessors of the loop action have executed. It may not execute for a subsequent time unless the previous execution of the body action is complete, that is, there is an implicit control flow between the execution of a body action and the next iteration of the test action. In a conditional or a loop action, a body action may not execute until its test action completes and yields “true.” Associations • test : Action [1..1] The action whose Boolean result (designated by testOutput) must be true for execution of the body action to proceed. • testOutput : OutputPin [1..1] The output pin of the test action whose value is the test result. If this value evaluates to “true,” the body action may begin execution. • body : Action [1..1] The action whose execution is contingent on the result of the test action being true. • bodyOutput : OutputPin [0..*] The ordered set of outputs of the body that are considered to be results of the clause. • predecessorClause : Clause [0..*] The set of clauses that must fail before this clause can execute its test action. • successorClause : Clause [0..*] The set of clauses that cannot execute their test actions unless this clause fails. March 2003 OMG-Unified Modeling Language, v1.5 2-241 2 UML Semantics Well-formedness Rules Note – The term “booleanType” is used here to indicate the Boolean enumeration type (instance of Enumeration). [1] The available outputs of the test action of a clause may not be connected to destinations outside the clause. self.test.subactions().availableInput->union(self.body.availableInput) ->includesAll(self.test.availableOutput.flow.destination) [2] The available outputs of the body action of a clause may not be connected to destinations outside the body action. self.body.subactions().availableInput->includesAll(self.body.availableOutput.flow.destination) [3] The testOutput of a clause must be an available output of the test action. self.test.availableOutput->includes(self.testOutput) [4] The testOutput pin must conform to type Boolean and multiplicity 1..1. self.testOutput.type = booleanType and self.testOutput.multiplicity.range->size = 1 and self.testOutput.multiplicity.range->forAll(r : MultiplicityRange | r.lower = 1 and r.upper = 1) [1] None of the actions within the test action of a clause (if any) may have control-flow connections with actions outside the test action. self.test.allSubactions()->forAll(action : Action | action.antecedent.predecessor->union(action.consequent.successor)->forAll(a : Action | a.isSubaction(self.test)) [2] None of the actions within the body action of a clause (if any) may have control-flow connections with actions outside the body action. self.body->allSubactions()->forAll(action : Action | action.antecedent.predecessor->union(action.consequent.successor)->forAll(a:Action | a.isSubaction(self.body)) [3] The test action of a clause may not participate in control flows. self.test.antecedent->isEmpty() and self.test.consequent->isEmpty() [4] The body action of a clause may not participate in control flows. self.body.antecedent->isEmpty() and self.body.consequent->isEmpty() [5] The body outputs of a clause must be available outputs of the body of the clause. self.body.availableOutput->includesAll(c.bodyOutput) [6] There cannot be any cycles in the predecessor/successor relationships among clauses. self.allClauseSuccessors()->excludes(self) 2-242 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Additional Operations Semantics A clause is executed as part of a conditional action or a loop action. See those actions for a description of how the clause is used in each case. 2.20.3.2 ConditionalAction A conditional action consists of a set of one or more clauses, exactly one of whose bodies is executed during any execution of the conditional action. If more than one clause has a test that yields “true,” exactly one of the corresponding body actions is selected for execution, but it is unspecified which one. (If the conditional action is declared to be determinate, this is an assertion that exactly one concurrent clause test will yield true.) The clause must have an ordered list of output pins that conform to the ordered list of output pins of the conditional. This list must be drawn from accessible outputs of the body action. The only outputs of the conditional action accessible outside it are the output pins directly owned by the conditional action. Attributes • isDeterminate : Boolean If true, then whenever the conditional action is executed, the execution of exactly one test action must result in “true.” (This is an assertion, not an executable property. If the assertion is violated by the action, the model is ill formed.) Associations • clause : Clause[1..*] The set of clauses contained in the conditional action. Inputs none. Note – There are no explicit input pins. Embedded actions may have input pins that are available inputs of the conditional action. [1] This operation returns the transitive closure of all successors of this clause. allClauseSuccessors() : Set(Clause) allClauseSuccessors() = self.successorClause- >union(self.successorClause.allClauseSuccessors()->asSet()) [2] This operation returns the available inputs of the test and body actions of a clause that are available outside the clause. clauseInputs() : Set(InputPin) clauseInputs() = self.body.availableInput->reject(i : InputPin | self.test.availableOutput- >includes(i.flow.source)) ->union(self.test.availableInput) March 2003 OMG-Unified Modeling Language, v1.5 2-243 2 UML Semantics Outputs • testOutput: Boolean [1..*] [These output pins are referenced by the Clause in the ConditionalActon but are not owned by it. They are owned by test actions within the clause.] A value used to control execution of the conditional body. If the value of a testOutput pin is true at the completion of execution of the test action of a clause, then the body action of the clause is a candidate for execution. Regardless of the number of clauses that produce true values, only one body action will be executed. The manner of selecting among multiple candidates is indeterminate. A test action may begin execution only if all of its predecessorClauses in the conditional action have completed execution and the value of all of their testOutput pins is false. If no clause produces a true test value during an execution of the conditional action, the model is ill formed. • bodyOutput: T [1..*], where T are user classes [These output pins are referenced by the Clause in the ConditionalActon but are not owned by it. They are owned by test actions within the clause.] The output values produced by the conditional body. The list of output pins for each clause must be equal in number and respective types to the list of output pins for the conditional action. At the completion of execution of the body action of the one clause selected for execution, the values on the output pins designated by that clause are copied onto the output pins of the conditional action. • output: T [0..*], where T are the same user classes as in bodyOutput [These output pins are owned by the ConditionalAction.] A list of zero or more values that are the only available outputs of the conditional action. At the completion of execution of the conditional action, each output pin has a value equal to the corresponding output pin of the clause that executed. Note – There are no available outputs of the conditional action except for the explicit output pins of the action itself. Well-formedness Rules [1] Each clause of a conditional action must have a number of outputs equal to the number of output pins of the conditional action. Each output of a clause must conform in type and multiplicity to the corresponding output of the conditional. self.clause->forAll(c : Clause | c.output->size() = self.outputPin->size() and Sequence{1..c.output->size()}->forAll(i : Integer | let cOutput : OutputPin = c.output->at(i) in let selfOutput : OutputPin = self.outputPin->at(i) in (cOutput.type = selfOutput.type or cOutput.type.allParents()->includes(selfOutput.type)) and cOutput.multiplicity.compatibleWith(selfOutput.multiplicity)) [2] The predecessors and successors of a clause in a conditional action must be clauses in the same conditional action. self.clause->includesAll(self.clause.predecessor->union(self.clause.successor)) 2-244 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Additional Operations A conditional execution represents the execution of a conditional action. Semantics A conditional execution represents the execution of a conditional action. 1. When the control and data flow prerequisites of a conditional action are satisfied, it enables its clauses. 2. Any clause lacking a predecessor clause may begin execution of its test subaction immediately. The test subactions of multiple clauses may execute concurrently. The test subaction of a clause with predecessors may execute if the execution of the test actions of all of its predecessor clauses completed and yielded false values for all test actions. 3. If the test action of any clause yields a true value, the body action of that clause may be executed. If multiple test actions yield true values, nevertheless only one body action will be executed, but the choice of which one to execute is not specified. [3] A conditional action owns no input pins. self.inputPin->isEmpty() [4] The available inputs of a conditional action are the union of the available inputs from all the clauses of the conditional action. self.availableInput = self.clause.clauseInputs() [5] The available outputs of a conditional action are the output pins of the conditional action. self.availableOutput = self.outputPin->asSet() [6] There may be no path from a conditional action to any action within the conditional action (where a path is defined as in rule [1] for Action and includes both data flows and control flows). self.allSuccessors()->excludesAll(self.clause.test.allSubactions()- >union(self.clause.body.allSubactions())) [1] The nested actions of a conditional action are the test and body actions of its clauses. nestedActions() : Set(Action) nestedActions() = self.clause.test->union(self.clause.body)->asSet() [2] A conditional action has no subactions. subactions() : Set(Action) subactions() = Set{} March 2003 OMG-Unified Modeling Language, v1.5 2-245 2 UML Semantics 4. When a body action completes execution, the values on the pins designated by the bodyOutput association from the clause containing the body action are copied to the output pins of the conditional action. Note that the list of bodyOutput pins and the list of output pins of the conditional action must match (well-formedness rule on the action). 5. If all clauses have been tested and no test value has been true, and the conditional action has no output pins, then the conditional execution completes execution and the control flow prerequisite is satisfied on any successor actions.If no test value has been true and the conditional action has one or more output pins, then the conditional action is ill formed and the behavior of the condition action is undefined. This represents an error in the model. 2.20.3.3 GroupAction A group action represents a simple composition of a set of subactions. A group action does not own any pins of its own, but data-flow connections may (generally) be made from actions outside the group to pins owned by actions within the group action. The group action as a whole may participate in control flows and actions within the group action may also participate in control flows with actions outside the group action. There is an implicit control flow from the group action to each action within it; this is important only if there is a control flow to the group action. Similarly, there is an implicit control flow from each action in the group action to the group action; this is important only if there is a control flow from the group action. Finally, a set of local variables can be declared in association with a group action. The group action serves as the scope for use of the variables. Attributes • mustIsolate : Boolean If true, then the actions in the group execute in isolation. Associations • subaction : Action [0..*] The set of actions contained in the group. • variable : Variable [0..*] The set of variables declared with the group as their scope. Inputs none Note – A group action has available inputs, but no explicit input pins. Its embedded actions may have input pins. Outputs none 2-246 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Note – A group action has available outputs, but no explicit output pins. Its embedded actions may have output pins. Well-formedness Rules Additional Operations Semantics Figure 2-45 on page 2-247 shows the life cycle for the execution of a group action. As with any action, a group execution becomes ready when the execution of all its prerequisite actions have completed. Since a group action does not directly own any inputs itself, it can only have control-flow prerequisites. The subactions within a group action may not start executing until the group execution as a whole is ready. A subaction may have its own prerequisite data and control flows that must be satisfied before the subaction may execute. In this sense, the group action is an additional prerequisite for all its subactions. The group execution maintains its executing status until all its subactions have completed. As individual subaction executions within the group execution complete, they trigger any data or control flows attached directly to them, independently of the completion of the group action as a whole. However, control flows with the group action itself as their source will not be triggered until the group execution reaches the complete status. [1] A group action does not own any pins. self.outputPin->isEmpty() and self.inputPin->isEmpty() [2] The set of available inputs of a group action is the union of the available inputs of all the subactions of the group action not connected within the group action to an available output of a subaction of the group action. self.availableInput = self.subaction.availableInput->asSet()->reject(i : InputPin | self.subaction.availableOutput.includes(i.flow.source)) [3] The set of available outputs of a group action is the union of the available outputs of all the subactions of the group action. self.availableOutput = self.subaction.availableOutput->asSet() [1] The nested actions of a group action are its subactions. nestedActions() : Set(Action) nestedActions() = self.subaction [2] A group action has explicit subactions. subactions() : Set(Action) subactions() = self.subaction March 2003 OMG-Unified Modeling Language, v1.5 2-247 2 UML Semantics A group action may also act as the scope for a set of local variables. The execution of the group action must therefore also maintain the state of those variables. A variable value associates a sequence of values with the variable, consistent with the multiplicity of the variable. As with pin values, the association of a variable with the instance values is via intermediate variable elements, which allow for the possibility of the variable containing duplicate values, and the ordering of these elements is only significant if the variable is marked as ordered. 1. A group action begins execution when all of its control flow prerequisites are satisfied. (A group action may not have data flow prerequisites.) When a group action begins execution, any variables declared in its scope are created with undefined values and all of its subactions are enabled. Any subactions without control or data flow prerequisites may begin execution immediately. Subactions with control or data flow prerequisites must wait until the prerequisites are satisfied. Figure 2-45 Life cycle for group-action execution waiting ready executing complete when( All prerequisites are satisfied ) / Create variables and start execution of subactions when( Subaction executions complete ) / D es troy variables 2-248 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2. When all of the subactions have completed execution, the execution of the group action is complete. The values of any variables declared in its scope are destroyed. Any control flow prerequisites in which the group action is a predecessor are satisfied. (A group action may not have data flow outputs.) Note – The execution model does not currently formalize the semantics of group actions with mustIsolate = true. 2.20.3.4 LoopAction A loop action contains a single clause whose test action and body action are executed repeatedly as long as the test action yields “true.” A list of output pins acts as “loop variables” for the loop action. The loop variables are not directly available outside the loop. Input pins of the overall loop action provide initial values that are copied into these loop variables before the first iteration of the loop. As output pins, the loop variables may be connected to available inputs of the test and body actions using normal data flows, to provide the “old values” of the loop variables during an iteration. The outputs of the loop clause provide “new values” that are copied to the loop variables at the completion of an iteration. The test is executed after the initial values are copied to the loop variables, and after each execution of the body action. The body action is executed only if the test yields true. When the loop terminates, the final values of the loop variables are copied to the regular output pins of the loop action, which are the only available outputs for the loop action as a whole. Associations • clause : Clause [1..1] The clause that contains the test and body actions for the loop. • loopVariable : OutputPin [0..*] The set of loop-action output pins that act as loop variables for the loop. These are owned directly by the loop action, but they are not available outside the loop. Inputs • loopVariableInput: T [0..*], where T are user classes [These input pins are owned by the LoopAction itself.] An ordered list of input pins holding values. Each pin can have a different type. The number and irrespective types of the pins must match the loop variable pins. These pins represent the initial values for the loop variables. During the first execution of the subaction, the loop variable pins hold copies of the values on the corresponding loop variable input pins. Outputs • result: T [0..*], where T are the classes as in loopVariableInput [These output pins are owned by the loop action itself.] An ordered list of output pins holding collections of output values. The number and type of each pin must match the corresponding loop variable input pin and loop variable pin. When the execution of the loop action is complete (because the test condition is false), the March 2003 OMG-Unified Modeling Language, v1.5 2-249 2 UML Semantics output pins have values equal to the values on the corresponding bodyOutput pins on the final execution of the body action. If the testOutput is false on first execution of the clause (which consequently does not execute the body action), the result pins have values equal to the values on the loopVariableInput pins. • loopVariable: T [0..*], where T are the same classes as in loopVariableInput [These output pins are owned directly by the LoopAction. These are internal output pins, visible only within the LoopAction itself.] An ordered list of output pins holding collections of output values. The number and type of each pin must match the corresponding loop variable input pin and result pin. During the first execution of the body action, the loopVariable pins have values equal to the values of the corresponding loopVariableInput pins. On each subsequent execution of the body action, each loopVariable pin has a value equal to the value of the corresponding body action output pin at the completion of the previous execution of the body action. The values of the loopVariable pins are available inputs of actions nested within the clause, including its test action and body action. • bodyOutput: T [0..*], where T are the same classes as in loopVariableInput [These output pins are owned by actions nested within the body action of the clause of the LoopAction. They are visible only within the LoopAction itself.] An ordered list of output pins holding collections of output values. The number and type of each pin must match the corresponding loop variable input pin and result pin. At the completion of each execution of the body action, each pin holds a value computed within the body action from its available inputs, including loop variable values. The value of each bodyOutput pin determines the value of the corresponding loopVariable pin on the subsequent execution of the body action and the corresponding result pin if the body action does not execute subsequently. The bodyOutput values are not otherwise available outside the body action itself. • testOutput : Boolean [These output pins are owned by an action nested within the test action of the loop action. They are visible only within the LoopAction.] An output pin holding a Boolean value computed within the test action of the clause of the loop action. During each iteration of the loop, the test action executes and the value on the testOutput pin determines whether the execution of the loop action is complete. If the value is false, execution is complete. If the value is true, the body action is executed again. 2-250 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Well-formedness Rules [1] The clause of a loop action must have the same number of outputs as the number of loop variables of the loop and each clause output in the ordered list must conform to the corresponding loop variable in type and multiplicity. self.clause.output->size() = self.loopVariable->size() and Sequence{1..clause.output->size()}->forAll(i : Integer | let clauseOutput : OutputPin = clause.output->at(i) in let v : OutputPin = self.loopVariable->at(i) in (clauseOutput.type = v.type or clauseOutput.type.allParents()- >includes(v.type)) and clauseOutput.multiplicity.compatibleWith(v.multiplicity)) [2] A loop action must have the same number of inputs pins as loop variables and each input pin must conform to the corresponding loop variable in type and multiplicity. self.inputPin->size() = self.loopVariable->size() and Sequence{1..self.inputPin->size()}->forAll(i : Integer | let p : InputPin = self.inputPin->at(i) in let v : OutputPin = self.loopVariable->at(i) in (p.type = v.type or p.type.allParents()->includes(v.type) and p.multiplicity.compatibleWith(v.multipicity)) [3] A loop action must have the same number of output pins as the number of loop variables and each loop variable in the ordered list must conform to the corresponding output pin (in order) in type and multiplicity. self.outputPin->size() =self. loopVariable->size() and Sequence{1..self.outputPin->size()}->forAll(i : Integer | let p : OutputPin = outputPin->at(i) in let v : OutputPin = loopVariable->at(i) in (v.type = p.type or v.type.allParents()->includes(p.type)) and v.multiplicity.compatibleWith(p.multipicity)) [4] The clause of a loop action may not have predecessors or successors. self.clause.predecessor->isEmpty() and self.clause.successor->isEmpty() [5] The set of available inputs of a loop action is the union of the loop-action input pins and the available inputs of the clauses of the loop action that are not connected to loop variables. self.availableInput = self.inputPin->union(self.clause.clauseInputs() ->reject(i : InputPin | self.loopVariable->includes(i.flow.source))) [6] The available outputs of a loop action are the output pins of the loop action. self.availableOutput = self.outputPin [7] There may be no path from a loop action to any action within the loop action (where a path is defined as in Rule [1] under Action). self.allSuccessors()->excludesAll(self.clause.test.allSubactions()- >union(self.clause.body.allSubactions())) March 2003 OMG-Unified Modeling Language, v1.5 2-251 2 UML Semantics Additional operations Semantics 1. When all control flow and data flow prerequisites of a loop action are satisfied, the execution of the loop begins. All of the values on input pins of the loop execution are copied into a set of loop variable values owned by the loop execution. The execution of the clause owned by the loop action begins. 2. When the execution of a clause begins, its test subaction is executed. 3. When the test action has completed execution, if the test action yields a false value for its testOutput pin, the loop execution completes. The values of the loop variables are copied to the loop output pins. 4. When the test action has completed execution, if the test action yields a true value, the body action of the clause is executed. Before execution begins, any control flow conditions, data flow values, or variables in the scope of the action from any previous iterations of the body action are cleared. 5. When the body action has completed execution, the values on the output pins of the body action are copied to the values of the loop variables. Then the test action is executed again. 2.20.3.5 Variable A variable is the specification of a data slot that represents a local variable shared by the actions within a group. There are actions to write and read variables. These actions are treated as side effect actions, similar to the actions to write and read object attributes and associations. There are no automatic sequencing constraints among actions that access the same variable. Such actions must be explicitly sequenced by control flows (unless their sequencing follows from other constraints anyway). Any values contained by a variable must conform to the type of the variable and have cardinalities allowed by the multiplicity of the variable. A variable without a type specification can hold any value. Attributes • multiplicity : Multiplicity A specification of the number of values a variable execution may hold at any one time. [1] The nested actions of a loop action are its test and body actions. nestedActions() : Set(Action) nestedActions() = Set{self.clause.test, self.clause.body} [2] A loop action has no subactions. subactions() : Set(Action) subactions() = Set{} 2-252 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics • ordering : OrderingKind Indicates whether the set of values held by this variable is to be considered ordered or not. Associations • scope : GroupAction [1..1] The group action that owns the variable. • type : Classifier [0..1] A classifier specifying the allowed classifiers of values held by the variable. The actual classifier of a value must conform to the type specification of the variable. Additional Operations 2.21 Read and Write Actions Objects, attributes, links, and variables have values that are available to actions. Objects have classifiers and they can be created and destroyed; attributes and variables have values; links can be created and destroyed, have object ends and qualifier values; all of which are available to actions. Read actions get values, while write actions modify values and create and destroy objects and links. Read and write actions share the structures for identifying the attributes, links, and variables they access. Objects, attributes, links, and variables each have their own section in this chapter. Following the philosophy of providing simple actions from which languages can compose powerful constructs, read actions do not modify the values they access, while write actions have the minimum possible effect. For example, creating an object does not execute constructors. Languages requiring higher-level semantics can define higher-level actions from the primitive ones given here. When an action violates those aspects of static UML modeling that constrain runtime behavior, the semantics is left undefined. For example, an attempt to create an instance of an abstract class is undefined: some languages may make this action illegal, others may create a partial instance for testing purposes. The semantics are also left undefined in situations that require classes as values at runtime. The only exception is minimum multiplicity, which is defined to be equivalent to the lower multiplicity being zero. Runtime situations violating minimum multiplicity do not conform to their model, but are necessary to allow intermediate stages of initializing runtime objects. The modeler must determine when minimum multiplicity should be enforced. [1] This operation checks whether the given action is within the scope of this variable. isAccessibleBy(a : Action) : Boolean isAccessibleBy(a) = self.scope.allNestedActions()->includes(a) March 2003 OMG-Unified Modeling Language, v1.5 2-253 2 UML Semantics Figure 2-46 Object Action metamodel 2.21.1 Object Actions The only properties an object has directly are its classes and whether it exists or not. All the other aspects of an object are handled through other elements, such as attributes and associations. This section covers the direct properties of objects. CreateObjectAction creates an object that conforms to a statically specified classifier and puts it on an output pin at runtime. DestroyObjectAction destroys the object on its input pin at runtime. When the object is also a link object, the link is also destroyed with the same semantics as a DestroyLinkAction. ReclassifyObjectAction adds and removes statically specified classifiers to and from the object given on its input pin at runtime. It supports adding and removing multiple classifiers at a time. No constructors or destructors are executed by the object actions, nor is there any effect on the state machines of the object. It has the option of removing all existing classifiers of the object before new ones are added. ReadIsClassifiedObject determines whether an object is classified by a classifier that is specified at modeling time, either as a direct instance or indirect descendant of the classifier. The actions on objects in general are applicable to link objects. See descriptions of classes for more information on their semantics. PrimitiveAction (from Action Foundation) DestroyObjectAction InputPin (from Acti on Foun dat io n) OutputPin (from Action Foundation) InputPin (from Acti on Foun dat io n) 1 0..1 +/input 1 0..1 ReadIsClassifiedObjectAction isDirect : Boolean 1 0..1 +/input 1 0..1 1 0..1 +/result 1 0..1 ReclassifyObjectAction isReplaceAll : Boolean 1 0..1 +/input 1 0..1 OutputPin (from Action Foundation) Classifier (from Core) 1 +classifier 1 0..* 0..* +newClassifier 0..* 0..* 0..* 0..* +oldClassifier 0..* 0..* CreateObjectAction 1 0..1 +/result 1 0..1 1 0..* +classifier 1 0..* 2-254 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.21.2 Attribute Actions Figure 2-47 Attribute action metamodel Attributes have values that can be read or written, as modeled in Figure 2-47 on page 2-254. The abstract metaclass AttributeAction statically specifies the attribute being accessed. The object to access is specified dynamically, by referring to an input pin on which the object will be placed at runtime. The type of the value of this pin is the classifier that owns the specified attribute, and the value’s multiplicity is 1..1. When an attribute is read with ReadAttributeAction, the values of the attribute of the input object are placed on the output pin of the action. The type and ordering of the output pin are the same as the specified attribute. The multiplicity of the attribute must be compatible with the multiplicity of the output pin. For example, the modeler can set the multiplicity of this pin to support multiple values even when the attribute only allows a single value. This way the action model will be unaffected by changes in the multiplicity of the attribute. Adding a value with AddAttributeValueAction has the option of removing existing values of the attribute beforehand, even if the value already exists. Attributes can also have all values removed with no new values added, using ClearAttributeAction. The semantics of adding a value that violates the maximum multiplicity of the attribute is undefined. Removing a value succeeds even when that violates the minimum multiplicity—the same as if the minimum were zero. The same applies to clearing the attribute. The modeler must determine when minimum multiplicity of attributes should be enforced. InputPin (from Action Foundation) AttributeAction 10..1 +/object 10..1Attribute (from Core) 0..*1 0..* +attribute 1 PrimitiveAction (from Action Foundation) OutputPin (from Action Foundation) ReadAttributeAction 1 0..1 +/result 1 0..1 RemoveAttributeValueAc tion WriteAttributeAction InputPin (from Acti on Foundation) 1 0..1 +/value1 0..1 AddAttributeValueAction isReplaceAll : Boolean 0..1 0..1 +/insertAt 0..1 0..1 ClearAttributeAction March 2003 OMG-Unified Modeling Language, v1.5 2-255 2 UML Semantics Values of an attribute may be ordered or unordered, even if the multiplicity maximum is 1. The insertion point for adding new values to ordered attributes is specified at runtime by an additional input pin. The insertion point is a positive integer giving the position to insert the value, or the special value unlimited, to insert at the end. Reinserting an existing value at a new position moves the value to that position. (This works because attribute values are sets.) The insertion point is required for ordered attributes and omitted for unordered attributes. The semantics of actions that read and write attributes with classifier ownerScope or targetScope is undefined. The attributes of an object may change over time due to dynamic classification. However, the attribute specified in an attribute action is inherited from a single classifier, and it is assumed that the object passed to an attribute action is classified by that classifier directly or indirectly. The attribute is referred to as a user model element, so it is uniquely identified, even if there are other attributes of the same name on other classifiers. 2.21.3 Association Actions In the following discussion, “associations” does not include those modeled with association classes, unless specifically indicated. Similarly, a “link” is not a link object unless specifically indicated. The actions on objects in general are applicable to link objects. The term “link end object” or “end object” refers to the object participating in a link at a particular end. The semantics of actions that read and write associations that have any end with classifier targetScope is undefined. Figure 2-48 Link identification metamodel rimitiveA ction (from Action Foundation) In p u t P i n (from Action Foundation) QualifierValue0..1 1 0..1 +/value 1 Link Action Attribute from C or e) 0..* 10..* +qualifier 1 Association from C or e) LinkEndData 0..10..1 0..1 +/value 0..1 1 0..* 1 +qualifier0..* 2..* 1 +endData2..* 1 AssociationEnd (from Core) 0..1 n +associationEnd0..1 +qualifiern {ordered} 2..* 1 +connection2..* 1 0..* 10..* +end 1 2-256 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.21.3.1 Identifying a Link A link cannot be passed as a runtime value to or from an action. Instead, a link is identified by its end objects and qualifier values, as required. This requires more than one piece of data, namely, the static end in the user model, the object on the end, and the qualifier values for that end. These pieces are brought together around LinkEndData. Each association end is identified separately with an instance of the LinkEndData class. For write actions, all association ends must have a corresponding input pin so that all end objects are specified when creating or deleting a link. An input pin identifies the end object by being given a value at runtime. It has the type of the association end and multiplicity of 1..1, since a link always has exactly one object at its ends. Read actions omit exactly one input pin for an object end. The model, shown in Figure 2-48, therefore abstracts the association to an input to be optional. When a qualifier must be specified, the input pin for the qualifier attribute has a type given by that qualifier, and multiplicity of 1..1. 2.21.3.2 Navigating Across an Association Navigation of a binary association requires the specification of the source end of the link. The target end of the link is not specified. When qualifiers are present, one navigates to a specific end by giving objects for the source end of the association and qualifier values for all the ends. These inputs identify a subset of all the existing links of the association that match the end objects and qualifier values. The result is the collection of objects for the end being navigated towards, one object from each identified link. Figure 2-49 shows the model for a ReadLinkAction, generalized for n-ary associations. One of the link-end data must have an unspecified object (the “open” end). The result of the action is a collection of objects on the open end of links of the association, such that the links have the given objects and qualifier values for the other ends and the given qualifier values for the open end. This result is placed on the output pin of the action, which has a type and ordering given by the open end. The multiplicity of the open end must be compatible with the multiplicity of the output pin. For example, the modeler can set the multiplicity of this pin to support multiple values even when the open end only allows a single value. This way the action model will be unaffected by changes in the multiplicity of the open end. The semantics are defined only when the open end is navigable, and visible to the host object of the action. March 2003 OMG-Unified Modeling Language, v1.5 2-257 2 UML Semantics Figure 2-49 Read-link action metamodel 2.21.3.3 Reading Link Objects Figure 2-50 Read link object action metamodel Link Action LinkEndData1 2..*1 +endData 2..* OutputPin (from A ct ion Fou ndation) ReadLinkAction 10..1 +/result 10..1 PrimitiveAction (from Action Foundation) AssociationEnd (from Core) ReadLinkObjectEndAction 0..1 +end 0..1 Attribute (from Core) 0..1 n +associationEnd 0..1 +qualifier n{ordered} utputPin (from Ac tion Foundation) 1 ..1 +/result 1 ..1 InputPin (from Action Foundation) 1 0..1 +/object 1 0..1 ReadLinkObjectQualifierAction 0..1 1 0..1 +qualifier1 1 0..1 +/result 1 0..1 1 0..1 +/object 1 0..1 PrimitiveAction (from A ction Foundation) 2-258 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Link objects are instances of association classes. They have their own identity because they are objects, so it is possible to read the end objects and qualifier values of a link object in a more direct fashion than for ordinary links. Figure 2-50 shows the model for link object reading actions. ReadLinkObjectEndAction reads a link object to retrieve an end object. The association end to retrieve the object from is given statically, and the link object to read is provided on the input pin at run time. ReadLinkObjectQualifierAction determines the association end through a qualifier attribute, which UML restricts to being on exactly one association end, and returns the value of the qualifier attribute. For both actions, the input and output pins have multiplicity 1..1. Qualifier attributes must have exactly one value. The type of the output pin is the type of the specified association end for ReadLinkObjectEndAction, and the type of the qualifier attribute for ReadLinkObjectQualifierAction. 2.21.3.4 Writing Links Figure 2-51 Write link action metamodel DestroyLinkAction WriteLinkAction OutputPin (f r om Ac tion Fou nda tio n) CreateLinkObjectAction 10..1 +/result 10..1 LinkEndData LinkAction 2..* 1 +endData 2..* 1 PrimitiveAction (from Action Foundation) CreateLinkAction InputPin (f rom Action Foundation) LinkEndCreationData isReplaceAll : Boolean 2..* 1 +/endData 2..* 1 0..1 0..1 +/ins er tAt0..1 0..1 InputPin (f r om Ac ti on F ou nda tio n) Association (f rom C ore) ClearAssociationAction 1 0..1 +/object 1 0..1 1 0..1 +association 1 0..1 March 2003 OMG-Unified Modeling Language, v1.5 2-259 2 UML Semantics Figure 2-51 shows the classes for creating and destroying links. Both inherit the elements for identifying associations from LinkAction (see Subsection ”Identifying a Link”). Both inherit well-formedness rules from WriteLinkAction. CreateLinkAction can be used to create links and link objects. In neither case is the created link object returned. This has the happy effect of requiring no change of the action if the association is changed to an association class or vice versa. CreateLinkAction uses a specialization of LinkEndData called LinkEndCreationData, to support ordered associations and for replacing all links at an end. The insertion point is specified at runtime by an additional input pin, which is required for ordered association ends and omitted for unordered ends. The insertion point is a positive integer giving the position to insert the link, or the special value unlimited, to insert at the end. Reinserting an existing end at a new position moves the end to that position. CreateLinkAction also supports the destruction of existing links of the association that connect any of the objects of the new link. When the link is created, this option is available on an end-by-end basis, and causes all links of the association emanating from the specified ends to be destroyed before the new link is created. CreateLinkObjectAction is exclusively for creating links of association classes. It returns the created link object. DestroyLinkAction deletes links, including link objects. ClearAssociationAction destroys all links of an association in which an object given at runtime participates. Creating a link that violates the maximum multiplicities of the association has undefined semantics. The semantics of destroying a link that violates the minimum multiplicities of the association is that same as if the minimum were zero, that is, the link is destroyed. The modeler must determine when minimum multiplicity of associations should be enforced. 2.21.4 Variable Actions Variables have values that can be read or written, as modeled in Figure 2-52 on page 2-260. The abstract metaclass VariableAction statically specifies the variable being accessed. Variable actions can only access variables within the procedure of which the action is a part. When a variable is read with ReadVariableAction, the values of the variable are placed on the output pin of the action. The type and ordering of the output pin are the same as the specified variable. The multiplicity of the variable must be compatible with the multiplicity of the output pin. For example, the modeler can set the multiplicity of this pin to support multiple values even when the variable only allows a single value. This way the action model will be unaffected by changes in the multiplicity of the variable. Adding a value with AddVariableValueAction has the option of removing existing values of the variable beforehand, even if the value already exists. Variables can also have all values removed with no new value added, using ClearVariableAction. 2-260 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics The semantics of adding a value that violates the maximum multiplicity of the variable is undefined. Removing a value succeeds even when that violates the minimum multiplicity—the same as if the minimum were zero. The same applies to clearing the variable. Values of a variable may be ordered or unordered, even if the multiplicity maximum is 1. The insertion point for adding new values to ordered variables is specified at runtime by an additional input pin. The insertion point is a positive integer giving the position to insert the value, or the special value unlimited, to insert at the end. Reinserting an existing value at a new position moves the value to that position. (This works because variable values are sets.) The insertion point is required for ordered variables and omitted for unordered variables. Figure 2-52 Variable action metamodel 2.21.5 Other Actions Additional actions support navigation to the object hosting the action, reading of the extent of a classifier, and starting the state machines of an object. Figure 2-53 on page 2-261 shows the model for these actions. Every action is ultimately a part of some procedure, which in turn is attached in some way to the specification of a classifier—for example as the body of a method or as part of a state machine. When the procedure executes, it does so in the context of some specific host instance of that classifier. ReadSelfAction produces this host instance on its output pin. The type of the PrimitiveAction (from Action Foundation) Variable (from Composite Actions) VariableAction 10..* +variable 10..* OutputPin (from Action Foundation) ReadVariableAction 1 0..1 +/result 1 0..1 RemoveVariableValueAction WriteVariableAction InputPin (from Action Foundation) 1 0..1 +/value 1 0..1 AddVariableValueAction isReplaceAll : Boolean 0..1 0..1 +/insertAt 0..1 0..1 ClearVariableAction March 2003 OMG-Unified Modeling Language, v1.5 2-261 2 UML Semantics output pin is the classifier to which the procedure is statically associated. ReadExtentAction reads the current extent of a given classifier. StartObjectStateMachineAction puts the state machines of an object in their top state, if they have not been there already. This can only be used once per object. CallProcedureAction starts a procedure passing inputs, and waiting for outputs if it is synchronous. Note – The extent of a classifier is the set of all instances of a classifier that exist at any one time. It is not generally practical to require that reading the extent produce all the instances of the classifier that exist in the entire universe. Rather, any real execution engine will manage only a limited subset of the theoretical extent of any classifier and may actually manage multiple distributed extents for any one classifier. It is not formally specified in general by the execution semantics which managed extent is actually read by a read-extent action. Figure 2-53 Other action metamodel 2.21.6 Additional OCL Operations for Read and Write Actions Some additional OCL operations are defined for this chapter. Action [1] procedure operates on Action. It returns the procedure containing the action. procedure() : Procedure; procedure = if self.ProcedureÆsize() > 0 then self.Procedure else self.group.procedure() endif ReadSelfActionClass ifier (from Core ) ReadExtentAction 1 0..1 +classifier 10..1 PrimitiveAction (from Acti on Foun datio n) StartObjectS tateM achineAction OutputPin (from Action Foundation) 1 0..1 +/result 1 0..1 1 0..1 +/result1 0..1 InputPin (from Action Foundation) 1 0..1 +/input1 0..1 CallProcedureA ction isSynchronous : Boolean 0..* 0..1 0..* 0..1 0..* 0..1 0..* 0..1 Procedure (from Common Behavior) 11 +procedure +/input +/output 2-262 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Procedure [1] hostClassifier operates on Procedure. It returns the classifier hosting the procedure. This is the classifier on which the procedure is defined as a method, action in a state machine, sender of a message in a collaboration, or sender of a stimulus in a CollaborationInstance. hostClassifier() : Classifier; hostClassifier = if self.Method->size() > 0 then self.Method.owner else if self.State->size() > 0 then self.oclAsType(StateVertex).hostClassifier() else if self.Transition->size() > 0 then self.Transition.source.hostClassifier() else if self.Message->size()>0 then self.Message.sender.base else if self.Stimulus->size>0 then self.Stimulus.sender.classifier endif endif endif endif [2] hostElement operates on Procedure. It returns the “innermost” element in the user model that is hosting the procedure. This will be either a Method, State, Transition, Message, or Stimulus. hostElement() : ModelElement; hostElement = if self.Method->size() > 0 then self.Method else if self.State->size() > 0 then self.State else if self.Transition->size() > 0 then self.Transition else if self.Message->size()>0 then self.Message else if self.Stimulus->size>0 then self.Stimulus endif endif endif endif endif March 2003 OMG-Unified Modeling Language, v1.5 2-263 2 UML Semantics StateVertex 2.21.7 Read and Write Action Classes 2.21.7.1 AddAttributeValueAction This action adds values to attributes. Attributes are potentially multi-valued. It also supports the removal of existing values of the attribute before the new value is added. If the new value already exists, then it is not removed under this option. Otherwise, adding an existing value has no effect. The semantics is undefined for adding a value that violates the upper multiplicity of the attribute. The semantics is undefined for adding a new value for an attribute with changeability frozen after initialization of the owning object. Adding values to ordered attributes requires an insertion point for a new value using the insertAt input pin. The pin is of type UnlimitedInteger. A positive integer less than or equal to the current number of values means to insert the new value at that position in the sequence of existing values, with the integer one meaning the new value will be first in the sequence. A value of unlimited for insertAt means to insert the new value at the end of the sequence. The semantics is undefined for a value of zero or an integer greater than the number of existing values. The insertAt input pin does not exist for unordered attributes. Reinserting an existing value at a new position moves the value to that position. Attribute • isReplaceAll : Boolean [1..1] Specifies whether existing values of the attribute of the object should be removed before adding the new value. Associations • insertAt : InputPin [0..1] (Derived from Action:inputPin) Gives the position at which to insert a new value or move an existing value in ordered attributes. This pin is omitted for unordered attributes. [1] hostClassifier operates on StateVertex. It returns the classifier hosting the state machine of the vertex. hostClassifier() : Classifier; hostClassifier = if self.top->size() > 0 then if self.top.context.oclIsType(Classifier) then self.top.context endif else self.container.hostClassifier() endif 2-264 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Inputs • value : T [1..1], where T is self.attribute.type (Inherited from WriteAttributeAction) Value of attribute to add. Its type is the same as the type of the attribute. • insertAt : UnlimitedInteger [0..1] Position at which to insert a new value or move an existing value in ordered attributes. This pin is omitted for unordered attributes. • object : U [1..1], where U is self.attribute.owner (Inherited from AttributeAction) Object to which to add a value. Its type is the same as the type of the owner of the attribute being written. Outputs None. Well-formedness rules 2.21.7.2 AddVariableValueAction This action adds values to variables. Variables are potentially multi-valued. It also supports the removal of existing values of the attribute before the new value is added. If the new value already exists, then it is not removed under this option. Otherwise, adding an existing value has no effect. The semantics is undefined for adding a value that violates the upper multiplicity of the variable. Adding values to ordered variables requires an insertion point for a new value using the insertAt input pin. The pin is of type UnlimitedInteger. A positive integer less than or equal to the current number of values means to insert the new value at that position in the sequence of existing values, with the integer one meaning the new value will be first in the sequence. A value of unlimited for insertAt means to insert the new value at the end of the sequence. The semantics is undefined for a value of zero or an integer greater than the number of existing values. The insertAt input pin does not exist for unordered variables. Reinserting an existing value at a new position moves the value to that position. [1] Actions adding a value to ordered attributes must have a single input pin for the insertion point with type UnlimitedInteger and multiplicity of 1..1, otherwise the action has no input pin for the insertion point. let insertAtPins : Collection = self.insertAt in if self.attribute.ordering = #unordered then insertAtPins->size() = 0 else let insertAtPin : InputPin = insertAts->asSequence()->first() in insertAtPins->size() = 1 and insertAtPin.type = UnlimitedInteger and insertAtPin.multiplicity.is(1,1)) endif March 2003 OMG-Unified Modeling Language, v1.5 2-265 2 UML Semantics Attributes • isReplaceAll : Boolean [1..1] Specifies whether existing values of the variable should be removed before adding the new value. Associations • insertAt : InputPin [0..1] (Derived from Action:inputPin) The input pin giving the position at which to insert values into an ordered variable. This pin is omitted for unordered variables. Inputs • value : T [1..1] , where T is self.variable.type (Inherited from WriteVariableAction) Value to add. Its type is the same as the type of the variable. • insertAt : UnlimitedInteger [0..1] The position at which to insert values into an ordered variable. This pin is omitted for unordered variables. Outputs None. Well-formedness rules 2.21.7.3 AttributeAction (abstract) An attribute action operates on a statically specified attribute of some classifier. The action requires an object on which to act, provided at runtime through an input pin. The semantics is undefined for accessing an attribute that violates its visibility. The semantics is undefined for attributes with ownerScope or targetScope equal to classifier. [1] Actions adding values to ordered variables must have a single input pin for the insertion point with type UnlimitedInteger and multiplicity of 1..1, otherwise the action has no input pin for the insertion point. let insertAtPins : Collection = self.insertAt in if self.variable.ordering = #unordered then insertAtPins->size() = 0 else let insertAtPin : InputPin = insertAts->asSequence()->first() in insertAtPins->size() = 1 and insertAtPin.type = UnlimitedInteger and insertAtPin.multiplicity.is(1,1)) endif 2-266 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes • isSynchronous: Boolean [1..1] Specifies whether the execution of the action waits for the started procedure to finish before continuing. Associations • attribute : Attribute [1..1] Attribute to be read. • object : InputPin [1..1] (Derived from Action:inputPin) Gives the input pin from which the object whose attribute is to be read or written is obtained. Must be of the same type as the attribute. Well-formedness rules 2.21.7.4 CallProcedureAction This action starts a statically-specified procedure, passing inputs, and waiting for outputs if it is synchronous. Associations • calledProcedure: Procedure [1..1] Procedure to be started. • input: InputPin [0..*] (Derived from Action:inputPin) Gives the input pin from which is obtained the inputs for starting the procedure. [1] The attribute must have an ownerScope of instance. self.attribute.ownerScope = #instance [2] The attribute must have a targetScope of instance. self.attribute.targetScope = #instance. [3] The type of the input pin is the same as the type of the object owning the attribute. self.object.type = self.attribute.owner [4] If the action has an input pin, then its multiplicity must be 1..1. self.object→forall(multiplicity.is(1,1)) [5] Visibility of attribute must allow access to the object performing the action. let host : Classifier = self.procedure().hostClassifier() in self.attribute.visibility = #public or host = self.attribute.owner.type or (self.attribute.visibility = #protected and host.allSupertypes→includes(self.owner.type))) March 2003 OMG-Unified Modeling Language, v1.5 2-267 2 UML Semantics • output: OutputPin [0..*] (Derived from Action:outputPin) Gives the output pin from which is obtained the outputs of a synchronously started procedure. Inputs • input: T [0..*], where T matches the order and types of the procedure inputs. Outputs • output: T [0..*], where T matches the order and types of the procedure outputs. Well-formedness rules 2.21.7.5 ClearAssociationAction This action destroys all the links of an association in which a particular object participates. This action has a statically-specified association end. It has an input pin for a runtime object that must be of the same type as at least one of the association ends of the association. All links of the association in which the object participates are destroyed even when that violates the minimum multiplicity of any of the association ends. If the association is a class, then link object identities are destroyed. Associations • association : Association [1..1] Association to be cleared. • object : InputPin [1..1] (Derived from Action:inputPin) Gives the input pin from which is obtained the object whose participation in the association is to be cleared. [1] Asynchronous calls can have no output pins. self.isSynchronous = #false implies self.output->size() = 0 [2] The number, type, and order of the input and output pins must be the same as the number, type, and order of the procedure inputs and outputs. self.input->size( ) = self.calledProcedure.argument->size( ) and Sequence {1..self.input->size( )} -> forAll (i:Integer | let inputi = self.input->at(i) in let argi = self.calledProcedure.argument->at(i) in inputi.type = argi.type) and self.output->size( ) = self.calledProcedure.result->size( ) and Sequence {1..self.calledProcedure.result->size( )} - > forAll (i:Integer | let outputi = self.output->at(i) in let resulti = self.calledProcedure.result>at(i) in outputi.type = resulti.type) 2-268 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Inputs • object : T [1..1], where T is the type of at least one of self.association.end.participant The object on which to clear the association. It must be of the same type as at least one of the association ends of the association. Outputs None. Well-formedness rules 2.21.7.6 ClearAttributeAction This action removes all values of an attribute. All values are removed even when that violates the minimum multiplicity of the attribute. The semantics is undefined if the attribute changeability is addonly, or the attribute changeability is frozen after initialization of the object owning the attribute, unless the attribute has no values. Inputs • object : T [1..1], where T is self.attribute.owner (Inherited from AttributeAction) The object on which to clear the attribute. It must be of the same type as the owner of the attribute. Outputs None. 2.21.7.7 ClearVariableAction This action removes all values of a variable. All values are removed even when that violates the minimum multiplicity of the variable. Inputs None Outputs None. [1] The type of the input pin must be the same as the type of at least one of the association ends of the association. self.association->exists(connection.participant = self.object.type) [2] The multiplicity of the input pin is 1..1. self.object.multiplicity.is(1,1) March 2003 OMG-Unified Modeling Language, v1.5 2-269 2 UML Semantics 2.21.7.8 CreateLinkAction This action creates a link or link object for an association or association class. This action has no output pin, because links are not necessarily values that can be passed to and from actions. When the action creates a link object, the object could be returned on output pin, but it is not for consistency with links. This allows actions to remain unchanged when an association is changed to an association class or vice versa. The semantics of CreateLinkObjectAction applies to creating link objects with CreateLinkAction. This action also supports the destruction of existing links of the association that connect any of the objects of the new link. This option is available on an end-by-end basis, and causes all links of the association emanating from the specified ends to be destroyed before the new link is created. If the link already exists, then it is not destroyed under this option. Otherwise, recreating an existing link has no effect. The semantics is undefined for creating a link for an association class that is abstract. The semantics is undefined for creating a link that violates the upper multiplicity of one of its association ends. A new link violates the upper multiplicity of an end if the cardinality of that end after the link is created would be greater than the upper multiplicity of that end. The cardinality of an end is equal to the number of links with objects participating in the other ends that are the same as those participating in those other ends in the new link, and with qualifier values on all ends the same as the new link, if any. The semantics is undefined for creating a link that has an association end with changeability frozen after initialization of the other end objects, unless the link being created already exists. Objects participating in the association across from an unfrozen end can have links created as long as the objects across from the frozen ends are still being initialized. This means that objects participating in links with two or more frozen ends cannot have links created unless all the linked objects are being initialized. Creating ordered association ends requires an insertion point for a new link using the insertAt input pin of LinkEndCreationData. The pin is of type UnlimitedInteger with multiplicity of 1..1. A pin value that is a positive integer less than or equal to the current number of links means to insert the new link at that position in the sequence of existing links, with the integer one meaning the new link will be first in the sequence. A value of unlimited for insertAt means to insert the new link at the end of the sequence. The semantics is undefined for value of zero or an integer greater than the number of existing links. The insertAt input pin does not exist for unordered association ends. Reinserting an existing end at a new position moves the end to that position. Associations • endData : LinkEndCreationData [2..*] (Derived from LinkAction:endData) Specifies ends of association and inputs. 2-270 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Inputs • endData.value : T [2..*], where T are self.endData.end.participant (Inherited from LinkAction) Gives the object at the association end. It is of the same type as the end. • endData.qualifier.value : U [0..*], where U are self.endData.end.qualifier.type (Inherited from LinkAction) Gives the qualifier value of an association end if the end is qualified. It is the same type as the qualifier attribute. See LinkEndData. • endData.insertAt : UnlimitedInteger [0..1] Gives insertion point for ordered association ends. This pin is omitted for unordered ends. Outputs None. Well-formedness rules 2.21.7.9 CreateLinkObjectAction This action creates a link object. It inherits the semantics of CreateLinkAction, except that it operates on association classes to create a link object. The additional semantics over CreateLinkAction is that the new or found link object is put on the output pin. If the link already exists, then the found link object is put on the output pin. The semantics of CreateObjectAction applies to creating link objects with CreateLinkObjectAction. Associations • result [1..1] : OutputPin [1..1] (Derived from Action:outputPin) Gives the output pin on which the result is put. Inputs • endData.value : T [2..*], where T are self.endData.end.participant (Inherited from CreateLinkAction) Gives object at association end. It is of the same type as the end. • endData.qualifier.value : U [0..*], where U are self.endData.end.qualifier.type (Inherited from CreateLinkAction) Gives qualifier values of an association end. They are the same type as the qualifier attribute. See LinkEndData. [1] The association cannot be an abstract class. not (if self.association().oclIsKindOf(Classifier) then (true = self.association().isAbstract) else false endif) [2] The end data must be LinkEndCreationData. self.endData->forall(oclIsKindOf(LinkEndCreationData)) March 2003 OMG-Unified Modeling Language, v1.5 2-271 2 UML Semantics • endData.insertAt : UnlimitedInteger [0..1] (Inherited from CreateLinkAction) Gives insertion point for ordered association ends. This pin is omitted for unordered ends. Outputs • result : V [1..1], where V is self.endData.end.association The link object created of the same type as the association of the action. Well-formedness rules 2.21.7.10 CreateObjectAction This action instantiates a concrete classifier. The new object is created, and the classifier of the object is set to the given classifier. The new object is returned as the value of the action. The action has no other effect. In particular, no constructors are executed, no initial expressions are evaluated, and no state machines transitions are triggered. The new object has no attributes values and participates in no links. The semantics is undefined for creating objects from abstract classifiers or from association classes. Associations • classifier : Classifier [1..1] Classifier to be instantiated. • result : OutputPin [1..1] (Derived from Action:outputPin) Gives the output pin on which the result is put. Inputs None. Outputs • result : T [1..1], where T is self.class The created object. The type of the runtime object is the classifier specified for the action. [1] The association must be an association class. self.association().oclIsKindOf(Classifier) [2] The type of the result pin must be the same as the association of the action. self.result.type = self.association() [3] The multiplicity of the output pin is 1..1. self.result.multiplicity.is(1,1) 2-272 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Well-formedness rules 2.21.7.11 DestroyLinkAction This action destroys a link or a link object. Link objects can also be destroyed with DestroyObjectAction. The link is specified in the same way as link creation, even for link objects. This allows actions to remain unchanged when their associations are transformed from ordinary ones to association classes and vice versa. Destroying a link that does not exist has no effect. The semantics of DestroyObjectAction applies to destroying a link that has a link object with DestroyLinkAction. The semantics is undefined for destroying a link that has an association end with changeability addonly, or frozen after initialization of the other end objects, unless the link being destroyed does not exist. Objects participating in the association across from an unfrozen end can have links destroyed as long as the objects across from the frozen ends are still being initialized. This means that objects participating in links with 2 or more frozen ends cannot have links destroyed unless all the linked objects are being initialized. Inputs • endData.value : T [2..*], where T are self.endData.end.participant (Inherited from LinkAction) Gives the object at the association end. It is of the same type as the end. • endData.qualifier.value : U [0..*], where U are self.endData.end.qualifier.type (Inherited from LinkAction) Gives the qualifier value of an association end if the end is qualified. It is the same type as the qualifier attribute. They are the same type as the qualifier attribute. See LinkEndData. Outputs None. [1] The classifier cannot be abstract. not (self.classifier.isAbstract = true) [2] The classifier cannot be an association class. not self.classifier.oclIsKindOf(AssociationClass) [3] The classifier of the result pin must be the same as the classifier of the action. self.result.type = self.classifier [4] The multiplicity of the output pin is 1..1. self.result.multiplicity.is(1,1) March 2003 OMG-Unified Modeling Language, v1.5 2-273 2 UML Semantics 2.21.7.12 DestroyObjectAction This action destroys an object. The object may be a link object, in which case the semantics of DestroyLinkAction also applies. The classifiers of the object are removed as its classifiers, and the object is destroyed. The action has no other effect. In particular, no destructors are executed, no state machines transitions are triggered, and references to the objects are unchanged. Destroying an object that is already destroyed has no effect. Associations • input : InputPin [1..1] (Derived from Action:inputPin) The input pin providing the object to be destroyed. Inputs • input : T [1..1], where T is any class. The object to be destroyed. There is no restriction on its type, other than it must be a class. Outputs None. Well-formedness rules 2.21.7.13 LinkAction (abstract) A link action creates, destroys, or reads links. A link is identified by its end objects and qualifier values, if any. The semantics is undefined for links of associations that have targetScope equal to classifier on any end. Associations • endData : LinkEndData [2..*] Data identifying link ends. [1] The multiplicity of the input pin is 1..1. self.input.multiplicity.is(1,1) [2] The input pin has no type. self.input.type->size() = 0 2-274 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Well-formedness rules Additional operations 2.21.7.14 LinkEndCreationData LinkEndCreationData is not an action. It is part of the metamodel that identifies links. It comprises a set of values that identifies one end of a link to be created by CreateLinkAction or CreateLinkObjectAction. It is required for specifying ordered association ends and for replacing all links at an end. See also CreateLinkAction. Attributes • isReplaceAll : Boolean [1..1] Specifies whether existing classifiers of the object should be removed before adding the new classifiers. Associations • insertAt : InputPin [0..1] Specifies where the new link should be inserted for ordered association ends, or where an existing link should be moved to. The type of the input is UnlimitedInteger. This pin is omitted for association ends that are not ordered. [1] The association ends of the link end data must all be from the same association and include all and only the association ends of that association. self.endData->collect(end) = self.association()->collect(connection)) [2] The association ends of the link end data must have targetScope of instance. self.endData->forall(end.targetScope = #instance) [3] The input pins of the action are the same as the pins of the link end data, qualifier values, and insertion pins. self.inputPin->asSet() = let ledpins : Set = self.endData->collect(value)->union(self.endData.qualifier.value) in if self.oclIsKindOf(LinkEndCreationData) then ledpins->union(self.endData.oclAsType(LinkEndCreationData).insertAt) else ledpins [1] association operates on LinkAction. It returns the association of the action. association(); association = self.endData->asSequence().first().end.association March 2003 OMG-Unified Modeling Language, v1.5 2-275 2 UML Semantics Well-formedness rules 2.21.7.15 LinkEndData LinkEndData is not an action. It is part of the metamodel that identifies links. It identifies one end of a link to be read by a ReadLinkAction or written by the children of WriteLinkAction. Associations • end : AssociationEnd [1..1] Association end for which this link-end data specifies values. • value : InputPin [0..1] Input pin that provides the specified object for the given end. This pin is omitted if the link-end data specifies an “open” end for reading. • qualifier : QualifierValue [0..*] Specifies qualifier attribute/value pairs of the given end. Well-formedness rules [1] LinkEndCreationData can only be end data for CreateLinkAction or one of its specializations. self.LinkAction.oclIsKindOf(CreateLinkAction) [2] Link end data for ordered association ends must have a single input pin for the insertion point with type UnlimitedInteger and multiplicity of 1..1, otherwise the link end data has no input pin for the insertion point. let insertAtPins : Collection = self.insertAt in if self.end.ordering = #unordered then insertAtPins->size() = 0 else let insertAtPin : InputPin = insertAts->asSequence()->first() in insertAtPins->size() = 1 and insertAtPin.type = UnlimitedInteger and insertAtPin.multiplicity.is(1,1)) endif [1] The qualifiers include all and only the qualifiers of the association end. self.qualifier->collect(qualifier) = self.end.qualifier [2] The type of the end object input pin is the same as the type of the association end. self.value.type = self.end.participant [3] The multiplicity of the end object input pin must be “1..1”. self.value.multiplicity.is(1,1) [4] The end object input pin is not also a qualifier value input pin. self.value->excludesAll(self.qualifier.value) 2-276 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.21.7.16 QualifierValue QualifierValue is not an action. It is part of the metamodel that identifies links. It gives a single qualifier within a link end data specification. See LinkEndData. Associations • qualifier : Attribute [1..1] Attribute representing the qualifier for which the value is to be specified. • value : InputPin [1..1] Input pin from which the specified value for the qualifier is taken. Well-formedness Rules 2.21.7.17 ReadAttributeAction This action reads the values of an attribute, in order if the attribute is ordered. Associations • result: OutputPin [1..1] (Derived from Action:outputPin) Gives the output pin on which the result is put. Inputs • object : T [1..1], where T is a self.attribute.owner (Inherited from AttributeAction:object) Object whose attribute is to be read. The type of the runtime object is the same as the type of the owner of the attribute. Outputs • result : U [1..1], where U is self.attribute.type Value of the attribute. It is of the same type as the attribute. The multiplicity of the attribute must be compatible with the multiplicity of this pin. [1] The qualifier attribute must be a qualifier of the association end of the link-end data. self.LinkEndData.end->collect(qualifier)->includes(self.qualifier) [2] The type of the qualifier value input pin are the same as the type of the qualifier attribute. self.value.type = self.qualifier.type [3] The multiplicity of the qualifier value input pin is “1..1”. self.value.multiplicity.is(1,1) March 2003 OMG-Unified Modeling Language, v1.5 2-277 2 UML Semantics Well-formedness Rules 2.21.7.18 ReadExtentAction This action reads the runtime objects of any classifier that may have instances. It reads all instances, direct and indirect. Association • classifier : Classifier [1..1] The classifier whose extent is to be read. Inputs None. Outputs • result : T [1..1], where T is self.classifier The runtime objects of the classifier. Well-formedness Rules 2.21.7.19 ReadIsClassifiedObjectAction This action tests an object’s classification against a statically specified class. It returns true if the object input to the action is classified by the specified classifier with no intervening classes between the object and the specified classifier. It returns true if the isDirect attribute is false and the object input to the action is classified by the specified classifier, either directly or with intervening classifiers. Otherwise, it returns false. [1] The type and ordering of the result output pin are the same as the type and ordering of the attribute. self.result.type = self.attribute.type and self.result.ordering = self.attribute.ordering [2] The multiplicity of the attribute must be compatible with the multiplicity of the output pin. self.attribute.multiplicity.compatibleWith(self.result.multiplicity) [1] The action has no input pins. self.pinValue→size() = 0 [2] The type of the result output pin is the classifier. self.result.type = self.classifier [3] The multiplicity of the result output pin is “0..*”. self.result.multiplicity.is(0,#unlimited) 2-278 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes • isDirect : Boolean [1..1]Indicates whether the classifier must directly classify the input object. Associations • classifier : Classifier [1..1] The classifier for testing classification of the input object. • input : InputPin [1..1] (Derived from Action:inputPin) The input pin on which to test classification. • result : OutputPin [1..1] (Derived from Action:ouputPin) The output pin on which the result is put. Inputs • input : T [1..1], where T is any class The object on which to test classification. There is no restriction on its type, other than it must be a class. Outputs • result : Boolean [1..1] The result of testing the classification of the input object. Well-formedness rules 2.21.7.20 ReadLinkAction This action navigates links of an association towards one end. For example, it navigates the link of a binary association from a source object to the objects at the other end of links of the association in which that source object participates. The end towards which navigation occurs is the one that does not have an input pin to take its object (the “open” end). The objects put on the result output pin are the ones participating in the [1] The multiplicity of the input pin is 1..1. self.input.multiplicity.is(1,1) [2] The input pin has no type. self.input.type->size() = 0 [3] The multiplicity of the output pin is 1..1. self.result.multiplicity.is(1,1) [4] The type of the output pin is Boolean. self.result.type = Boolean [5] If isDirect is false, then generalization between classifiers must be statically defined. This rule is not formalized. March 2003 OMG-Unified Modeling Language, v1.5 2-279 2 UML Semantics association at the open end, conforming to the specified qualifiers, in order if the end is ordered. The semantics is undefined for reading a link that violates the navigability or visibility of the open end. Associations • result : OutputPin [0..*] (Derived from Action:outputPin) The pin on which are put the objects participating in the association at the end not specified by the inputs. Inputs • endData.value : T [1..*], where T are self.endData.end.participant (Inherited from LinkAction) Gives the object at an association end. It is of the same type as the end. See LinkEndData. • endData.qualifier.value : U [0..*], where U are self.endData.end.qualifier.type (Inherited from LinkAction) Gives the qualifier value of an association end if the end is qualified. It is the same type as the qualifier attribute. See LinkEndData. Outputs • result : V [0..*], where V are self.endData.end.association.connection[open end].participant, where [open end] designates the end of the association not included in the inputs. The objects participating in the association at the end not specified by the inputs. The type of the identities are the same as the type of the open association end. The multiplicity of the association end must be compatible with the multiplicity of this pin. Well-formedness Rules [1] Exactly one link-end data specification (the “open” end) must not have an end object input pin. self.endData->select(ed | ed.value->size() = 0)->size() = 1 [2] The type and ordering of the result output pin are same as the type and ordering of the open association end. let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)- >asSequence()->first().end in self.result.type = openend.type and self.result.ordering = openend.ordering [3] The multiplicity of the open association end must be compatible with the multiplicity of the result output pin. let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)- >asSequence()->first().end in openend.multiplicity.compatibleWith(self.result.multiplicity) [4] The open end must be navigable. 2-280 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.21.7.21 ReadLinkObjectEndAction This action reads the object on an end of a link object. Associations • end : AssociationEnd [1..1] Link end to be read. • object : InputPin [1..1] (Derived from Action:inputPin) Gives the input pin from which the link object is obtained. Inputs • object : T [1..1], where T is self.end.association Link object being read. The type of the runtime object is the same as the association owning the association end being read. Outputs • result : U [1..1], where U is self.end.participant Object participating in the link at the specified end. Well-formedness Rules let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)- >asSequence()->first().end in openend.isNavigable = true [5] Visibility of the open end must allow access to the object performing the action. let host : Classifier = self.procedure().hostClassifier() in let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)- >asSequence()->first().end in openend.visibility = #public or self.endData->exists(oed | not oed.end = openend and (host = oed.end.participant or (openend.visibility = #protected and host.allSupertypes- >includes(oed.end.participant)))) [1] The association of the association end must be an association class. self.end.Association.oclIsKindOf(AssociationClass) [2] The ends of the association must all have instance targetScope. self.end.Association.connections->forall(targetscope = #instance) [3] The type of the object input pin is the association class that owns the association end. self.object.type = self.end.Association [4] The multiplicity of the object input pin is “1..1”. March 2003 OMG-Unified Modeling Language, v1.5 2-281 2 UML Semantics 2.21.7.22 ReadLinkObjectQualifierAction This action reads a qualifier value on an end of a link object. Associations • qualifier : Attribute [1..1] The attribute representing the qualifier to be read. • object : InputPin [1..1] (Derived from Action:inputPin) Gives the input pin from which the link object is obtained. Inputs • object : T [1..1], where T is self.end.association The link object being read. The type of the runtime object is the same as the association owning the association end of the qualifier attribute being read. Outputs • result : U [0..1], where U is self.qualifier.type Value of the qualifier attribute on its end of the link, if any. The value has the same type as the qualifier attribute. Well-formedness Rules self.object.multiplicity.is(1,1) [5] The type of the result output pin is the same as the type of the association end. self.result.type = self.end.participant [6] The multiplicity of the result output pin is 1..1. self.result.multiplicity.is(1,1) [1] The qualifier attribute must be a qualifier attribute of an association end. self.qualifier.associationEnd->size() = 1 [2] The association of the association end of the qualifier attribute must be an association class. self.qualifier.associationEnd.Association.oclIsKindOf(AssociationClass) [3] The ends of the association must all have instance targetScope. self.qualifier.associationEnd.Association.connections->forall(targetscope = #instance) [4] The type of the object input pin is the association class that owns the association end that has the given qualifier attribute. self.object.type = self.qualifier.associationEnd.Association [5] The multiplicity of the object input pin is “1..1”. 2-282 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.21.7.23 ReadSelfAction This action reads the host object of an action. The semantics is undefined for usage in a procedure that does not have a host object. Associations • result : OutputPin [1..1] (Derived from Action:outputPin) Gives the output pin on which the hosting object is placed. Inputs None. Outputs • result : T [1..1], where T is the class that owns the procedure containing the action Object hosting the action. Well-formedness Rules 2.21.7.24 ReadVariableAction This action reads the values of a variable, in order if the variable is ordered. self.object.multiplicity.is(1,1) [6] The type of the result output pin is the same as the type of the qualifier attribute. self.result.type = self.qualifier.type [7] The multiplicity of the result output pin is “1..1”. self.result.multiplicity.is(1,1) [1] The action must be contained in a procedure that has a host classifier. self.procedure().hostClassifier()->size() = 1 [2] If the action is contained in a procedure that is acting as the body of a method, then the operation of the method must have an ownerScope of instance. let hostelement : Element = self.procedure().hostElement() in not hostelement.oclIsKindOf(Method) or hostelement.oclAsType(Method).specification.ownerScope = #instance [3] The type of the result output pin is the host classifier. self.result.type = self.procedure().hostClassifier() [4] The multiplicity of the result output pin of a read-self action is “1..1”. self.result.multiplicity.is(1,1) March 2003 OMG-Unified Modeling Language, v1.5 2-283 2 UML Semantics Associations • result : OutputPin [1..1] (Derived from Action:outputPin) Gives the output pin on which the values of the variable are placed. Inputs None. Outputs • result : T [0..*], where T is self.variable.type Value of the variable. The type of the value is the same as the type of the variable. The multiplicity of the variable must be compatible with the multiplicity of this pin. Well-formedness Rules 2.21.7.25 ReclassifyObjectAction This action changes classifiers for an object. The object input to the action is classified by its existing classifiers plus the new classifiers and minus the old classifiers statically specified by the action. It also supports the removal of existing classifiers of the object before the new classifiers are added. The action has no other effect. In particular, the identity of the object is preserved, no constructors or destructors are executed and no initial expressions are evaluated. New classifiers replace existing classifiers in one action, so that attribute values and links are not lost by intermediate stages of classification when the old and new classifiers have attributes and associations in common. Adding a classifier that duplicates one already existing, or removing a classifier that is not there, has no effect. Adding and removing the same classifiers has no effect. States are preserved for state machines that are in common before and after the action. New state machines are not started. Removed state machines behave as if the object were deleted. The semantics is undefined if any of the new classifiers are abstract. The semantics is undefined if all classifiers are removed from a runtime object. [1] The type and ordering of the result output pin of a read-variable action are the same as the type and ordering of the variable. self.result.type =self.variable.type and self.result.ordering = self.variable.ordering [2] The multiplicity of the variable must be compatible with the multiplicity of the output pin. self.variable.multiplicity.compatibleWith(self.result.multiplicity) 2-284 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Attributes isReplaceAll : Boolean [1..1] Specifies whether existing clasifiers of the object should be removed before adding the new classifiers. Associations • input : InputPin [1..1] (Derived from Action:inputPin) Gives the object to be reclassified. • newClassifier : Classifier [0..*] Classifiers to add to the classifiers of the object. • oldClassifiers : Classifier [0..*] Classifiers to remove from classes of the object. Inputs • input : T [1..1], where T is any class Object to be reclassified. Outputs None. Well-formedness rules 2.21.7.26 RemoveAttributeValueAction This action removes values from attributes. Attributes are potentially multi-valued. Removing a value succeeds even when it violates the minimum multiplicity. Removing a value that does not exist has no effect. The semantics is undefined for removing an existing value for an attribute with changeability addonly. The semantics is undefined for removing an existing value of an attribute with changeability frozen after initialization of the owning object. Inputs • value : T [1..1], where T is self.attribute.type (Inherited from WriteAttributeAction) Value of attribute to remove or remove. Its type is the same as the type of the attribute. [1] None of the new classifiers may be abstract. not self.newClassifier->exists(isAbstract = true) [2] The multiplicity of the input pin is 1..1. self.input.multiplicity.is(1,1) [3] The input pin has no type. self.input.type->size() = 0 March 2003 OMG-Unified Modeling Language, v1.5 2-285 2 UML Semantics • object : U [1..1], where U is self.attribute.owner (Inherited from AttributeAction) Object from which to remove the attribute value. Its type is the same as the type of the owner of the attribute being modified. Outputs None. 2.21.7.27 RemoveVariableValueAction This action removes values from variables. Variables are potentially multi-valued. Removing a value succeeds even when that violates the minimum multiplicity. Removing a value that does not exist has no effect. Inputs • value : T [1..1], where T is self.variable.type (Inherited from WriteVariableAction) Value to remove. Its type is the same as the type of the variable. Outputs None. 2.21.7.28 StartObjectStateMachineAction This action puts the state machines of an object in their top states, if they have not been there already. This can only be used once per object. The action has no effect if the object does not have a state machine. Associations • input : InputPin [1..1] (Derived from Action:inputPin) The object on which to start the state machines. Inputs • input : T [1..1], where T is any user class that has a state machine Object on which to start the state machines. Outputs None. Well-formedness rules None 2.21.7.29 VariableAction (abstract) A variable action operates on a statically specified variable. 2-286 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Associations • variable : Variable [1..1] Variable being accessed. Well-formedness rules 2.21.7.30 WriteAttributeAction (abstract) A write attribute action operates on an attribute of an object to modify its values. It has an input pin on which the value that will be added or removed is put. Other aspects of write attribute actions are inherited from AttributeAction. Associations • value : InputPin [1..1] (Derived from Action:inputPin) Value to be added or removed from the attribute. Well-formedness rules 2.21.7.31 WriteLinkAction (abstract) A write link action creates or destroys links. Well-formedness rules 2.21.7.32 WriteVariableAction (abstract) A write variable action modifies a statically specified variable. Associations • value : InputPin [1..1] (Derived from Action:inputPin) Value to be added or removed from the variable. [1] The action must be in the scope of the variable. self.variable.isAccessibleBy(self) [1] The type input pin is the same as the owner of the attribute. self.value.type = self.attribute.owner [2] The multiplicity of the input pin is 1..1. self.value.multiplicity.is(1,1) [1] All end data must have exactly one input object pin. self.endData.forall(value->size() = 1) March 2003 OMG-Unified Modeling Language, v1.5 2-287 2 UML Semantics Well-formedness rules 2.22 Computation Actions These actions transform a set of input values to a set of output values. These actions do not read or write attribute or link values, nor do they otherwise interact with object memory or other objects, so their control is entirely self-contained. Consequently, they embody mathematical functions. These actions supply the primitive functions out of which computations are constructed. 2.22.1 Computation actions Computation actions evaluate various mathematical functions. They take input values and produce output values. The output values depend only on the input values and not on the state of the memory or the state of the control. This specification does not define a set of primitive functions. Rather, we assume that any particular implementation of the action semantics will define a set of primitive functions, presumably using a profile. For modeling purposes, users must be able to define new primitive functions, but the mechanisms of the definition are outside of the UML and action semantics. This specification does require each primitive function to have a name and lists of input and output types. This approach has the drawback that users must agree on the set of primitive functions, but different groups of users will prefer different sets of functions anyway, so little is lost in not providing a default set of functions. The following model shows the computation action classes. [1] The type of the input pin is the same as the type of the variable. self.value.type =self.variable.type [2] The multiplicity of the input pin is 1..1. self.value.multiplicity.is(1,1) 2-288 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Figure 2-54 Computation classes metamodel Literal value actions are broken out as a separate kind of action. These are to be regarded as special kinds of primitive functions, with zero inputs and one output. Code actions are included here, although they might possibly have external effects and therefore not be pure mathematical functions. Because they are explicitly implementation-dependent, it is hard to say much more about them within UML itself. PrimitiveAc tion (f r om A ct i on F... ) NullActi on InputPin (from Action Foundation) OutputPin (from Action Foundation) CodeAction language : String encoding : String 0..* 0..1 +/argument 0..*{ordered} 0..1 0..* 0..1 +/result 0..* {ordered} 0..1 OutputPin (from Action Foundation) DataVal ue (from C ommon B ehavior) LiteralValueAction 1 0..1 +/result 1 0..1 1 0..* +value1 0..* InputPin (from Action Foundation) OutputPin (from Action Foundation) ApplyFunctionAction 0..* 0..1 +/argument 0..*{o rd e re d } 0..1 1..* 0..1 +/result1..* {ordered} 0..1 PrimitiveFunction language : String encoding : String 1 0..* +function 1 0..* DataType (from Core) ArgumentSpecification multiplicity : Multiplicity ordering : OrderingKind0..* 0..* +inputSpec 0..* 0..* 1..* 0..* +outputSpec 1..* 0..* 1 0..* +type 1 0..* InputPin (from Action Foundation) OutputPin (f rom Ac tion Foundat ion) UnmarshalAction 0..1 1 0..1 +/argument 1 0..1 0..* 0..1 +/result 0..* {ordered} InputPin (from Action Foundation) OutputPin (from Action Foundation) Class (f rom Core) 1 0..* +unmarshalType 1 0..* MarshalAction 0..1 0..* 0..1 +/argument0..* {ordered} 0..1 10..1 +/result 1 1 0..* +marshalType1 0..* InputPin (from Action Foundation) OutputPin (from Action Foundation) TestIdentityAction 0..1 1 0..1 +/first 1 0..1 1 0..1 +/second 1 1 0..1 +/result 1 0..1 ModelElement (from Core) March 2003 OMG-Unified Modeling Language, v1.5 2-289 2 UML Semantics 2.22.2 Computation Classes 2.22.2.1 ApplyFunctionAction This action computes a primitive predefined mathematical function that depends only on the input values, with no access to object memory or to any objects. The execution and results of this action depend only on the function and the input values. There are absolutely no side effects of this action and it therefore cannot conflict with anything. All it does is produce result values using a mathematical function. New primitive functions may be defined (outside of UML) as mathematical functions of input values to output values. All usual primitive operations should be considered as primitive functions (e.g., addition, nand, square root, finding a substring, Bessel function, etc.). A list of defined primitive functions may be supplied as part of a modeling profile. UML does not provide a mechanism to define primitive functions, as their definition is outside its scope. It is expected that users will agree on environments containing such definitions. Attributes None Associations • function: PrimitiveFunction[1..1] The function to execute Inputs • argument: T [0..*], where T = self.function.inputSpec.type The input values Outputs • result: U[0..*], where U = self.function.outputSpec.type The output values 2-290 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Well-formedness rules Therefore there are no functions on collections, but operations on collections can be constructed as actions at a higher level out of functional pieces. Functions have no effect on and may not access object state. The definition of the mathematical functions is outside of UML. Semantics 1. When all of the control and data flow prerequisites of the action have been satisfied, the argument values are obtained from the input pins and made available to the computation. 2. The result values are computed from the input values according to the given function. During the execution of the computation, there is no communication or interaction with the rest of the system. The amount of time to compute the results is unspecified. Some primitive functions may raise exceptions for certain input values, in which case the computation is terminated. 3. The result values are placed on the output pins of the action execution and the execution of the primitive function action is complete; or, the primitive function execution may raise an exception, in which case no output values are produced. 2.22.2.2 ArgumentSpecification (Not an action) Specification of an input or output argument of a primitive function. Attributes • multiplicity: Multiplicity The range of allowed cardinality of the values on the argument. • ordering: OrderingKind Whether and how multiple values on an argument are arranged. [1] The number and types of the input argument and output result pins must be compatible with the number and types of the parameters of the function. self.input_argument()->size( ) = self.function.inputType->size( ) and Sequence {1..self.input_argument()->size( )} -> forAll (i:Integer | let argumenti = self.input_argument (i) let inparameteri = self.function.inputType->at(i) argumenti.type.isCompatibleWith (inparameteri.type)) and self.output_result()->size( ) = self.function.outputType->size( ) and Sequence {1..self.output_result()->size( )} -> forAll (i:Integer | let resulti = self.output_result (i) in let outparameteri = self.function.outputType->at(i) in outparameteri.type.isCompatibleWith (resulti.type)) March 2003 OMG-Unified Modeling Language, v1.5 2-291 2 UML Semantics Associations • type: DataType [1..1} The data type that values on the argument must conform to. Well-formedness rules None 2.22.2.3 CodeAction A code action performs an action that is defined outside of UML. This may involve external interactions, so it is not a mathematical transformation like a primitive function action. The action may have inputs and outputs. Code actions must not alter object memory state, although it is hard to prevent such things. The semantics of a code action that alters object memory are undefined, together with the semantics of all subsequently executed actions. Attributes • language: String-- the language in which the code action is specified. • encoding: String-- a string that identifies the action in the given language. Not meaningful to UML. Associations none Inputs • argument: T [*], where T is implementation dependent on self.encoding The input values Outputs • result: U [*], where U is implementation dependent on self.encoding The output values Well-formedness rules Clearly each kind of code action has constraints on its input and output values, but as the whole purpose of the code action is to do something that is outside of UML, it is not possible to specify the constraints within UML. Semantics 1. When all of the control and data flow prerequisites of the action have been satisfied, the input values are obtained from the input pins and made available to the computation. 2-292 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2. During the execution of the code action, the execution may access or change values in the rest of the system or communicate with the run-time execution engine or devices in the real world. Such behavior is inherently implementation dependent and may be different or meaningless in different implementation environments. 3. At such time as specified by the implementor of the code action, the output values (if any) are placed on the output pins of the action execution and the execution is complete. 2.22.2.4 LiteralValueAction Generates a literal value on the output pin. The value can be of any pure data type. Attributes None Associations • value: DataValue The literal value produced by the action. Inputs none Outputs • result: T, where T = self.value.type The output value, equal to the literal value. Well-formedness rules self.output_result().type = self.value.type Semantics 1. When all of the control prerequisites of the action have been satisfied, the value specified by the literal is placed on the output pin of the action execution, and the action execution satisfies the appropriate control and data flow prerequisites. 2.22.2.5 MarshalAction Creates an object whose attribute values are initialized from the inputs. Attributes None March 2003 OMG-Unified Modeling Language, v1.5 2-293 2 UML Semantics Associations • marshalType: Class[1.1] The type of object to create. Inputs • argument: T [0..*], where T = self.marshalType.attribute.type for attribute The initial attribute values of the newly created object. Outputs • result: U [1..1], where U = self.marshalType The newly created, initialized object. Well-formedness rules Semantics 1. When all of the control and data flow prerequisites of the action have been satisfied, the input values are obtained from the input pins and made available to the computation. An object of the type specified by marshalType is created and its attributes are initialized with the input values. The identity of the object is placed on the output pin of the action execution, and the execution of the action is complete and satisfies appropriate control and data flow prerequisites. 2.22.2.6 NullAction An action that has no effect. Attributes none Associations none Inputs none Outputs none [1] The argument types must match the attribute types of the marshal type. self.input_argument()->size( ) = self.marshalType.allAttribute->size( ) and Sequence {1..self.input_argument()->size( )} -> forAll (i:Integer | let argumenti = self.input_argument (i) in let inparameteri = self.marshalType.allArgument()->at(i) in argumenti.type.isCompatibleWith (inparameteri.type)) 2-294 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Well-formedness rules none Semantics 1. When all of the control prerequisites of the action have been satisfied, the execution of the null action is complete, and the action execution satisfies any control prerequisites for which it is a predecessor. 2.22.2.7 PrimitiveFunction (Not an action) Describes the signature of a primitive function, that is, a mathematical function that produces output values from input values without any internal action semantics substructure. The manner of specifying functions is outside the scope of action semantics and must be expressed in some external language. Attributes • name: Name (inherited from ModelElement) The name of the function. • language: String The language in which the function is specified. • encoding: String The specification of the function in the given language. Associations • inputSpec: ArgumentSpecification [0..*] Specification of the input values of the function. • outputSpec: ArgumentSpecification [1..*] Specification of the output values of the function. Well-formedness rules None 2.22.2.8 TestIdentityAction Produces true if the two input values are the same identity, false if they are not. Defined only on object identities. Attributes None Associations none March 2003 OMG-Unified Modeling Language, v1.5 2-295 2 UML Semantics Inputs • first: T, where T is any class-- one object identity • second: U, where U is any class-- another object identity Outputs • result: Boolean True if first and second input values are the same identity. Well-formedness rules None Semantics 1. When all of the control and data flow prerequisites of the action have been satisfied, the input values are obtained from the input pins and made available to the computation. If the two input values represent the same object identity (regardless of any implementation-level encoding), the value true is placed on the output pin of the action execution; otherwise the value false is placed on the output pin. The execution of the action is complete and satisfies appropriate control and data flow prerequisites. 2.22.2.9 UnmarshalAction Breaks an object of a known type into outputs, each of which is equal to the value of one of the object’s attribute values. Attributes None Associations • unmarshalType: Class The type of object accepted by the action. Inputs • argument: T, where T = self.unmarshalType- The identity of an input object, which must be of the given unmarshalType or a descendant of it. Outputs • result: U [0..*], where U = self.unmarshalType.attribute.type Values equal to the attribute values of the object (according to the unmarshalType). 2-296 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Well-formedness rules Semantics 1. When all of the control and data flow prerequisites of the action have been satisfied, the input value is obtained from the input pins and made available to the computation. An object of the type specified by marshalType is required as the input value. The values of the various attributes of the object are placed on the respective output pins of the action execution, one attribute value per pin. The execution of the action is complete and satisfies appropriate control and data flow prerequisites. 2.23 Collection Actions A collection action applies another action (a “subaction”) to collections of elements. Collection actions avoid explicit indexing and extracting of elements from collections, and the consequent overspecification of control. There are four kinds of collection actions, as follows: Figure 2-55 Collection actions [1] The result types must match the attributes of the unmarshal type. self.output_result()->size( ) = self.unmarshalType.attribute->size( ) and Sequence {1..self.output_result()->size( )} -> forAll (i:Integer | let resulti = self.output_result (i) in let outparameteri = self.function.outputType->at(i) in outparameteri.type.isCompatibleWith (resulti.type)) Action (from Action F oundation) CollectionAction 1 0..* +subaction 1 0..* FilterAction Re duceAction isUnordered : Boolean IterateAction isUnordered : Boolean MapAction March 2003 OMG-Unified Modeling Language, v1.5 2-297 2 UML Semantics • Filter - The filter action applies a subaction that determines whether to include an element of a collection in a new output collection, effectively filtering the input collection according to some criterion. The subaction can be applied to the elements in parallel. An example is a subaction that determines whether an account is above a certain balance. • Iterate - The iterate action applies a subaction repeatedly to each of the elements in a collection, accumulating the effects in “loop variables.” Because the result of each subaction is accumulated, the subaction must be applied to each element in the collection in sequence. An example is paying creditor accounts in order of precedence until funds are exhausted. • Map - The map action applies a subaction in parallel to each of the elements of a collection of data resulting in a collection with the same number of elements. An example is paying interest on each account. • Reduce - The reduce action repeatedly applies a subaction to pairs of adjacent elements in a collection, replacing a pair of elements by the result, until the final result, which is a scalar of the same type. An example is summing up balances of all accounts. 2.23.1 General Rules for Collection Actions A number of elements, all of the same type, comprise a collection. The element type is the type of the collection’s elements. The number of elements in a collection is its size. Collection actions repeat an action (the subaction) for the elements in a collection. Because the number of repetitions is governed by the size of the collection, rather than a programmed test condition required in a loop action, when a collection action takes more than one collection as input, they must all have the same size. Similarly, multiple collections produced by the same action must have the same size as each other. Multiple collections are conceptually equivalent to a single collection of tuples. A slice is a tuple containing one element, at the same position, from each collection. Each subaction has a single pin for each scalar element in the slice, while each pin of a collection action holds collections. That is, the input and output pins to collection actions hold collections while the pins to the subactions hold the corresponding elements. If there is more than one input collection in a slice, the elements in each collection must be ordered so that the corresponding elements in the different collections can be correctly matched (hence the word slice). If the input collection or collections are ordered, then the output collection or collections are ordered also. (The concept of ordering can be extended to more complex data structures, such as bags, trees, graphs, and so on. In such a case, all collections in an action must have the same form.) Subactions may have other scalar inputs from outside the collection action. Such values will be the same for all the subaction executions during one execution of a collection action. Subaction outputs are never available outside the collection action. 2-298 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.23.2 Collection Action Classes 2.23.2.1 CollectionAction (abstract) An action that operates on a collection of values. Attributes none Associations • subaction: Action[1..1]The action applied repeatedly or concurrently to the elements of the collection. 2.23.2.2 FilterAction Figure 2-56 Filter action The filter action applies a subaction to every slice of inputs. The subaction must yield a boolean output whose value is used to decide whether each slice of input values is passed through to the output collections. The result of the filter action is a set of collections, whose size is equal to or less than the size of the input collections, comprising all the slices of the input collections for which the subaction yielded a true value. The gaps caused by the subaction yielding a false value are closed up. All executions of the subaction can be concurrent. In the simplest case, the subaction takes an input (a single element from the collection input to the filter action), and produces a boolean data value on the output pin. The filter action has a collection of elements as input and an output that is a collection of a subset of the input collection, in the same order, whether the collection is ordered or not. pin of the subaction InputPin OutputPinFilterAction 1..* 0..1 +/argument 1..* {ordered} 0..1 0..1 +/result {ordered} 0..1 1..*0..1 +subinput 1..* {ordered} 0..1 1 0..* +subtest 1 0..* c orrespond match March 2003 OMG-Unified Modeling Language, v1.5 2-299 2 UML Semantics The subaction may also take inputs that are not inputs to the filter action, such as a constant or a ‘variable’ used in every execution of the subaction. For example, if the subaction tests whether an element is less than x, then the inputs to the subaction are the element and x, while the input to the filter action is the collection of elements. The output of the subaction remains a boolean scalar. The filter action may also take multiple input collections, each of which must have the same number of elements. When each slice is presented successively as inputs to the subaction, the subaction determines whether to pass the slice through to the corresponding output collections. The number of the input and output collections must therefore be the same. The type of each output collection matches the type of its corresponding input collection. In addition, the number of elements in each output collection will be the same. Attributes None Associations • subaction: Action[1..] An action that tests whether to keep the input slice in the result. It must have an output pin that yields a Boolean value. For each execution yielding a true value, the input slice is copied to the output collections of the filter action. • subinput : OutputPin [1..*] An ordered list of collections. During each execution of the subaction, a value from each input collection (a slice) is copied to the corresponding subinput pin. The subaction is executed once for each input slice. • subtest: OutputPin - The boolean result of the testing subaction. During each execution of the subaction, the value on this output pin determines whether the corresponding slice is copied to the output collections. If the value is false, the slice does not appear in the output collections and the gap is closed up. If the input collection(s) are ordered, then the output collections are ordered, otherwise the output is unordered. Inputs • argument: U [1..*], where U[i] = Collection of T[i], in which T is from subinput [These input pins are owned by the filter action itself.] An ordered list of collections. All the collections must have the same size, but each collection may contain a different type of element. The subaction is executed once per slice. If there is more than one collection, they must be ordered so that the element values can be matched. Outputs • result: U[1..*], where U is the same as on argument [These output pins are owned by the filter action itself.] At the completion of execution of the filter action, the value of each result pin in the ordered list is a collection of values, equal in number to the number of input argument collections. 2-300 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics The type of each collection and the type of elements in it is identical to that of the corresponding argument collection. The size of each collection is less than or equal to the size of the corresponding input collection. The list of values in each collection is the same as the list of values in the corresponding input collection, after removing elements for which the subtest value was false and closing up the gaps. If the collections are ordered, the ordering of elements is preserved. • subtest: Boolean[1..][This output pin is owned by an action embedded within the subaction.] At the completion of an execution of the subaction, this pin holds a Boolean value. If the value is true, the value of the subinput values are passed through to the corresponding result collections. If the value is false, the result collections lack elements at the appropriate position. • subinput: T [1..*], where T are user classes [These output pins are owned by the FilterAction and accessible only to the subaction and its embedded actions.] The number of pins is equal to the number of input collections of the filter action. All the input collections must be the same size. During each execution of the subaction, the value on each subinput pin is equal to the value of an element of the collection on the corresponding input pin of the filter action. The position of the element in each collection is identical, but different for each execution of the subaction. Semantics 1. When all the control and dataflow prerequisites of the action execution have been satisfied, it begins execution. The argument values must all be collections of the same size and kind, otherwise the model is ill formed and its subsequent behavior is undefined. A subordinate action execution is created for each position in the group of collections. The element value at the given position in each collection is copied to the respective input pin of the subordinate action execution corresponding to the position in the collections. 2. The subordinate action executions execute concurrently. When a subordinate action execution completes, the Boolean value on the designated subtest pin determines whether the slice of input values will be present in the collection of output values of the filter action. 3. When all of the subordinate action executions have completed, a group of output collections are created, each of the same kind and type as the corresponding input collection of the filter action. The elements of the output collections are the same as the elements of the input collections, except that positions corresponding to false test values of the subordinate action executions are removed from the collections. When an element is filtered out from an output collection, the remaining values “close up” the missing position, as follows: For a set, the missing element is simply absent; for a list, the subsequent elements move forward one position for each missing element; for other kinds of collections that may be defined in the future, the specifier must define the effect of removing an element. The filtered collections are placed on the output pins of the filter action and its execution is complete. March 2003 OMG-Unified Modeling Language, v1.5 2-301 2 UML Semantics 2.23.2.3 IterateAction The iterate action applies an action repeatedly, once for each input slice. A bank of loop variables accumulates the result of the iteration and is eventually passed to the output of the iterate action. This action is a special case of a loop in which the number of iterations is equal to the number of elements in a collection and the elements of the collection are made available to the loop body on successive iterations. The iterate action executes a subaction once for each input slice. The slices are presented from first to last in the scan order for the collection. When the order of computation does not affect the result, for example if the input collection is a set, or if the isUnordered attribute is true, then the slices are presented in an indeterminate (and not necessarily repeatable) order. Like a loop, an iterate action has loop variables that accumulate the effects of the iteration. The subaction accesses the previous values of the loop variables and computes new values for the next execution. The initial values of the loop variables are supplied by inputs to the iterate action, and the final values of the loop variables become the results of the iterate action. If there are no loop variables, the action can have an effect only by writing memory values. An iterate action has two kinds of input pins: the input collections, and scalar values used to initialize the loop variables. The iterate action has one kind of output pins, whose number and types match the loop variable input pins. The iterate action owns internal OutputPins, matching the loop variable output pins. On the initial execution of the subaction, these pins get the values from the loop variable input pins. The iterate action also owns a bank (labeled subinput) of internal OutputPins, equal in number to the collection input pins. The type of each subinput pin matches the type of element containing in the corresponding collection input pin. During each execution of the subaction, these pins hold one slice. The iterate action also designates (as suboutput) a bank of OutputPins owned by the subaction. At the conclusion of the execution of the subaction, the values on these pins become the new values of the loop variable pins. The subaction has access to the subinput values and the loop variable values that change during each execution of the subaction. It may also access available OutputPins in the containing scope. Such values are fixed during the executions of the subactions for any one execution of the iterate action. During one execution, the subaction computes values for the suboutput pins. The values on the suboutput pins become the new values of the loop variable pins on the next iteration of the subaction. When all slices of the collections have been processed, the final values of the loop variables become the values on the result output pins of the overall iterate action. No outputs of the subaction are available outside of it, except for the explicit suboutput pins designated by the iterate action, which are available only to the iterate action itself. The isUnordered attribute states that the order of execution of slices is irrelevant, even though the ordering of elements in each collection is still used to match corresponding elements into slices. The purpose of this attribute would be to remove overspecification of ordering and permit optimization within an implementation, especially if values are not all computed at the same time (such as lazy evaluation). If the input collection shape is a set, then the slices are processed in an indeterminate order. 2-302 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Figure 2-57 Iterate action Attributes • isUnordered: Boolean[1..1] If true, indicates that the slices may be given to the successive executions of the subaction in any order. This should be set only if the final result is insensitive to execution order. If false, the subaction is executed on slices of the collections in order from first to last, in accord with the scan order of the particular kind of collection. If the collection is a set, then the iteration order is automatically unordered and this flag has no further effect. Associations • subaction: Action[1..1] An action that is executed repeatedly and sequentially, once for each slice of values in a list of input collections. During each execution of the action, one slice of values is made available to the execution, from the first to last position in the collections. Like a loop action, this action has a list of loop variables that make the results of one execution of the subaction available to the next sequential execution of the subaction. On the first execution of the subaction, the loop variables are set by the loopValueInput values that are input to the overall IterateAction. The iterate action designates a list of output pins from the subaction as the updated values of the loop variables. During each execution of the subaction, the previous values of the loop variables are available within the subaction. After each execution, the designated output values in the subaction are copied to the loop variables. After the subaction has been executed once for each sliced of the input collections, the final values of the loop variables are copied to the output pins of the iterate action. pin of the subaction InputPin OutputPinIterateAc tion isUnordered : Boolean1..* 0...+/collectionInput 1..* {ordered} 0... 0..* 0... +/loopVariableInput 0..* {ordered} 0... 0..* 0... +loopVariable 0..* {ordered}0... 0..*0... +suboutput 0..* {ordered} 0... 0..*0... +/result 0..*{ordered}0... match 1..* 0... +subinput 1..* 0... mat ch mat ch correspond March 2003 OMG-Unified Modeling Language, v1.5 2-303 2 UML Semantics • loopVariable: OutputPin[0..*] A (possibly empty) list of output pins (owned by the iterate action) whose values represent the accumulated result of executing the action so far. During the first execution of the subaction, each pin holds a copy of the corresponding loopVariableInput pin (among the input pins of the iterate action). During each subsequent execution of the subaction, each pin holds a copy of the value on the corresponding suboutput pin within the previous execution of the subaction. • subinput:OutputPin[1..*] A nonempty list of output pins (owned by the iterate action) whose values represent one slice of the input collections during one execution of the subaction. During each execution of the subaction, a different slice of values appears on the pins. The pins are available to the subaction. The type of each element pin must match the type of element held by each collection on the corresponding input pin. • suboutput: OutputPin[0..*] A (possibly empty) list of available output pins owned by the subaction. They represent updated values of the loop variables computed by the subaction. After each execution of the subaction, the values on these pins are copied to the loop variable pins for the next execution of the subaction or the output result of the overall iterate action. This list of pins must match in number and types the loopVariable pins. Inputs • collectionInput: V[1..*], where V[i] = Collection of T[i], in which T are from subinput [These input pins are owned by the iterate action itself.] Each input pin holds a collection of values. All the collections must have the same shape and number of elements, but the types of elements in the various pins may differ. During each execution of the subaction, one value from the same position of each collection constitutes a slice of values available to that execution of the subaction as the values of the subinput pins. The subaction is executed once for each position in the input collections, in order from first to last position. • loopVariableInput: U [0..*], where U are any user classes [These input pins are owned by the iterate action itself.] The number of pins must equal the number of loop variable pins and the type of value in each pin must match the type of element in the corresponding loop variable pin. The values on these pins represent the initial values for the loop variables. During the first execution of the subaction, the loop variable pins hold copies of the values on the corresponding loop variable input pins. Outputs • loopVariable: U [0..*], where U are the same as on loopVariableInput [These output pins are owned by the iterate action and accessible only within the subaction. The values are not accessible outside the iterate action.] During the first execution of the subaction, each loopVariable pin has the value of the corresponding loopVariableInput pin. On each subsequent execution, each loopVariable pin has the value of the corresponding suboutput pin after the previous execution of the subaction. 2-304 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics • result: U [0..*], where U are the same as on loopVariableInput [These output pins are owned by the iterate action itself.] The number of pins must equal the number of loop variable input pins and the number of loop variable pins, and the types of pins in each corresponding position must match. After the execution of the subaction on the final slice of values from the input collections, the result pins have values equal to the values of the suboutput pins on the final execution of the subaction. If the input collections are of size zero and the subaction is consequently not executed, the result pins get copies of the values on the loop variable input pins. • subinput: T [1..*], where T are user classes [These output pins are owned by the iterate action itself but are accessible only within the subaction, not accessible outside the iterate action.] During the execution of a subaction, each subinput pin has a value equal to the value of the element in a given position of the corresponding collectionInput collection. During each subsequent execution of the subaction, the position moves through the collections from first element to last element. • suboutput: U [1..*], where U are the same as on loopVariableInput [These output pins are owned by actions nested within the subaction. They are accessible only within the iterate action.] The number and types of the subinput pins must match the loopVariable pins. At the completion of an execution of the subaction, the list of suboutputs will have values. The value of each suboutput pin becomes the value of the corresponding loopVariable pin during the next execution of the subaction. Semantics 1. When all control flow and data flow prerequisites of an iterate action are satisfied, the execution of the iteration begins. All of the values on loopVariableInput pins are copied into a newly created set of loopVariable values owned by the iteration execution. 2. For each position with the tuple of inputCollection collections, the subaction is executed once. The executions are sequential, in the same order as the elements in the input collections. If the collections are unordered or if the isUnordered flag is true, then the order of processing elements is undefined and nondeterministic. For each execution of the subaction, the subinput pins of the execution receive the values corresponding to the given element position in the respective input collections. The execution also has access to the loopVariable values created by the iteration execution (for the first iteration) or updated by the previous subaction execution (for subsequent iterations). 3. When the execution of a subaction is complete, the values of its suboutput pins are copied to the corresponding loopVariable pins for the next iteration. 4. When the subaction has been executed once for each slice of the input collections, the value on each loopVariable pin is copied to the corresponding result pin of the iteration action. The execution of the iteration action is complete. March 2003 OMG-Unified Modeling Language, v1.5 2-305 2 UML Semantics 2.23.2.4 MapAction Figure 2-58 Map action The map action applies a subaction to each input slice. If the subaction has output pins, then the map action has that same number of outputs, each of which is a collection with the same size as the input collections. Any values produced on the suboutput pins are formed into collections, each containing one value from each execution. The subaction is executed concurrently, once for each input slice. If executions of the subaction conflict (because they write shared objects), then the result is indeterminate. The map action has zero or more output pins, each of which holds a collection. The output collections from the map action have the same size as the input collections, and each output value occupies the corresponding position in its collection, but the types of the collections may differ from each other and the input collections. The number of output collections need not equal the number of input collections. The subaction may access available scalar inputs from outside the map action, but no output pin of the subaction is available outside the map action. Attributes None Associations • subaction: Action[1..1]An action to be executed once for each input slice. During each execution of the subaction, one element value from each input collection (i.e., a slice) is made available to the subaction. The subaction must produce one output slice (i.e., one value for each output collection). InputPin OutputPinMapAction 1..* 0..1 +/argument 1..* {ordered} 0..1 0..*0..1 +/result 0..*{ordered}0..1 1..*0..1 +subinput 1..* {ordered} 0..1 0..*0..* +s uboutput 0..* {ordered}0..* pin of the subaction correspond correspond 2-306 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics • subinput: OutputPin[1..*] Each output pin has a type that matches the element type. The subaction is executed once for each slice in the input collections. During each execution of the subaction, a value from each slice is copied to the corresponding subinput pin. • suboutput: OutputPin[0..*] The number of suboutput pins matches the number of output pins of the map action, and each suboutput pin has a type that matches the element type. The value from each suboutput pin is copied to the corresponding map action result pin at the same position in the collection as the input slice to the subaction. Inputs • argument: T [1..*], where T[i] = Collection of U[i], in which U is on subinput [These input pins are owned by the map action itself.) An ordered list of collections. The collections may have different types but all of them must have the same number of elements. Outputs • result: W [0..*], where W[i] = Collection of V[i], in which V is on suboutput [These output pins are owned by the map action.] An ordered list of collections. Each collection has the same collection type and element type as the corresponding argument collection, and all of them have the same number of elements as the input collections. After completion of execution of the subaction for each slice of input values, the value of each element in each output collection is equal to the value of the corresponding suboutput pin after the execution of the subaction for the same position in the input collections. • subinput: U [1..*], where U are user classes [These output pins that are owned by the map action. The pins are accessible within the subaction but are not accessible outside the map action.] The subaction is executed once for each element position in the input collections. During each execution of the subaction, each subinput pin has a value equal to the value of the element in the given position of the corresponding input collection. • suboutput: V [0..*], where V are user classes [These output pins are owned by actions nested within the subaction and are accessible only within the map action.] At the completion of each execution of the subaction, the suboutput pins have values computed during that execution of the subaction. The result values of the map action in a given element position are copied from the suboutput values of the subaction execution for that position of input elements. Semantics 1. When all the control and dataflow prerequisites of the action execution have been satisfied, it begins execution. The argument values must all be collections of the same size and kind, otherwise the model is ill formed and its subsequent behavior is undefined. A subordinate action execution is created for each position in the group of collections. The element value at the given position in each collection is copied March 2003 OMG-Unified Modeling Language, v1.5 2-307 2 UML Semantics to the respective input pin of the subordinate action execution corresponding to the position in the collections. (Each subordinate action has an input pin corresponding to each input pin of the map action.) 2. The subordinate action executions execute concurrently. When a subordinate action execution completes, it has values available on its designated suboutput pins (if any). 3. When all of the subordinate action executions have completed, a group of output collections are created, each containing elements of the same type as one of the suboutput pins of the subaction. Each collection kind is the same as the (common) collection kind of the input collections (i.e., set, list, etc.). For each subordinate action execution, the value of each suboutput pin is copied to the position in the respective output collection corresponding to the position of the input values for that execution.The output collections are placed on the output pins of the map action and its execution is complete. 2.23.2.5 ReduceAction The reduce action applies an associative binary subaction repeatedly to adjacent pairs of slices from the input collections, until the (intermediate working) collection is reduced to a single slice of scalar values, which together constitute the output values of the reduce action. The order in which the subaction is applied to pairs of values is indeterminate, and does not affect the ultimate result if the action is associative, unless the subactions are not isolated from each other, in which case the result is unpredictable. As an example, consider a collection comprising four integers in order: 2, 7, 5 and -3. The result of applying the reduce action to this collection with the binary associative subaction Addition is the scalar 9. This can be computed by any of the following orderings: ( ( (2+7) + 5) + -3) = 11; (2 + (7 + (5 + -3))) = 11; ((2 + 7) + (5 + -3)) = 11. When the subaction is symmetric, as with addition, the order of the elements in the collection is not important. However, some associative operations are not symmetric, such as matrix multiplication, so A × B is not the same as B × A. In these cases, the concept of adjacency of the elements and the order in which they appear is critical. The reduce action requires a subaction, which must be a binary associative operator. Each of the two inputs to the subaction is a slice from the input collections to the reduce action. For example, to sum all the balances for a customer’s account, the reduce action has a single input collection of account balances, and a single scalar output, the sum of those balances, which must necessarily be of the same type. Each of the two inputs to the subaction, Addition, takes “a slice from the input collections to the reduce action,” which in this case is a single account balance on each input. The output is a tuple with the same structure: a balance. When the reduce action has several input collections, then one slice across all collections will be one input to the subaction and another slice will constitute the other input. The reduce action executes the subaction one fewer time than the size of the input collections., because it operates on adjacent pairs of slices from the input collections. The output of the subaction conceptually replaces the two input slices in the collection 2-308 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics of tuples, so the subaction can be applied repeatedly to pairs of slices until a single slice remains. Its value is place on the result output pins of the overall reduce action as scalars. In other words, the reduce action serves to reduce a collection of values to a single value by repeated application of a binary function. If the subaction accesses values from outside the reduce action, such values will be the same for all the concurrent subaction executions during a single execution of the reduce action. No output pins of the subaction may be connected outside the reduce action. The isUnordered attribute states that the reduction can be applied to the slices in any order, even though the ordering of elements in each collection is still used to match corresponding elements into slices. This will be mathematically valid if the subaction is symmetric and the actions are isolated. Figure 2-59 Reduce action Attributes • isUnordered: Boolean If true, indicates that the slices of values may be given to the successive executions of the subaction in any order. This should be set only if the final result is insensitive to execution order. If false, the subaction is executed on slices of the collections in order from first to last, in accord with the scan order of the particular kind of collection. If the collection is a set, then the iteration order is automatically unordered and this flag has no further effect. Inp ut Pin Out putPi nReduceAction isUnordered : Boolean 1.. * 0..1+/argument 1.. * {ordered} 0..1 1..* 0..1 +/result: Value 1..*{ordered} 0..1 1..*0..1 +leftSubinput 1..* {ordered}0..1 1..*0..* +suboutput 1..* {ordered} 0..* 1.. * 0..1 +rightSubinput 1.. * {ordered}0..1 pin of the subaction correspond correspond correspond correspond March 2003 OMG-Unified Modeling Language, v1.5 2-309 2 UML Semantics Associations • subaction: Action An action that is executed repeatedly on adjacent pairs of slices. The action produces a slice with the same size. • leftSubinput: OutputPin[1..*] A nonempty list of output pins (owned by the reduce action), which represents the first of two tuples that are input to the subaction. On each execution of the subaction, these pins hold the values in the first of two adjacent slices in the working collection of the reduce action. The number of pins and their types must match the output pins of the reduce action. • rightSubinput: OutputPin[1..*] A nonempty list of output pins (owned by the reduce action), which represents the second tuples input to the subaction. On each execution of the subaction, these pins hold the values in the second of two adjacent slices in the working collection of the reduce action. The number of pins and their types must match the output pins of the reduce action. • suboutput: OutputPin[1..*] A nonempty list of available output pins owned by the subaction, which represents the results of executing the subaction. After each execution of the subaction, the slice of values on these pins replaces the two adjacent slices in the working collection that served as subinputs to the subaction. The number of pins and their types must match the output pins of the reduce action. Inputs • argument: U [1..*], where U[i] = Collection of T[i], in which T are from result [These input pins are owned by the reduce action.] The input collections to the reduce action. Outputs • result: T [1..*], where T are user classes These output pins are owned by the reduce action. The corresponding result, leftSubinput, rightSubinput, and suboutput pins all have the same type, equal to the element type of the corresponding argument collection.] After the final execution of the subaction, each result pin has the value equal to the value of the corresponding suboutput pin after completion of the final execution of the subaction. • leftSubinput: T [1..*], where T are the same as in result [These l output pins are owned by the reduce action. The values are accessible within the subaction but are not available outside the reduce action.] During each execution of the subaction, each pin has the value of the corresponding suboutput pin on a previous execution of the subaction. • rightSubinput: T [1..*], where T are the same as in result [These output pins are owned by the reduce action. The values are accessible within the subaction but are not available outside the reduce action.] During each execution of the subaction, each pin has the value of the corresponding suboutput 2-310 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics pin on a previous execution of the subaction. The leftSubinput and the rightSubinput come from adjacent positions in the implicit intermediate collections that start with the argument collections and end up as collections of size one. • suboutput: T [1..*], where T are the same as in result [These output pins are owned by actions nested within the subaction. These are accessible only within the reduce action.] After the completion of each execution of the subaction, the suboutput pins have values computed during that execution. Each suboutput value conceptually replaces the adjacent pair of values that supplied the left and right subinput values from the implicit intermediate collection, thereby reducing the size of the intermediate collection by one element. When the size of the intermediate collections is one, the values of the suboutput pins on the final execution of the subaction become the results of the reduce action. Semantics 1. When all control flow and data flow prerequisites of an iterate action are satisfied, the execution of the reduce action begins. The tuple of argument collections is conceptually copied to a temporary working store of collections that accumulates intermediate results of the action. The original input collections are not modified by the action. 2. Two contiguous positions in the intermediate working store are selected nondeterministically and a subordinate execution of the subaction is created. The subaction execution receives the first slice of intermediate collection values as a tuple of leftSubinput pin values, and it receives the second slice of intermediate collection values as a tuple of rightSubinput pin values. If the collections are unordered or if the isUnordered flag is true, then any two elements may be selected nondeterministically. 3. Additional pairs of contiguous positions may be selected nondeterministically for concurrent execution of the subaction, provided they do not include positions already selected for execution. 4. When a subordinate action execution completes, the tuple of values on its suboutput pins replaces the pair of slices of values within the intermediate working store. For collections more complicated than lists, the specifier must define what it means to replace two elements by a single element. 5. Step 2 is repeated as long as the working store contains more than one element position. At any point, more than one execution of a subordinate action may be working on a pair of element positions. 6. When the size of each collection in the working store has been reduced to one element, the value of the element from each collection in the working store is copied to the corresponding result position of the reduce action. The execution of the reduce action is complete. The execution order of the reduce action is nondeterministic. If, however, the subaction represents an associative operator (i.e., (x op y) op z = x op (y op z)) and multiple executions of the subaction do not conflict, the result value will be insensitive to execution order, so the result value will be deterministic for ordered collections. If, in March 2003 OMG-Unified Modeling Language, v1.5 2-311 2 UML Semantics addition, the subaction represents a commutative operator (i.e., x op y = y op x), then the result value will be insensitive to the order of elements, so the result value will be deterministic for unordered collections (including the use of the isUnordered flag). Many common operations (e.g., sum, maximum value, union) satisfy these properties, and the normal intent of the reduce action is for use in such cases. 2.24 Messaging Actions These actions exchange messages among objects. An initial message from one object to another is called a request. The sender of a request may simply continue execution immediately without concern for the behavior invoked by the request (an asynchronous invocation), or it may choose to suspend execution until the activity invoked by the request reaches a well-defined point and sends a reply message back to the requestor, with optional return values (a synchronous invocation). If the request is synchronous, the behavior of the receiver must have a well-defined reply point; if the request is asynchronous, a reply is optional. The receiver may handle a request in various ways based on its organization, including procedure execution and triggering a state machine. The requestor need not be aware of how the request will be handled. The messaging model covers a wide range of ways to match behavior to requests, including state machine triggers, fixed procedures, class-based method lookup, method combination (such as before-after methods), object-based delegation (as in self), and so on. In all cases, the effect is processed by a distinct context from the context of the requestor and the messaging information is transmitted among requestor and target by value. This messaging model fully supports distributed processing without special mechanisms. This model unifies operations and signals into a single concept. The actions CallOperationAction, SendSignalAction, and BroadcastSignalAction provide the functionality found in traditional programming languages without the generality of the full messaging mechanism. Logically, they could be considered special cases of the unified messaging actions, but they may be implemented directly without using the unified messaging mechanisms. 2.24.1 Request A request represents a request for service made by a requestor object to a target object. It includes both the kind of service to be performed (such as a particular operation or signal) as well as the parameters of the service request (the parameters of the operation or signal). A request is modeled as an object. The class of the request object represents the specific kind of service requested, that is, the operation to be performed or the signal to be handled. The attributes of the object represent the parameters of the service request, that is, the parameters of the operation or signal. The target object is specified separately from the request information. A class used for request objects is called a request class. There is one request class corresponding to each operation and signal. Request classes may be organized into generalization hierarchies (subject to constraints by the modeler), and request resolution mechanisms may use such hierarchies in matching requests to behavior. Request classes are defined in user models explicitly or implicitly from other elements, such as operations. 2-312 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics There is nothing special about request or reply classes. A class is known to be a request or reply class because it is used in invocation actions, not because it has any particular structure, therefore no Request or Reply metaclasses are defined in the model. 2.24.2 Asynchronous Invocation An asynchronous invocation is the transmission of a request from a requestor to a target object in which the requestor continues execution immediately, without waiting for a reply. The target object might later communicate to the requestor, but any such communication must be explicitly programmed and it is not part of the asynchronous invocation action itself. Sending a signal and asynchronously calling a procedure are examples of asynchronous invocations. The requestor continues after the invocation without waiting for a response, so the invoked execution need not have a definite termination point. It is permissible to asynchronously invoke a request to a procedure that eventually issues a reply; the reply message is simply discarded. The reverse is not allowed: a synchronous invocation that activates behavior without a distinct reply will leave the invocation hanging forever (although implementations can attempt to detect this and provide some kind of exception handling to deal with it as a programming error). The execution of an asynchronous invocation has the following structure: • the requestor creates a request object and sends it to a target object by means of an asynchronous invocation action; • once the invocation is set up, the requestor continues execution without further direct interaction with the invoked execution; • the request object is transmitted to the target object, which might take some time in a distributed system; • the request object arrives at the target object and is kept until the receiver is ready to handle it. Real-time extensions to UML might define queuing orders, priority mechanisms, and so on, but they are beyond the scope of the basic action semantics, which leave the order of handling requests undefined; • the receiver begins handling the request; • the type of the request object is matched against information in the target object, and the request is resolved into a behavioral effect, usually involving the execution of a procedure; • a procedure may be executed. This definition of asynchronous invocation is meant to encompass both asynchronous calls as well as traditional signals that trigger state machines, as well as other models of computation. From the requestor’s viewpoint, these are all requests that do not wait for a reply. The modeler may change the implementation of the request without changing the invocation. The action semantics provides a general framework and does not limit or specify the exact resolution mechanism. March 2003 OMG-Unified Modeling Language, v1.5 2-313 2 UML Semantics 2.24.3 Synchronous invocation A synchronous invocation is the transmission of a request from a requestor to a target object in which the requestor waits for a reply from the invoked execution. The invoked execution may supply return values, but even if there are no return values, the requestor waits for a reply indicating that the invoked execution has completed. A behavior invoked by a synchronous request must therefore have a definite reply point, even if there are no return values, because the reply point indicates the point at which the requestor may continue execution, possibly concurrently with the remainder of the invoked execution. With no loss of generality, we may think of the invoked execution as sending a reply object back to the requestor. The reply object is an object whose attributes represent the return values, but even if there are no return values, the sending of the reply message and its receipt by the requestor allow the requestor to continue execution. In the most general case, the requestor may use the type of the reply message as well as its values (for example, to distinguish different kinds of values or indicate exceptional situations), although many programming languages may choose to constrain the return type to a predetermined type. The execution of a synchronous invocation has the following structure: • the requestor creates a request message object and sends it to a target object by means of a synchronous invocation action, at which point the execution of the requestor is blocked; • the request message is transmitted to the target object, which might take some time in a distributed system; • the message arrives at the target object and is kept until the receiver is ready to handle it. Real-time extensions might define queuing orders, priority mechanisms, and so on, but they are beyond the scope of the basic action semantics, which leave the order of handling requests undefined; • the receiver begins handling the request; • the type of the message is matched against information in the target object, and it is resolved into a behavioral effect, usually involving the execution of a procedure; • the procedure is executed and at some point a reply message is generated; • the reply message is transmitted back to the requestor; • the requestor is given the reply message and execution of the requestor is allowed to proceed. This definition of synchronous invocation is meant to encompass both traditional operation calls and also calls that trigger state machines, as well as other models of computation. From the requestor’s viewpoint, these are all requests that wait for a reply. The modeler may change the implementation of the request without changing the invocation. The action semantics provides a general framework and does not limit or specify the exact resolution mechanism. 2-314 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.24.4 Request Handling To support a wide range of behavior in mainstream and more innovative languages, the skeleton description of invocation may be parameterized in the following ways, which must be specified as part of a UML extension or profile defining the given system environment. These represent different semantic variation points on the behavior of the invocation mechanism: • The handling of requests by an object may be sequential or concurrent, according to the specification of the target object (not the requestor) and the type of request. • Sequential handling corresponds to a state machine on the target object, the guarded execution of a procedure, or the direct inline receipt of a request by an executing procedure. Such execution cannot proceed until previous executions by the target object or the resolved procedure have completed, and there is sharing of control state across subsequent executions. • Concurrent handling corresponds to the execution of a procedure in its own context, regardless of other executions; for example, a traditional procedure call. Such execution can proceed immediately on receipt because it automatically generates a new execution context, and sharing of information is only through the attributes of the target object. • The order in which requests are handled may be specified by the received object. This permits the definition of queuing and priority mechanisms. This document does not specify such possible mechanisms, but we would expect them to be specified in a real-time profile, for example. • The transmission of messages may be subject to delays and errors. We do not elaborate this possibility in this document, but we expect it to be pursued in real- time profiles. • The way in which a request type determines the execution of one or more procedures (and other behavioral effects) is called resolution. It represents a more general form of method lookup and is expanded in more detail later. Triggering state machine transitions, selecting a method attached to an ancestor of the target object type, and object-based delegation are all varieties of resolution. • Sending a reply message can be an explicit action or it can be implicit in the structure of the procedures. All messages are transmitted “by value.” That is, a message object itself has no identity; its attribute values can be freely copied without loss of information. However, the values of the attributes within a message may be object references, that is, they may reference instances. In other words, a value may be a simple data value or a reference to an identity. An “in-out” parameter includes a value in both the request and reply objects. A send is similar to a call, except that the sender continues execution immediately and has no further interaction with the invoked execution. If the invoked execution attempts to send a reply, the reply message is immediately discarded. March 2003 OMG-Unified Modeling Language, v1.5 2-315 2 UML Semantics 2.24.5 Reply Handling A traditional procedure expects a request of a specific type and generates a reply of a specific type. The messaging model presented here permits variants on both the request to and the reply from a single procedure. Variant replies would permit a procedure to return objects of different types depending on circumstances. This would permit handling unusual or exceptional situations without extra flags or special data values. Inline exceptions are considered as simply another type of reply value (see Section 2.25.3, “Exceptions,” on page 2-335). If the execution of a called procedure generates an exception that cannot be handled within the called procedure, the exception object is returned to the caller as a reply object. No special indication is necessary that it is an exception. In fact, the caller is free to treat it as an ordinary reply value (presumably within a case statement on reply types). If the reply type violates constraints on the expected reply type, then it is raised as an exception in the scope of the execution that made the call, permitting the exception handling mechanisms to come into play. This approach unifies exception handling with variant reply types and allows the caller and the executed procedure to choose independently between explicit exceptions and multiple reply types. 2.24.6 Procedures A procedure is a structured set of actions that can be invoked as a behavior entity. An action can only be executed as part of a procedure execution; individual actions may not be referenced outside their procedures. A procedure represents a distinct, closed context. No variables are shared among caller and called procedure. A procedure also does not have “global variables” or “static variables” that hold state. Any such state must be implemented using objects. Because it has no state, many executions of the same procedure are conceivable on the same object, each with its own execution context. This does not mean that all procedures must support such simultaneous access, and many will not, but simply that the structure of procedures does not prevent it. The target object can be different from the requesting object and they can have different classes. We do not distinguish “local calls” from “remote procedure calls;” semantically, there is no difference. There is an implicit chain of call executions during execution, but no need to assume that they are organized into a stack or owned by an explicit task, thread, or process. Such things are implementation choices that can be implemented in different ways. While the execution of a procedure invoked by a synchronous invocation is progressing, the requesting action execution is “blocked.” This does not require any special mechanisms; the synchronous action execution is simply in the “executing” state until the invoked procedure execution terminates and returns. The called procedure execution has, as part of its state, sufficient information to identify the calling action execution. There is no special “return” action available to a procedure. A procedure execution returns when it completes the execution of its action, and the 2-316 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics output values of the procedure are used as the return values. If the invocation was asynchronous and the request was repliable, any output values are formed into a reply object which is transmitted asynchronously to the invoking object. A procedure has an input value and an output value, both represented as objects without identity (or snapshots). In the most usual case, the input value is immediately unmarshalled into its constituent attribute values and is not available in the procedure as an object, but other variations are possible. 2.24.7 Performing requests A request has a request type and a list of argument values. A request is modeled as an object. The type of the object represents the request type. The attributes of the request class represent the parameters. Because the request type and its parameters are modeled as a single class, there is no possibility of an incorrect argument list or missing arguments. Making a request requires a list of argument values that have been marshalled into a request object. The action semantics does not restrict the manner in which request objects are produced. For a typical operation call, all the argument values could be generated concurrently and then used to generate a request object. However, request objects can also be produced in several stages, starting with a raw object of the correct type and then initializing attribute values one at a time. All that matters is that a valid request object be available when the request action is performed. Note that a request object is transmitted “by value,” therefore the identity of the request object supplied to the request action is irrelevant, and the contents of the object can be copied if convenient for the semantics or the implementation. The attribute values themselves may include object identities, each of which must continue to identify the same object in spite of any implementation encodings due to transmission. Requests may be sent to any object. Each object determines how it handles requests that it receives. All requests to the same object need not be handled the same way. Some requests may invoke methods and some may trigger transitions. The manner of handling a request is discussed later under Resolution. The execution of a method creates a new procedure execution and does not affect an existing state machine or running action execution. The activation of a method creates, from the point of view of the receiver, a new “thread of control” that executes alongside existing “threads of control” on the same object, but without sharing control or variables. Different executions interact only indirectly, through the attributes of the target object, which are shared by all executions on it. The triggering of a transition is possible only if the target object has a state machine execution attached to it. Triggering a transition does not create a new thread of control. The execution proceeds in the context of the existing state machine execution, when the state machine is ready to handle the request. March 2003 OMG-Unified Modeling Language, v1.5 2-317 2 UML Semantics 2.24.8 Effect Resolution A request is an unsolicited message sent from a requestor object to a target object that causes behavior when it is received by the target object. (The other kind of message is a reply, which goes directly to a blocked execution, not to an object, and is expected by it.) The mechanism of turning a received request into execution is called resolution. The requestor need not know how the request will be resolved, and therefore need not change even if the manner of handling the request is changed. Resolution is a framework within which different kinds of behavior can be specified. UML extensions or profiles would be needed to specify new kinds of behavior. Here are 3 common mechanisms for resolving requests that have appeared in various programming languages. These are not meant to be comprehensive, and others might be proposed in the future. 1. The request type is used to determine a procedure to be executed. The procedure execution receives the request object as its input value. When the procedure execution completes, if the invocation was synchronous, its output value is a reply message that is transmitted back to the requesting execution. If the request was asynchronous and repliable, then its output value is a reply message which is transmitted to the invoking object as an asynchronous request. If the request was asynchronous and not repliable, the reply message is not generated. The request type corresponds to an operation, the attributes of the request to the arguments of the operation, and the attributes of the reply message to the return values. This mechanism corresponds to a traditional operation call (synchronous or asynchronous, as the case may be). In some variations, multiple procedures can be executed, and the resolution mechanism must indicate their order of execution and which one supplies the reply value. 2. The request type is used to trigger a transition within the state machine execution attached to the object. Requests are stored until the state machine execution is quiescent and chooses to handle one of them. If the request type matches an event on a transition leaving the current state (subject to the full rules of transition firing), the transition fires. Firing a transition updates the state of the object. If there is a procedure attached to the transition, it is executed. When the procedure execution completes, its output value is a reply message that is transmitted back to the calling execution (for a synchronous request) or to the calling object (for an asynchronous, repliable request). Typically more than one transition can execute on a single firing (e.g., entry and exit transitions). The resolution mechanism must indicate which procedure supplies the reply value. If the request is asynchronous and not repliable, then any output values are ignored and no reply message is sent. In traditional terms, the request type corresponds to a signal, its attributes to the attributes of the signal, and any attributes of the reply message to return values on a call event. 3. The request is explicitly read by an execution using an explicit action. In this case, requests are held in a queue until the execution explicitly reads them. When the execution reads a request, the execution gains access to the request data and may take whatever actions it likes. The execution also gets a handle to the return information, which it can later use implicitly to send a reply message. It may not 2-318 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics manipulate the return information, however. This mechanism corresponds to traditional interprocess communication and would require a UML extension or profile in which executions are directly manipulable at run time. In practice, the resolution mechanisms will often be specified for a particular kind of system or a particular request type, but we define them in a general way that can cover many different kinds of systems. We do not imply that the actual implementation of a system must be identical to this logical model; only the final effect must be the same. The following sections describe each kind of resolution mechanism. 2.24.9 Operation Lookup The phrase operation lookup refers to mapping a request type (e.g., an operation) to a procedure (e.g., a method) in the context of an object. In Smalltalk or C++, operation lookup is based on the class of an object and the class hierarchy, but other languages support other kinds of operation lookup, which we wish to encompass in the action semantics. For example, self supports an object-based lookup mechanism and CLOS supports before- and after-methods. The following list describes the possible kinds of operation lookup: 1. An operation map (a set of operation-method pairs) is attached to an object. If a request type matches an operation in the map, the corresponding method is executed. If the operation is not found, then a link points to another object that is then searched. This is the concept of delegation. 2. An operation map is attached to a class. The map on the type of the object is examined. If a request type matches an operation in the map, the corresponding method is executed. If the operation is not found, then a link points to another class that is then searched. This is the concept of inheritance. 3. An operation map is defined globally. If a request type matches an operation in the map, the corresponding method is executed. This is the concept of a direct procedure call (i.e., traditional). A further variation allows the execution of more than one matching procedure from different maps. The order in which the procedures are executed is part of the particular operation lookup mechanism. Another variation would allow several kinds of maps on each element, with matching methods to be executed in a designated order. For example, CLOS supports 3 kinds of maps: a before map, a main map, and an after map. First, all the matching methods on the before map are executed, starting at the top of the class hierarchy; then the most specific match in the main map is executed, then all the matches in the after map, ending at the top of the class hierarchy. Only the return value from the main match is returned to the caller. Section 2.24.16, “Optional Profile for Resolution of Operations and Signals,” on page 2-330 describes one way that traditional operation calls as in variation 2 above could be implemented. March 2003 OMG-Unified Modeling Language, v1.5 2-319 2 UML Semantics 2.24.10 Transition Triggering The phrase transition triggering refers to mapping a request type (a signal) to a procedure (a procedure) in the context of an object with a state machine. A state machine may be attached to the object or, more usually, to the type of the object. The object has a current state (which may decompose into a set of primitive states). The state of the object is a state (or set of states) in the attached state machine. The following rules, summarized from the state machine package, are suitable for implementation of request resolution with no change in semantics: The following item describes the event lookup: 1. A transition map (a set of event-procedure-next state tuples, with some additional information) is attached to a state on the state machine attached to the type of the target object. If a request type matches an event in the map, subject to various qualifying information (such as conditions), the corresponding procedure is executed and the current state is updated. The request object is delivered to the procedure execution. If the event is not found, then a link points to another state that is then searched. This is the concept of nested states. If any entries or exits are triggered, the request object is delivered to any triggered procedures. 2. Same as above, except the state machine is attached directly to the object. This idea pushes the state of the art but it seems compatible with object-level method lookup. The normal nested-state variation allows multiple matches, somewhat similar in spirit to CLOS before-after methods, although not identical: exit transitions and entry transitions are executed on the path from the old state to the new state. Many variations are possible. The state machine packages appear s in a form directly amenable to resolution, provided Signals are regarded as request objects. A “synchronous signal” (formerly “call event”) is a request sent by a synchronous invocation action that is resolved into a transition trigger rather than a method. The manner of handling this is not restricted by the action semantics, but one variation that implements the correct semantics is as follows: If a state machine has a transition triggered by a synchronous invocation object, the request object is delivered to each procedure attached to a triggered transition. When a transition is triggered by a request, the procedure is executed. When the execution of the procedure attached to the main transition (that is, the one directly triggered by the request) is complete, its output values are formed into a reply message and passed back to the action that issued the call request, and it becomes the output of the call action. If the request triggers exit or entry transitions, only the main procedure attached to the main transition is used to determine the reply. (Other rules are possible for determining the return values.) 2.24.11 Direct Communication among Executions Usually invocations are handled implicitly by some underlying execution machinery that manages the gathering of packets by a target object, their storage until the object is ready to process one of them, and the selection and resolution of a request into a behavioral effect. This approach characterizes method invocation and state machine 2-320 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics triggering. It is also possible, however, for executions to explicitly receive requests and generate replies. This kind of usage is characteristic of kinds of real-time computation. The mechanisms for such interaction are not specified in this document, but they could be defined in a UML extension or profile. 2.24.12 Strong Typing The action semantics attempts to define actions in a general way that accommodates both mainstream, strongly-typed languages as well as alternative languages. The messaging model presented here does not require strong typing but is compatible with it. It can operate on an object basis (as in self), in which case typing is irrelevant. It can operate on a class basis in which run-time types are used for request resolution (as in Smalltalk). It can also operate on a class basis with predefined types for requests and replies, to support strong typing as in C++ and other languages. In general, in this messaging model, a request is an object whose type is determined at run time. This model is usual for signals. However, most languages assume that an operation is specified as part of a call at compile time. This may be modeled in the Action Semantics as a constraint on the type of the request and reply objects, corresponding to fixing the operation. This model can also accommodate pointers to operations. For example, an integrate procedure takes as one of its parameters a pointer to the function to integrate. This is easily handled in this model because the request is an object representing the function. A constraint can be placed on the type of request object that might be passed. For example, the integration function must be an operation with one numerical input and one numerical output. Rather than fixing the exact operation, any operation that meets the constraints could be used. Variant reply types in a strong typing system are interpreted as jumps within the scope of the calling action and trigger the jump handling mechanisms (Section 2.25, “Jump Actions,” on page 2-332). 2.24.13 Transmitting messages The execution of request invocations implies “information in transit.” The action semantics in this document are not affected by the presence of a request in transit, because there is no way for an action to access this state. UML extensions or profiles could be specified in which the format of transmitted messages is defined and actions are provided to access it at run time. Similarly, profiles could be specified in which transmission time or the possibility of errors during transmission are present. All such profiles are likely to be implementation dependent. 2.24.14 Return information During the execution of a synchronous invocation, the invoked procedure execution must have sufficient information to be able to awaken the invoking action execution when execution of the invoked procedure is complete. The manner in which this March 2003 OMG-Unified Modeling Language, v1.5 2-321 2 UML Semantics information is stored is part of the implementation and is not defined here. An invoked procedure execution has no explicit access to such information; it is used implicitly on the completion of the procedure execution. UML extensions or profiles could be specified in which the format of return information is defined and actions are provided to access it at run time. 2.24.15 Messaging Classes Figure 2-60 Messaging classes metamodel PrimitiveAction (from Action Foundation) AsynchronousInvocationAction is Re pl ia bl e : B oo le an OutputPin (from Action Foundation) SynchronousInvocationAction 1 0..1 +/reply1 0..1 InputPin (from Action Foundation) InputPin (from Action Foundation) InvocationAction 1 0..1 +/target 1 0..1 1 0..1 + /re qu es t 1 0..1 InputPin (from Action Foundation) ExplicitInvocationA ction 0..* 0..1 +/argument0..* 0..1 OutputPin (from Action Foundation) InputPin (from Action Foundation) CallOperationAction isAsynchronous : Boolean 0..1 0..* 0..1 +/result 0..* 0..1 1 0..1 +/target1 Operation 0... 1 0... +operation 1 BroadcastSignalAction Signal (from Common Behavior) 1 0... +signal 1 0... InputPin (from Action Foundation) SendSignalAction 1 0... +signal 1 0... 1 0... +/target 1 0... 2-322 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.24.15.1 AsynchronousInvocationAction Creates a request that is transmitted to the target object, where it causes the execution of an effect, such as a method or the triggering of a transition. The request object is available to the execution of invoked procedures. The requestor continues execution without waiting for the request to be delivered or handled. If the invocation is repliable, a subsequent reply by the invoked execution is transmitted to the requesting object as an asynchronous request. If the invocation is not repliable, any attempt by the invoked execution to issue a reply is ignored. Attributes • isRepliable: Boolean If true, the identity of the invoking object is transmitted as part of the request. If the receiver later reaches a reply point within a synchronous context, a reply message is transmitted to the invoking object as an asynchronous message. If false, the identity of the invoker is not transmitted and any attempt to later issue a reply is ignored. Associations None Inputs • target: T, where T is any user class The target object. Information in the object or the object’s class is used to determine a method procedure or procedures to execute the operation. To send to a set of objects, use a map action around an invocation action. • request: U, where U is any user class An object whose type represents the kind of operation or signal sent and whose attributes are the arguments of the operation or signal. Outputs None Well-formedness rules None. Semantics 1. When all the control and data flow prerequisites of the action execution are satisfied, a copy of the request object is transmitted to the target object. The identity of the request object is not preserved in the transmission, but the identities of its attributes are preserved. (In other words, the request is just a collection of values and has no significance as an object.) If the invocation is repliable, the identity of the invoking object is transmitted as part of the request. The target object may be March 2003 OMG-Unified Modeling Language, v1.5 2-323 2 UML Semantics local or remote. The manner of encoding the transmission, the amount of time required to transmit it, and the path for reaching the target object are undefined. (They are appropriate topics for a runtime implementation profile.) 2. When the transmission arrives at the target object, it causes a behavioral effect on the target object as specified in the target object itself or in the class of the target object. A copy of the request object is available to the behavioral effect. The manner of specifying behavior effects depends on the particular effect. For example, if the request type appears as a reception for the target class, the effect is a signal event for the state machine of the target object; the request object is available as an argument to procedures invoked by transitions caused by the signal. If the request type appears as the signature of an operation for the target class, the effect is the execution of the procedure for the method realizing the operation. 3. If the behavioral effect attempts to return control to a repliable invocation, the reply object is transmitted to the invoking object as an asynchronous request. If the invocation is not repliable, the attempt to reply is simply ignored. 2.24.15.2 BroadcastSignalAction Creates a request signal that is transmitted to all the potential target objects in the system, where it may cause the firing of state machine transitions and the execution of attached procedures. The argument values are available to the execution of attached procedures. The requestor continues execution immediately. Any attempt to issue a reply is ignored. The definition of the set of target objects in the system requires an implementation- dependent specification, as any practical implementation of this action obviously requires a finite set of objects. Attributes None Associations • signal: Signal The kind of signal transmitted to the target object. Inputs • argument: T [0..*], where T = self.signal.attribute.type A tuple of values that become the attributes of the signal. Outputs None Well-formedness rules None. 2-324 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Semantics 1. When all the control and data flow prerequisites of the action execution are satisfied, the argument values are formed into a request object that is transmitted concurrently to each of the target objects in the system. The target objects may be local or remote. The signal type is encoded into the transmission. The manner of encoding the transmission, the amount of time required to transmit it, and the path for reaching the target objects are undefined. (They are appropriate topics for a runtime implementation profile.) 2. When a transmission arrives at a target object, it causes a signal event in the target object. The signal has the type specified by the action and its attributes are the arguments of the action. The effect of receiving a signal event is specified elsewhere; normally it involves causing the firing of a state machine transmission and the execution of an attached procedure. If the isList value of the procedure is true, the original argument values of the broadcast signal action are made available to the procedure execution as the separate values of its argument pins. 3. A broadcast signal action provides no return information to the invoked behavioral effect. If the invoked procedure attempts to return control to the broadcast signal action execution, the attempt is simply ignored. 2.24.15.3 CallOperationAction Assembles the call arguments into an operation call request that is transmitted to the target object, where it causes the selection of a method and the execution of its procedure. The argument values are available to the execution of the invoked procedure as predefined OutputPin values. (They are output pins because they represent values available within the procedure.) The action execution waits until the effect invoked by the request completes and returns to the caller. When the execution of a procedure is complete, its result values are returned to the calling execution. When a return message is received, execution of the action is complete and the return values are used as the result values of the call operation action execution. Note – The semantics of this action could be mapped onto the SynchronousRequestAction and the AsynchronousRequestAction (depending on the isSynchronous flag), so that the semantics of this action are purely derivative. There is no requirement that this be done, however, either in the logical model or in an actual implementation; this action may be implemented directly. Attributes • isSynchronous: Boolean If true, the call is synchronous and the caller waits for completion and a reply. If false, the call is asynchronous and the caller proceeds immediately and does not expect a reply. March 2003 OMG-Unified Modeling Language, v1.5 2-325 2 UML Semantics Associations • operation: Operation The operation to be invoked by the action execution. Inputs • target: T, where T is any user type The target object. The object’s class is used to determine a method to execute the operation. • argument: U [0..*], where U = self.operation.parameter.type for which self.operation.parameter.kind = in or inout A tuple of input values whose types must match the input parameters of the operation (including any in-out parameters). Outputs • result:V [0..*], where V = self.operation.parameter.type for which self.operation.parameter.kind = return or out or inout A tuple of output values whose types must match the output parameters of the operation (including any in-out parameters). Semantics 1. When all the control and data flow prerequisites of the action execution are satisfied, information comprising the operation and the argument pin values of the action execution is created and transmitted to the target object. The target object may be local or remote. The manner of encoding the transmission, the amount of time required to transmit it, and the path for reaching the target object are undefined. (They are appropriate topics for a runtime implementation profile.) If the call is asynchronous, the caller proceeds immediately. If the call is synchronous, the caller is blocked from further execution until it receives a reply as a consequence of the call. 2. When the transmission arrives at the target object, it causes the selection of a method realizing the operation in the class of the target object. The method is selected according to the inheritance rules for inheritance of methods. The procedure implementing this method is executed. The argument values from the call invocation are made available to the procedure execution as the predefined values of its argument pins. If the call is synchronous, the runtime environment encodes (in an unspecified manner) return information sufficient to identify the invoking action execution. The return information is bound to the invoked procedure execution, but is not accessible to it. 3. If the call is synchronous, when the execution of the invoked procedure completes, the values of its result pins are formed into reply information that is transmitted to the calling action execution using the return information bound to the procedure execution. The manner of encoding the reply information for transmission, the time required for transmission, and the transmission path are unspecified. 2-326 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 4. When the reply information arrives at the invoking action execution, copies of the values of its attributes are placed on its result pins, and the execution of the CallOperationAction is complete. 2.24.15.4 ExplicitInvocationAction (abstract) Abstract action that indicates sending a request object to a target object using an explicit argument list. Creates a request that is transmitted to the target object. The request is resolved into a behavioral effect by the target object or its class based on the type of the request. Depending on the kind of action, the requestor may or may not wait for a reply. Attributes None Associations None Inputs • argument: T [0..*], where T is determined by the specific subclass of action A list of values that are the arguments to the invocation. Outputs None -- Depends on subclass. Well-formedness rules None. Semantics See the particular subclass. 2.24.15.5 InvocationAction (abstract) Abstract action that indicates sending a request object to a target object. Creates a request that is transmitted to the target object. The request is resolved into a behavioral effect by the target object or its class based on the type of the request. Depending on the kind of action, the requestor may or may not wait for a reply. Attributes None Associations None March 2003 OMG-Unified Modeling Language, v1.5 2-327 2 UML Semantics Inputs • target: T, where T is any user class The target object. Information in the object or the object’s class is used to determine a method procedure or procedures to execute the operation. • request: U, where U is any user class An object whose type represents the kind of operation or signal sent and whose attributes are the arguments of the operation or signal. Outputs None -- Depends on subclass. Action Description: The request is sent to the target object, where it causes the execution of a method or the triggering of a transition. The request object is available to the execution of invoked procedures. The behavior of the requestor depends on the specific concrete action. Well-formedness rules None. Semantics See the particular subclass. 2.24.15.6 SendSignalAction Creates a request signal that is transmitted to the target object where it may cause the firing of a state machine transition and the execution of an attached procedure. The argument values are available to the execution of attached procedures. The requestor continues execution without waiting for the request to be delivered or handled. Any attempt by the state machine to issue a reply is ignored. Attributes None Associations • signal: Signal The signal transmitted to the target object. Inputs • target: T, where T is any user class The target object. The signal will be sent to this object and processed by its state machine. To send to a set of objects, use a map action around a send signal action or use a BroadcastSignalAction to send indiscriminately to the entire available system. 2-328 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics • argument: U [0..*], where U = self.signal.attribute.type A tuple of values that become the attributes of the signal. Outputs None Well-formedness rules None. Semantics 1. When all the control and data flow prerequisites of the action execution are satisfied, the argument values are formed into a request object that is transmitted to the target object. The target object may be local or remote. The signal type is encoded into the transmission. The manner of encoding the transmission, the amount of time required to transmit it, and the path for reaching the target object are undefined. (They are appropriate topics for a runtime implementation profile.) 2. When the transmission arrives at the target object, it causes a signal event in the target object. The signal has the type specified by the action and its attributes are the arguments of the action. The effect of receiving a signal event is specified elsewhere; normally it involves causing the firing of a state machine transmission and the execution of an attached procedure. If a procedure is executed, the original argument values of the send signal action are made available to it as values of its argument pins (the isList value of the procedure must be true). 3. A send signal action provides no return information to the invoked behavioral effect. If the invoked procedure attempts to return control to the send signal action execution, the attempt is simply ignored. 2.24.15.7 SynchronousInvocationAction Creates a request packet that is transmitted to the target object where it causes an effect, such as the execution of a method or the triggering of a transition. The request object is available to the execution of invoked procedures. The action execution waits until the effect invoked by the request completes and returns a reply message to the caller. When a reply message is received, execution of the action is complete and the reply message is used as the output of the call action execution. Attributes None Associations None March 2003 OMG-Unified Modeling Language, v1.5 2-329 2 UML Semantics Inputs • target: T, where T is any user class The target object. Information in the object or the object’s class is used to determine an effect to execute the operation. • request: U, where U is any user class An object whose type represents the kind of operation or signal sent and whose attributes are the arguments of the operation or signal. Outputs • reply: V, where V is any user class The results produced by executing the selected effect with the given arguments. The number and types of the results is determined by the executed effect. The model may place a constraint on the type of value returned (as with an ordinary operation). Well-formedness rules None. Semantics 1. When all the control and data flow prerequisites of the action execution are satisfied, a copy of the request object is transmitted to the target object. The identity of the request object is not preserved in the transmission, but the identities of its attributes are preserved. (In other words, the request is just a collection of values and has no significance as an object.) The target object may be local or remote. The manner of encoding the transmission, the amount of time required to transmit it, and the path for reaching the target object are undefined. (They are appropriate topics for a runtime implementation profile.) The invoking action execution is blocked until it subsequently receives a return object as a result of the behavioral effect caused by the request. 2. When the transmission arrives at the target object, it causes a behavioral effect on the target object as specified in the target object itself or in the class of the target object. A copy of the request object is available to the behavioral effect. The manner of specifying behavior effects depends on the particular effect. For example, if the request type appears as a reception for the target class, the effect is a signal event for the state machine of the target object; the request object is available as an argument to procedures invoked by transitions caused by the signal. If the request type appears as the signature of an operation for the target class, the effect is the execution of the procedure for the method realizing the operation. The runtime environment encodes (in an unspecified manner) return information sufficient to identify the invoking action execution. The return information is bound to the invoked behavioral effect, but is not accessible to it. 3. A behavioral effect invoked by a synchronous invocation must eventually reach a return point defined by the behavior effect. For a procedure invoked as the method realizing an operation or as a consequence of the firing of a state machine transition, the return point is the completion of execution of the procedure. The definition of the return point includes a set of return values. For an invoked 2-330 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics procedure, the return values are the values on its result pins when it completes execution. Behavioral effects that do not invoke procedure executions must define how their return points and return values are determined. When control within a behavioral effect reaches the return point, a return object of a type specified by the behavioral effect is created, and its attribute values are the return values of the behavior effect. Using the return information bound to the behavior effect, the return object is transmitted to the invoking action execution. The manner of encoding the return object for transmission, the time required for transmission, and the transmission path are unspecified. 4. When the return object arrives at the invoking action execution, a copy of it becomes the value of the reply pin of the action execution, and the execution of the SynchronousInvocationAction is complete. If the invoked behavioral effect never reaches a reply point, either because the effect is an asynchronous effect or the effect gets caught in an endless loop, then the invoking action execution will remain blocked forever, which is probably not a good thing for the designer but does not violate any rules. 2.24.16 Optional Profile for Resolution of Operations and Signals Traditional operations and signals can be modeled using the CallOperationAction and the SendSignalAction, but this does not provide the ability to mix operations and signals and hide the implementation from the requestor. This section defines an optional UML Profile for Messaging of Operations and Signals, or ResolvedFeature for short. This profile is not part of the basic action semantics specification. It is an optional compliance point and need not be implemented to achieve UML compliance. It is expected that other profiles will be proposed to provide other kinds of resolution. This kind of resolution can be implemented using the profile shown in Tabl e. The only additions in this profile are the two stereotyped tags of the OperationResolution stereotype of BehavioralFeature named inputSignature and outputSignature, the values of which are of type Classifier. Each distinct resolved Operation must define two attached Classifiers: one for its arguments (inputSignature) and one for its results (outputSignature). (For an asynchronous operation, there is only one classifier, the inputSignature.) These classes are derivable from the operation specification, namely, the list of parameters, and would not have to be explicitly defined by modelers. The same two classes are attached to the Methods for each Operation. Each distinct resolved Reception must define one attached Classifier, the inputSignature. This Classifier is the Signal classifier itself. If the Reception generates a reply suitable for a synchronous invocation, the Reception must also define an outputSignature classifier. On an invocation action, the type of the request object is matched against the inputSignatures attached to the behavioral features of the class of the target object. If the matching behavioral feature is an Operation, the normal inheritance rules are used to find a Method, whose Procedure is executed with the request object as its single argument. If the matching behavioral feature is a Signal, a signal event occurs in the March 2003 OMG-Unified Modeling Language, v1.5 2-331 2 UML Semantics target object. If the handling of the event results in the firing of a transition that invokes a Procedure, the procedure is executed with the request object as its single argument. If an invocation matches more than one operation and/or signal, then the model is ill formed. If a method is executed on a synchronous invocation, a reply is generated when the execution of the invoked procedure is complete. The output values of the operation are formed into a reply object, whose type is the outputSignature class and whose attribute values are the result values of the operation. The reply object is returned to the calling action execution. If a transition fires as a result of the reception of a synchronous request, the procedure (if any) attached to the transition itself (rather than any entry/exit procedures) is regarded as the main procedure. The reply point occurs on the completion of execution of this procedure. A reply object is created whose type is the outputSignature for the Reception. The output values of this procedure become the attributes of the reply object. The reply object is returned to the calling action execution. Any entry procedures caused by the firing of the transition will execute concurrently with the invoker of the request. If more than one transition is triggered by a synchronous request or if more than one procedure is attached to a triggered transition, the model is ill formed. A more complicated profile could provide for such possibilities by specifying how to choose or assemble the eventual reply object if multiple procedure executions are caused by a transition. In any case, eventually one reply object must be returned to a synchronous requester that triggers a state machine. If an exception or other jump propagates to the top level of a procedure, the jump object becomes the reply object that is returned to the caller. If the type of this object is not the type specified as the output type of the SynchronousInvocationAction, a jump is raised in the context of the action execution and may be handled by a handler on the invocation action execution or may propagate upward. These semantics implement traditional operations and signals in the context of the unified messaging model. Note that the request object can be dynamically created; therefore, this profile supports dynamic operation determination not possible with CallOperationAction. Other profiles could be defined that would implement other semantics, such as object-based delegation (as in self), operations with variant return types, before-after methods as in CLOS, Ada-style rendezvous, etc. Stereotype Base Class Parent Tags Constraints Description Resolved- Feature BehavioralFeature N/A inputSignature, outputSignature none Operations with this stereotype have a resolution mechanism as defined here.. 2-332 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics 2.25 Jump Actions All flow of control for a procedure could use Dijkstra-style, fully nested flow-of- control constructs, but this style can be awkward and obscure when dealing with unusual or secondary conditions that do not follow the main line. Programming languages include constructs such as break, continue, and exceptions for dealing with these situations. When a non-mainline situation occurs, the normal flow of control is abandoned and a different flow of control, specified in the program, is taken. The UML jump construct unifies these nonlinear flow-of-control mechanisms while providing the functionality found in most modern programming languages. 2.25.1 Jumps A jump is a condition that occurs synchronously during the execution of an action or a sequence of actions that causes the abandonment of the normal execution sequence (at a definite known location) and the execution of an alternate action (sequence) that brings the execution to a known state compatible with the successors of the action that would have been executed had the jump not occurred. In other words, under certain conditions, execution of the current action is aborted and control jumps to some enclosing level at which a handler action cleans things up and allows control to resume after the higher level action. A jump is used to handle a situation that is inconvenient to handle using linear flow of control. Jumps are often used to handle unexpected inputs or situations regarded as errors, such as exceptions, but they are not restricted to such use and they may be considered another control mechanism, albeit one that should be used with restraint. The traditional break and continue statements are a typical use of jumps as a static control mechanism. The traditional exception handling mechanism is a typical use of jumps as a more dynamic control mechanism. A jump type is a classifier, in the same way that a signal type is declared as a classifier. There is no jump type metaclass; any class may be used as a jump type. Jumps may be explicitly caused by a jump action. For example, a traditional break statement can be modeled as a jump action with a predefined Break class as the jump type. A primitive action may also cause jumps as part of its behavior for given input values. Such a usage of a jump to handle an abnormal or non-mainline situation is often called an exception. For example, a squareRoot action might specify that the Irrational jump occurs if the input argument is less than zero, and the jump object has one attribute whose value is the square root of the absolute value of the argument. An arrayIndex action might specify that an OutOfBounds jump is caused when an index argument is not legal for an array; the jump type would have the index value and the array bounds as attributes. Tag Stereotype Type Multiplicity Description inputSignature ResolvedFeature Class 0..1 Specifies the class that serves as the request type for a request that resolves to the operation. outputSignature ResolvedFeature Class 0..1 Specifies the class that serves as the reply type for a request that resolves to the operation. March 2003 OMG-Unified Modeling Language, v1.5 2-333 2 UML Semantics The occurrence of a jump is manifested as an instance—a jump object—of the given jump type. The object types indicate what kind of situation caused the jump. The attribute values (if any) describe the situation in more detail. The occurrence of a jump terminates the current action and transfers control to a jump handler attached to the current action. If the current action lacks a jump handler for the given jump type, the jump propagates to enclosing levels of actions. A jump handler may be attached to an action (primitive or composite). A jump handler is a map: a set of jump-type-to-action pairs, similar to the signal-type-to-transition pairs attached to states in state machines. If a jump occurs during the execution of an action and the jump type or one of its ancestor types appears in the jump handler attached to the action, then the execution of the action is abandoned and the handler action corresponding to the jump type is executed instead. A jump object is created with the argument values specified by the action. The jump object is the input to the handler action. The handler action may also access output values in its accessible scope, like any action. The accessible values in a handler are the same as the accessible values in the action that it protects. When the execution of a handler action is completed, the execution of the original action is deemed to be complete and successors are enabled. If the original action has any data flow outputs, each of its handlers must have a list of data flow outputs whose number, order, and types match the output list of the action (otherwise the successors will not have needed values available), therefore an action with handlers has much the form of a conditional. There is one exception permitted: A handler action that always causes a jump during its execution must have zero output pins and need not match the outputs of the protected action (because it will never complete normally). A handler action is ill formed if it can possibly complete normally but the pins do not match. Actions within a jump handler may have jump handlers attached to them. If a jump occurs during the execution of a jump handler action, the execution of the handler action causing the jump occurrence is terminated, and its jump handler (if any) is started. If there is no jump handler, the jump propagates upward. If the propagated jump reaches the top of the jump handler without being handled, it is propagated to the action enclosing the action having the jump handler. If a second jump occurs during the processing of another jump, the original jump is lost. If a jump is handled directly by a handler on the action causing the jump, then nothing else need be done. However, if an action does not have a handler for a jump, then the jump occurrence propagates to the immediate enclosing composite action, where it may trigger a jump handler on the wider scope. If jump propagation occurs, the execution of any successors to the original action will not have begun and the execution of any predecessors of the original action will have completed, so the state of execution of a linear sequence of actions is determinate. Concurrent executions within the composite scope must complete before propagation of the jump may continue. Eventually the addition of an interrupt mechanism to UML would permit concurrent executions to be aborted due to the occurrence of an unhandled jump in another action execution. If a jump is not handled by the outermost action in a procedure, then the execution of the procedure terminates and a reply object is returned to the caller of the procedure. Such a reply object is just an object of a particular reply type, different from the reply 2-334 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics type expected for a normal return. This permits programming languages to treat jump returns (such as exceptions) in two different, but essentially equivalent, ways: as multiple variant return types handled inline as ordinary values, or as a deviation from an expected default return type in which the receipt of any non-default types cause jumps within the calling scope. This approach permits a procedure to have multiple return types and have them treated either as variant returns or as exceptions, at the option of the caller. See Section 2.24.5, “Reply Handling. Note that jump handling does not add any fundamental power to the semantics. Each action could instead output status values that would be checked by conditionals, with the jump handlers being clauses of the conditionals executed if jump types were returned. Experience with programming languages has shown that such a program organization obscures its fundamental structure and makes changes difficult. Jump handling permits separation of concerns between normal control flow and unusual situations that require special handling. 2.25.2 Break and Continue Statements In many programming languages, a break statement terminates the execution of the current composite flow-of-control construct, such as a block, a case statement, or a conditional. Some languages have the ability to break out of several nested levels of control by supplying an argument to designate the level to break to. A continue statement terminates the execution of the body of a loop construct and advances to the next iteration. There are many variations in the way these statements work in different languages. The UML jump construct can represent these statements with flexibility. Each of these static flow-of-control constructs can be represented in UML as a JumpAction. The differences come in the type of jump object supplied and the place where the matching jump handler is placed. A simple break statement can be modeled as a JumpAction whose argument type is a special predefined class, such as BreakJump. This class has no attributes. A break handler for this type is placed on the immediately enclosing GroupAction. The break handler body is the null action. Execution of the JumpAction simply terminates execution of the current group of actions and resumes control beyond the group action. The same BreakJump type can be used throughout the entire model to represent all simple break statements. Each one will be caught by its immediately enclosing group action. The entire structure is statically determined. On a loop, the break handler would be placed on the LoopAction itself to terminate execution of the loop. If the enclosing GroupAction has data flow outputs, the handler must generate them. This is a situation that does not occur in traditional programming languages, but it is straightforward to model and does not present any difficulties in concept or implementation. In some situations, the modeler may choose to define a special jump type whose attributes include the output values of the group action or data needed to compute them. This is a powerful but straightforward extension of the traditional break statement involving parameters. To represent a break statement that jumps over several nested levels, use a special jump type caught only by the desired enclosing composite action. Actions in any embedded nesting level can potentially cause a jump of the given type. March 2003 OMG-Unified Modeling Language, v1.5 2-335 2 UML Semantics A simple continue statement can be modeled as a JumpAction whose argument type is a special predefined class, such as ContinueJump. This class has no arguments. A break handler for this type is placed on the (not necessarily immediately) enclosing GroupAction that represents the body of the loop. The break handler body is a null action. Execution of the JumpAction terminates execution of the current group of actions, and the jump propagates through any additional levels of nesting until it is caught by the appropriate level representing the loop body, whose execution is terminated. Control will then resume with the next iteration of the loop. The same ContinueJump type can be used throughout the entire model to represent all simple continue statements. If the enclosing loop body has data flow outputs, the handler must generate them. In particular, if the loop has dataflow loop variables, their values must be generated by the handler. Often the use of a continue statement represents a situation in which the loop variables take on default values. In complicated situations, it may be necessary to define a special jump type for the particular loop so that the information needed can be passed as part of the jump. This becomes a parameterized continue statement. 2.25.3 Exceptions In many programming languages, exceptions may occur during the execution of certain statements. In most languages, an exception can also be raised explicitly by a program statement. The occurrence of an exception terminates the current statement and causes control to jump to an enclosing statement that has an exception handler to catch the particular type of exception. The UML jump construct can represent traditional exception handling with flexibility. (Note that UML includes a metaclass called Exception. This metaclass represents interobject error conditions handled using state machines. The kind of exceptions found in traditional programming languages represent syntactic control constructs within a single thread of control, and are not related to or well modeled by the Exception metaclass. This section discusses the syntactic programming-language kind of exceptions, not the Exception metaclass.) The occurrence of an exception is modeled in UML as a jump object. The type of the jump object represents the kind of exception. The arguments of the jump object represent the parameters of the exception. Explicitly raising an exception is modeled using the JumpAction. In addition, primitive functions may be predefined to raise exceptions for particular arguments. For example, the divide function may be defined to cause a DivideByZero jump if the quotient is zero. The possibility of causing jumps is built into the definition of the function and represents part of its overall input-output mapping. Most users will not define their own primitive functions; usually those are predefined in a particularly computing environment, including their possible exceptions. However, any definition of a primitive function must specify the types of jumps that may occur, the input values for which they occur, and the mapping from input values to jump object attribute values. 2-336 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics An exception handler is modeled as a jump handler that catches the given jump type. Because the jump object may have attributes, the jump handler has access to relevant information about the circumstances that caused the exception and can use the information in dealing with the situation. 2.25.4 Jumps with Concurrent Executions If a jump propagates to a composite action, the execution of actions concurrent with the original action must be dealt with before the execution of the composite action can be abandoned, and their state at the time of the jump occurrence is indeterminate. The simplest approach is to wait for all concurrent executions to complete normally, under the assumption that they are unaffected by an error in a separate region. This approach is supported by the current semantics. Another possibility is that the concurrent executions are made irrelevant by an exception and should be terminated, but this decision must be made by the modeler in each specific situation. An interrupt is a condition that occurs asynchronously during the execution of an action or action sequence that may force a change in execution without waiting for normal completion. Dealing with the execution of concurrent actions because of the propagation of a jump to an enclosing scope is an interrupt situation. It might occur anywhere in the execution sequence of the concurrent action. In the simplest case, the execution of concurrent action could simply be allowed to complete, but in many situations an exception in a concurrent execution means that their results are worthless. Alternately, all concurrent executions could be abandoned, but there are many situations in which the affected concurrent action should be given a chance to clean itself up before terminating (or possibly even ignore the interrupt and complete normally). Past experience with operating systems has shown that there are various ways to deal with interrupts. It is anticipated that interrupt handling will be provided in a future update to UML. It is anticipated that the propagation of a jump to an action execution with concurrent executions would be a situation in which an interrupt would occur or could be made to occur. There is a likelihood that interrupt mechanisms will depend on the implementation and might therefore be defined in layers built on top of basic UML. If two jumps occur concurrently in different concurrent actions, it is indeterminate which jump (or possibly a third jump) will be raised at the level of the composite action. In any case, only one jump will be propagated upward and the others are lost. When a jump propagates upward, the execution of the composite action is complete and no activity or information (such as additional jump occurrences) remains. Without the use of interrupts, a jump may propagate upward only after concurrent executions complete. 2.25.5 Jump Classes The metamodel in Figure 2-61 shows the jump classes. March 2003 OMG-Unified Modeling Language, v1.5 2-337 2 UML Semantics Figure 2-61 Jump handling classes Note that jump handling extends the definitions of several other action classes to provide the ability to attach jump handlers or to define the behavior of the action when a jump occurs. 2.25.5.1 Action (in addition to the original definition in Action Foundation) InputPin (from Action Foundation) JumpAction 1 0..1+/jum pOc curence 1 0..1 Action (from Action Foundation) PrimitiveAction (from Action Foundation) OutputPin (from Action Foundation) Action (from Action Foundation) OutputPin (from Action Foundation) Classifier (from Core) HandlerAction 0..* 0..* + h an dl erOu tpu t 0..* {ordered} 0..* 1 0..1 +body1 0..1 1 0..1 +/occurrence1 0..1 JumpHandler 1 0..* +jumpType 1 0..* 1 0..* +body 1 +jumpHandler 0..* Action (from Action Foundation) 0..* 0..* +jumpHandler 0..* +protectedAction 0..* 2-338 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics Associations • jumpHandler: JumpHandler [0..*] Designates a set of JumpHandlers whose jump types apply to the action. If a jump of the given jump type or a descendant type occurs during the execution of the owning action, the HandlerAction attached to the JumpHandler is executed. If the jump type is not present on any jump handler attached to the action, the jump propagates to the enclosing action. 2.25.5.2 HandlerAction An action may have zero or more handlers attached to it. A handler deals with jumps that occur during the execution of its underlying action. A jump handler associates actions and jump types with the handler actions that replace the actions if a jump of the given type (or a descendant of the jump type) occurs. An action used as a handler is a kind of composite action. It must have one internal output pin; the output pin receives the jump occurrence object and makes it available within the handler action. A jump handler action must have a list of output pins that matches in number, order, and types the outputs of the action for which it handles jumps. If it does not have a matching list of output pins, it may still catch the jump, but it must re-raise the same or another jump rather than completing normally (otherwise the outputs of the original action would not be defined). The handler action has a body action (often a group action) that it executes. The occurrence pin is available to the body action as an available input. Associations • jumpHandler: JumpHandler [1..1] The handler catches any jump of the given jump type or a descendant type during an execution of its attached action. The handler action must own one internal output pin that receives the jump occurrence object. It must have a list of output pins that matches in number, order, and types those of the action it protects. • body: Action [1..1] The action that is triggered by the jump handler. The occurrence output pin of the handler action is available to the body action. All inputs available to the protected action are also available to the body action. No output pins of the body action are accessible outside the jump handler except the designated handlerOutput pins. Inputs none Outputs • occurrence: T [1..1], where T = self.jumpHandler.jumpType [An output pin owned by the HandlerAction itself and available to the body action but not outside the HandlerAction.] During the execution of the handler action, the value of the jump occurrence object is available on this pin. • handlerOutput: U [0..*], where U = self.jumpHandler.protectedAction..availableOutput.type, for all combinations of jumpHandler and protectedAction March 2003 OMG-Unified Modeling Language, v1.5 2-339 2 UML Semantics [A list of output pins owned by the body action but designated by the handler action. The number and types of the pins in the ordered list must match the number and types of the pins that are outputs of the action protected by the handler action.] At the completion of execution of the body action for a jump handler, the values on these pins are copied to the output pins of the protected action, and the successors of the protected action are enabled as if it had completed normally. Well-formedness rules 2.25.5.3 JumpAction An action whose execution causes the occurrence of a specified jump with specified arguments. The execution of this action has the remarkable property that it cannot complete normally. Although a jump handler could (somewhat perversely) be attached to the jump action itself, usually the purpose of a jump action is to terminate a group of actions containing the raise action and escape to a jump handler at some enclosing level. The use of this action is the normal way to represent break and continue statements from programming languages. Inputs • jumpOccurrence: T [1..1], where T is any user class The jump occurrence object caused by the action. When the action is executed, a jump occurs and the object becomes its the jump occurrence object. The execution of the jump action is terminated (!) and the normal process of jump handling occurs using the given jump object. Outputs none 2.25.5.4 JumpHandler (not an action) Essentially the reification of a qualified association relating an Action and a jump type to the HandlerAction that is invoked if the jump occurs during the execution of the action. Associations • body: HandlerAction [1..1] The action executed if an occurrence of the given jump type occurs during an execution of the attached action. [1] An action used as a jump handler must have output pins that match the output pins of the protected action. self.body.outputPin.type = self.jumpHandler.protectedAction.outputPin.type [2] The occurrence input pin must have a type matching the corresponding jump type. self.occurrence.type = self.jumpHandler.jumpType 2-340 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics • jumpType: Classifier [1..1] The type of jump caught by the jump handler. • protectedAction [0..*] The action whose executions are protected by the jump handler. The same handler can protect multiple actions. Well-formedness rules none 2.25.6 Additional Jump Semantics for Actions Defined Elsewhere 2.25.6.1 ConditionalAction Semantics (Additional semantics for jump handling) If a jump fails to be handled by an executing body action, reaches the propagating status, the jump propagates to the conditional execution action itself. The execution of the conditional is terminated. Normal jump handling occurs. If jump fails to be handled by the execution of a test action of a clause and no other clauses are executing, the jump propagates to the conditional execution itself. The execution of the conditional is terminated. Normal jump handling occurs. Note that if some clause returns true, execution of its body proceeds in spite of a jump in the test action from another clause. 2.25.6.2 FilterAction Semantics (Additional semantics for jump handling) If a jump is propagated from a subordinate subaction, the jump is considered raised in the filter execution. If there are other active subordinate subactions, they must complete before jump handling can continue. When there are no active subordinate subactions, the filter execution is terminated and the jump is raised on it. If more than one subordinate action propagates a jump, it is indeterminate which jump will be propagated to the filter execution. 2.25.6.3 GroupAction Semantics (Additional semantics for jump handling) March 2003 OMG-Unified Modeling Language, v1.5 2-341 2 UML Semantics If a jump fails to be handled by one of the concurrently executing subactions of the group, the jump is considered raised in the group action execution. Any concurrently executing actions in the group must complete before the jump propagates to the enclosing action. If more than one jump is propagated concurrently to the group action execution, one of them will be propagated when all of the other concurrent executions are inactive, but it is indeterminate which one. When interrupts are added to UML, it is expected that the occurrence of an unhandled jump within a group action would be a situation that would generate an interrupt. 2.25.6.4 IterateAction Semantics (Additional semantics for jump handling) If a jump is propagated from the subordinate execution, the iterate execution is terminated and the jump handler of the iterate action handles the jump. 2.25.6.5 LoopAction Semantics (Additional semantics for jump handling) If a jump fails to be handled by either the test action or the body action of a loop, the jump propagates to the loop action itself. The execution of the loop is terminated. Normal jump handling occurs. 2.25.6.6 MapAction Semantics (Additional semantics for jump handling) If a jump is propagated from a subordinate subaction, the jump is considered raised in the map execution. If there are other active subordinate subactions, they must complete before the jump propagates to the map execution itself. When there are no active subordinate subactions, the map execution is terminated and the normal jump handling occurs at the map execution action. If more than one subordinate action propagates a jump, it is indeterminate which jump will be propagated to the map execution. 2.25.6.7 Procedure Semantics (Additional semantics for jump handling) 2-342 OMG-Unified Modeling Language, v1.5 March 2003 2 UML Semantics If a jump is propagated from the subordinate action, execution of the procedure is terminated. The jump object is treated as the reply and it is passed to the caller in lieu of the normal reply object. The procedure execution is considered complete. If the invocation was asynchronous, the reply is ignored and no further propagation occurs. The jump is returned to the caller as the reply object. This permits the caller to handle a jump inline, if desired. If the call result is strongly typed and the jump type does not match the return type, the jump is re-raised in the calling procedure. Therefore no special mechanism is needed to propagate jumps to callers. 2.25.6.8 ReduceAction Semantics (Additional semantics for jump handling) If a jump is propagated from a subordinate execution, execution of the reduce action is terminated and the jump is raised on the reduce action itself. 2.25.7 Jump Value Classes These classes may be used as jump types to provide certain traditional control flow capabilities. 2.25.7.1 BreakJump As the type of a jump, represents a traditional break statement. It has no attributes. Attributes none Associations none 2.25.7.2 ContinueJump As the type of a jump, represents a traditional continue statement. It has no attributes. Attributes none Associations none March 2003 OMG-Unified Modeling Language, v1.5 3-1 UML Notation Guide 3 This guide describes the notation for the visual representation of the Unified Modeling Language (UML). This notation document contains brief summaries of the semantics of UML constructs, but the UML Semantics chapter must be consulted for full details. Contents This chapter contains the following topics. Topic Page “Part 1 - Background” “Introduction” 3-5 Part 2 - Diagram Elements “Graphs and Their Contents” 3-6 “Drawing Paths” 3-7 “Invisible Hyperlinks and the Role of Tools” 3-7 “Background Information” 3-8 “String” 3-8 “Name” 3-9 “Label” 3-10 “Keywords” 3-11 “Expression” 3-11 “Type-Instance Correspondence” 3-14 Part 3 - Model Management 3-2 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide “Package” 3-16 “Subsystem” 3-19 “Model” 3-24 Part 4 - General Extension Mechanisms “Constraint and Comment” 3-26 “Element Properties” 3-29 “Stereotypes” 3-31 Part 5 - Static Structure Diagrams “Class Diagram” 3-34 “Object Diagram” 3-35 “Classifier” 3-35 “Class” 3-35 “Name Compartment” 3-38 “List Compartment” 3-38 “Attribute” 3-41 “Operation” 3-44 “Nested Class Declarations” 3-48 “Type and Implementation Class” 3-49 “Interfaces” 3-50 “Parameterized Class (Template)” 3-52 “Bound Element” 3-54 “Utility” 3-56 “Metaclass” 3-57 “Enumeration” 3-57 “Stereotype Declaration” 3-57 “Powertype” 3-61 “Class Pathnames” 3-61 “Accessing or Importing a Package” 3-62 “Object” 3-64 “Composite Object” 3-67 “Association” 3-68 “Binary Association” 3-68 Topic Page March 2003 OMG-Unified Modeling Language, v1.5 3-3 3 UML Notation Guide “Association End” 3-71 “Multiplicity” 3-75 “Qualifier” 3-76 “Association Class” 3-77 “N-ary Association” 3-79 “Composition” 3-81 “Link” 3-84 “Generalization” 3-86 “Dependency” 3-90 “Derived Element” 3-93 “InstanceOf” 3-93 Part 6 - Use Case Diagrams “Use Case Diagram” 3-94 “Use Case” 3-96 “Actor” 3-97 “Use Case Relationships” 3-97 “Actor Relationships” 3-99 Part 7 - Interaction Diagrams “Collaboration” 3-101 “Sequence Diagram” 3-102 “Object Lifeline” 3-108 “Activation” 3-110 “Message and Stimulus” 3-111 “Transition Times” 3-113 Part 8 - Collaboration Diagrams “Collaboration Diagram” 3-114 “Pattern Structure” 3-117 “Collaboration Contents” 3-121 “Interactions” 3-123 “Collaboration Roles” 3-124 “Multiobject” 3-127 “Active object” 3-128 Topic Page 3-4 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide “Message and Stimulus” 3-111 “Creation/Destruction Markers” 3-134 Part 9 - Statechart Diagrams “Statechart Diagram” 3-136 “State” 3-137 “Composite States” 3-140 “Events” 3-142 “Simple Transitions” 3-145 “Transitions to and from Concurrent States” 3-146 “Transitions to and from Composite States” 3-147 “Factored Transition Paths” 3-150 “Submachine States” 3-152 “Synch States” 3-154 Part 10 - Activity Diagrams “Activity Diagram” 3-155 “Action state” 3-158 “Subactivity state” 3-159 “Decisions” 3-159 “Call States” 3-161 “Swimlanes” 3-161 “Action-Object Flow Relationships” 3-163 “Control Icons” 3-165 “Synch States” 3-154 “Dynamic Invocation” 3-168 “Conditional Forks” 3-169 Part 11 - Implementation Diagrams “Component Diagram” 3-169 “Deployment Diagram” 3-171 “Node” 3-173 “Component” 3-174 Topic Page March 2003 OMG-Unified Modeling Language, v1.5 3-5 3 UML Notation Guide Part 1 - Background 3.1 Introduction This chapter is arranged in parts according to semantic concepts subdivided by diagram types. Within each diagram type, model elements that are found on that diagram and their representation are listed. Note that many model elements are usable in more than one diagram. An attempt has been made to place each description where it is used the most, but be aware that the document involves implicit cross-references and that elements may be useful in places other than the section in which they are described. Be aware also that the document is nonlinear: there are forward references in it. It is not intended to be a teaching document that can be read linearly, but a reference document organized by affinity of concept. Each part of this chapter is divided into sections, roughly corresponding to important model elements and notational constructs. Note that some of these constructs are used within other constructs; do not be misled by the flattened structure of the chapter. Within each section the following subsections may be found: • Semantics: Brief summary of semantics. For a fuller explanation and discussion of fine points, see the UML Semantics chapter in this specification. • Notation: Explains the notational representation of the semantic concept (“forward mapping to notation”). • Presentation options: Describes various options in presenting the model information, such as the ability to suppress or filter information, alternate ways of showing things, and suggestions for alternate ways of presenting information within a tool. Dynamic tools need the freedom to present information in various ways and the authors do not want to restrict this excessively. In some sense, we are defining the “canonical notation” that printed documents show, rather than the “screen notation.” The ability to extend the notation can lead to unintelligible dialects, so we hope this freedom will be used in intuitive ways. The authors have not sought to eliminate all the ambiguity that some of these presentation options may introduce, because the presence of the underlying model in a dynamic tool serves to easily disambiguate things. Note that a tool is not supposed to pick just one of the presentation options and implement it. Tools should offer users the options of selecting among various presentation options, including some that are not described in this document. • Style guidelines: Include suggestions for the use of stylistic markers, such as fonts, naming conventions, arrangement of symbols that are not explicitly part of the notation, but that help to make diagrams more readable. These are similar to text indentation rules in C++ or Smalltalk. Not everyone will choose to follow these suggestions, but the use of some consistent guidelines of your own choosing is recommended in any case. • Example: Shows samples of the notation. String and code examples are given in the following font: This is a string sample. 3-6 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide • Mapping: Shows the mapping of notation elements to metamodel elements (“reverse mapping from notation”). This indicates how the notation would be represented as semantic information. Note that, in general, diagrams are interpreted in a particular context in which semantic and graphic information is gathered simultaneously. The assumption is that diagrams are constructed by an editing tool that internalizes the model as the diagram is constructed. Some semantic constructs have no graphic notation and would be shown to a user within a tool using a form or table. Part 2 - Diagram Elements 3.2 Graphs and Their Contents Most UML diagrams and some complex symbols are graphs containing nodes connected by paths. The information is mostly in the topology, not in the size or placement of the symbols (there are some exceptions, such as a sequence diagram with a metric time axis). There are three kinds of visual relationships that are important: 1. connection (usually of lines to 2-d shapes), 2. containment (of symbols by 2-d shapes with boundaries), and 3. visual attachment (one symbol being “near” another one on a diagram). These visual relationships map into connections of nodes in a graph, the parsed form of the notation. UML notation is intended to be drawn on 2-dimensional surfaces. Some shapes are 2- dimensional projections of 3-d shapes (such as cubes), but they are still rendered as icons on a 2-dimensional surface. In the near future, true 3-dimensional layout and navigation may be possible on desktop machines; however, it is not currently practical. There are basically four kinds of graphical constructs that are used in UML notation: 1. Icons - An icon is a graphical figure of a fixed size and shape. It does not expand to hold contents. Icons may appear within area symbols, as terminators on paths or as standalone symbols that may or may not be connected to paths. 2. 2-d Symbols - Two-dimensional symbols have variable height and width and they can expand to hold other things, such as lists of strings or other symbols. Many of them are divided into compartments of similar or different kinds. Paths are connected to two-dimensional symbols by terminating the path on the boundary of the symbol. Dragging or deleting a 2-d symbol affects its contents and any paths connected to it. 3. Paths - Sequences of line segments whose endpoints are attached. Conceptually a path is a single topological entity, although its segments may be manipulated graphically. A segment may not exist apart from its path. Paths are always attached to other graphic symbols at both ends (no dangling lines). Paths may have terminators; that is, icons that appear in some sequence on the end of the path and that qualify the meaning of the path symbol. March 2003 OMG-Unified Modeling Language, v1.5 3-7 3 UML Notation Guide 4. Strings - Present various kinds of information in an “unparsed” form. UML assumes that each usage of a string in the notation has a syntax by which it can be parsed into underlying model information. For example, syntaxes are given for attributes, operations, and transitions. These syntaxes are subject to extension by tools as a presentation option. Strings may exist as singular elements of symbols or compartments of symbols, as elements in lists (in which case the position in the list conveys information), as labels attached to symbols or paths, or as stand-alone elements on a diagram. 3.3 Drawing Paths A path consists of a series of line segments whose endpoints coincide. The entire path is a single topological unit. Line segments may be orthogonal lines, oblique lines, or curved lines. Certain common styles of drawing lines exist: all orthogonal lines, or all straight lines, or curves only for bevels. The line style can be regarded as a tool restriction on default line input. When line segments cross, it may be difficult to know which visual piece goes with which other piece; therefore, a crossing may optionally be shown with a small semicircular jog by one of the segments to indicate that the paths do not intersect or connect (as in an electrical circuit diagram). In some relationships (such as aggregation and generalization) several paths of the same kind may connect to a single symbol. In some circumstances (described for the particular relationship) the line segments connected to the symbol can be combined into a single line segment, so that the path from that symbol branches into several paths in a kind of tree. This is purely a graphical presentation option; conceptually the individual paths are distinct. This presentation option may not be used when the modeling information on the segments to be combined is not identical. 3.4 Invisible Hyperlinks and the Role of Tools A notation on a piece of paper contains no hidden information. A notation on a computer screen may contain additional invisible hyperlinks that are not apparent in a static view, but that can be invoked dynamically to access some other piece of information, either in a graphical view or in a textual table. Such dynamic links are as much a part of a dynamic notation as the visible information, but this guide does not prescribe their form. We regard them as a tool responsibility. This document attempts to define a static notation for the UML, with the understanding that some useful and interesting information may show up poorly or not at all in such a view. On the other hand, we do not know enough to specify the behavior of all dynamic tools, nor do we want to stifle innovation in new forms of dynamic presentation. Eventually some of the dynamic notations may become well enough established to standardize them, but we do not feel that we should do so now. 3-8 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.5 Background Information 3.5.1 Presentation Options Each appearance of a symbol for a class on a diagram or on different diagrams may have its own presentation choices. For example, one symbol for a class may show the attributes and operations and another symbol for the same class may suppress them. Tools may provide style sheets attached either to individual symbols or to entire diagrams. The style sheets would specify the presentation choices. (Style sheets would be applicable to most kinds of symbols, not just classes.) Not all modeling information is presented most usefully in a graphical notation. Some information is best presented in a textual or tabular format. For example, much detailed programming information is best presented as text lists. The UML does not assume that all of the information in a model will be expressed as diagrams; some of it may only be available as tables. This document does not attempt to prescribe the format of such tables or of the forms that are used to access them, because the underlying information is adequately described in the UML metamodel and the responsibility for presenting tabular information is a tool responsibility. It is assumed that hidden links may exist from graphical items to tabular items. 3.6 String A string is a sequence of characters in some suitable character set used to display information about the model. Character sets may include non-Roman alphabets and characters. 3.6.1 Semantics Diagram strings normally map underlying model strings that store or encode information about the model, although some strings may exist purely on the diagrams. UML assumes that the underlying character set is sufficient for representing multibyte characters in various human languages; in particular, the traditional 8-bit ASCII character set is insufficient. It is assumed that the tool and the computer manipulate and store strings correctly, including escape conventions for special characters, and this document will assume that arbitrary strings can be used without further fuss. 3.6.2 Notation A string is displayed as a text string graphic. Normal printable characters should be displayed directly. The display of nonprintable characters is unspecified and platform- dependent. Depending on purpose, a string might be shown as a single-line entity or as a paragraph with automatic line breaks. Typeface and font size are graphic markers that are normally independent of the string itself. They may code for various model properties, some of which are suggested in this document and some of which are left open for the tool or the user. March 2003 OMG-Unified Modeling Language, v1.5 3-9 3 UML Notation Guide 3.6.3 Presentation Options Tools may present long strings in various ways, such as truncation to a fixed size, automatic wrapping, or insertion of scroll bars. It is assumed that there is a way to obtain the full string dynamically. 3.6.4 Examples BankAccount integrate (f: Function, from: Real, to: Real) { author = “Joe Smith”, deadline = 31-March-1997, status = analysis } The purpose of the shuffle operation is nominally to put the cards into a random configuration. However, to more closely capture the behavior of physical decks, in which blocks of cards may stick together during several riffles, the operation is actually simulated by cutting the deck and merging the cards with an imperfect merge. 3.6.5 Mapping A graphic string maps into a string within a model element. The mapping depends on context. In some circumstances, the visual string is parsed into multiple model elements. For example, an operation signature is parsed into its various fields. Further details are given with each kind of symbol. 3.7 Name 3.7.1 Semantics A name is a string that is used to identify a model element uniquely within some scope. A pathname is used to find a model element starting from the root of the system (or from some other point). A name is a selector (qualifier) within some scope—the scope is made clear in this document for each element that can be named. A pathname is a series of names linked together by a delimiter (such as ‘::’). There are various kinds of pathnames described in this document, each in its proper place and with its particular delimiter. 3.7.2 Notation A name is displayed as a text string graphic. Normally a name is displayed on a single line and will not contain nonprintable characters. Tools and languages may impose reasonable limits on the length of strings and the character set they use for names, possibly more restrictive than those for arbitrary strings, such as comments. 3-10 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.7.3 Example Names: BankAccount integrate controller abstract this_is_a_very_long_name_with_underscores Pathname: MathPak::Matrices::BandedMatrix 3.7.4 Mapping Maps to the name of a model element. The mapping depends on context, as with String. Further details are given with the particular element. 3.8 Label A label is a string that is attached to a graphic symbol. 3.8.1 Semantics A label is a term for a particular use of a string on a diagram. It is purely a notational term. 3.8.2 Notation A label is a string that is attached graphically to another symbol on a diagram. Visually the attachment normally is by containment of the string (in a closed region) or by placing the string near the symbol. Sometimes the string is placed in a definite position (such as below a symbol) but most of the time the statement is that the string must be “near” the symbol. A tool maintains an explicit internal graphic linking between a label and a graphic symbol, so that the label drags with the symbol, but the final appearance of the diagram is a matter of aesthetic judgment and should be made so that there is no confusion about which symbol a label is attached to. Although the attachment may not be obvious from a visual inspection of a diagram, the attachment is clear and unambiguous at the graphic level (and poses no ambiguity in the semantic mapping). March 2003 OMG-Unified Modeling Language, v1.5 3-11 3 UML Notation Guide 3.8.3 Presentation Options A tool may visually show the attachment of a label to another symbol using various aids (such as a line in a given color, flashing of matched elements, etc.) as a convenience. 3.8.4 Example Figure 3-1 Attachment by Containment and Attachment by Adjacency 3.9 Keywords The number of easily-distinguishable visual symbols is limited. The UML notation makes use of text keywords in places to distinguish variations on a common theme, including metamodel subclasses of a base class, stereotypes of a metamodel base class, and groups of list elements. From the user’s perspective, the metamodel distinction between metamodel subclasses and stereotypes is often unimportant, although it is important to tool builders and others who implement the metamodel. The general notation for the use of a keyword is to enclose it in guillemets («»): «keyword» Certain predefined keywords are described in the text of this document. These must be treated as reserved words in the notation. Others are available for users to employ as stereotype names. The use of a stereotype name that matches a predefined keyword is ill formed. 3.10 Expression 3.10.1 Semantics Various UML constructs require expressions, which are linguistic formulas or procedures that yield values when evaluated at run-time. These include expressions for types, boolean values, and numbers. UML does not include an explicit linguistic analyzer for expressions. Rather, expressions are expressed as strings in a particular BankAccount account 3-12 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide language or using procedures, or both. The OCL constraint language is used within the UML semantic definition and may also be used at the user level; other languages (such as programming languages) may also be used. UML avoids specifying the syntax for constructing type expressions because they are so language-dependent. It is assumed that the name of a class or simple data type will map into a simple Classifier reference, but the syntax of complicated language- dependent type expressions, such as C++ function pointers, is the responsibility of the specification language. 3.10.2 Notation An expression is displayed as a string defined in a particular language. The syntax of the string is the responsibility of a tool and a linguistic analyzer for the language. The assumption is that the analyzer can evaluate strings at run-time to yield values of the appropriate type, or can yield a procedure to capture the meaning of the expression. For example, a type expression evaluates to a Classifier reference, and a boolean expression evaluates to a true or false value. The language itself is known to a modeling tool but is generally implicit on the diagram, under the assumption that the form of the expression makes its purpose clear. 3.10.3 Examples BankAccount BankAccount * (*) (Person*, int) array [1..20] of reference to range (-1.0..1.0) of Real [ i > j and self.size > i ] 3.10.4 Mapping An expression string maps to an Expression element (possibly a particular subclass of Expression, such as BooleanExpression or TimeExpression). If an analyzer yields a procedure for calculating the value of the expression, then the body association from Expression to Procedure is used to record this. 3.10.5 OCL Expressions UML includes a definition of the OCL language, which is used to define constraints within the UML metamodel itself. The OCL language may be supported by tools for user-written expressions as well. Other possible languages include various computer languages as well as plain text (which cannot be parsed by a tool, of course, and is therefore only for human information). The OCL language is defined in the “Object Constraint Language Specification” chapter. March 2003 OMG-Unified Modeling Language, v1.5 3-13 3 UML Notation Guide 3.10.6 Selected OCL Notation Syntax for some common navigational expressions are shown below. These forms can be chained together. The leftmost element must be an expression for an object or a set of objects. The expressions are meant to work on sets of values when applicable. 3.10.7 Examples flight.pilot.training_hours > flight.plane.minimum_hours company.employees−>select (title = “Manager” and self.reports−>size > 10) 3.11 Note A note is a graphical symbol containing textual information (possibly including embedded images). It is a notation for rendering various kinds of textual information from the metamodel, such as constraints, comments, method bodies, and tagged values. 3.11.1 Semantics A note is a notational item. It shows textual information within some semantic element. 3.11.2 Notation A note is shown as a rectangle with a “bent corner” in the upper right corner. It contains arbitrary text. It appears on a particular diagram and may be attached to zero or more modeling elements by dashed lines. 3.11.3 Presentation Options A note may have a stereotype. item ‘.’ selector The selector is the name of an attribute in the item or the name of the target end of a link attached to the item. The result is the value of the attribute or the related object(s). The result is a value or a set of values depending on the multiplicities of the item and the association. item ‘.’ selector ‘[‘ qualifier-value ‘]’ The selector designates a qualified association that qualifies the item. The qualifier-value is a value for the qualifier attribute. The result is the related object selected by the qualifier. Note that this syntax is applicable to array indexing as a form of qualification. set ‘->’ ‘select’ ‘(‘ boolean-expression ‘)’ The boolean-expression is written in terms of objects within the set. The result is the subset of objects in the set for which the boolean expression is true. 3-14 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide A note with the keyword “constraint” or a more specific stereotype of constraint (such as the code body for a method) designates a constraint that is part of the model and not just part of a diagram view. Such a note is the view of a model element (the constraint). 3.11.4 Example See also Figure 3-17 on page 3-28 for a note symbol containing a constraint. Figure 3-2 Note 3.11.5 Mapping A note may represent the textual information in several possible metamodel constructs; it must be created in context that is known to a tool, and the tool must maintain the mapping. The string in the note maps to the body of the corresponding modeling element. A note may represent: • a constraint, • a tagged value, • the body of a procedure of a method, or • other string values within modeling elements. It may also represent a comment attached directly to a diagram element. 3.12 Type-Instance Correspondence A major purpose of modeling is to prepare generic descriptions that describe many specific items. This is often known as the type-instance dichotomy. Many or most of the modeling concepts in UML have this dual character, usually modeled by two paired modeling elements, one represents the generic descriptor and the other the individual items that it describes. Examples of such pairs in UML include: Class-Object, Association-Link, UseCase-UseCaseInstance, Message-Stimulus, and so on. Although diagrams for type-like elements and instance-like elements are not exactly the same, they share many similarities. Therefore, it is convenient to choose notation for each type-instance pair of elements such that the correspondence is visually apparent immediately. There are a limited number of ways to do this, each with advantages and disadvantages. In UML, the type-instance distinction is shown by employing the same geometrical symbol for each pair of elements and by underlining This model was built by Alan Wright after meeting with the mission planning team. March 2003 OMG-Unified Modeling Language, v1.5 3-15 3 UML Notation Guide the name string (including type name, if present) of an instance element. This visual distinction is generally easily apparent without being overpowering even when an entire diagram contains instance elements. Figure 3-3 Classes and Objects A tool is free to substitute a different graphic marker for instance elements at the user’s option, such as color, fill patterns, or so on. Roles (in collaborations) are somewhat between types and instances. Like instances, they identify distinct occurrences of a single classifier. Like types, they describe a reusable element that can have many distinct instances. A role is a distinguishable use of a classifier, but one that is still part of a general description (a collaboration) that can be used to create many instances. A run-time object may correspond to zero or more classes and to zero or more roles. The notation for a role permits indication of its base classifiers. The notation for an instance permits specification of its classifiers, its roles, or both. A role is indicated by a name, colon, and type, not underlined and part of a collaboration. An instance is indicated by an optional name, optional slash followed by list of roles, colon, and list of types. Point x: Real y: Real rotate (angle: Real) scale (factor: Real) p1: Point x = 3.14 y = 2.718 :Point x = 1 y = 1.414 3-16 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide Figure 3-4 Roles and objects Part 3 - Model Management 3.13 Package 3.13.1 Semantics A package is a grouping of model elements. Packages themselves may be nested within other packages. A package may contain subordinate packages as well as other kinds of model elements. All kinds of UML model elements can be organized into packages. Note that packages own model elements and are the basis for configuration control, storage, and access control. Each element can be directly owned by a single package, so the package hierarchy is a strict tree. However, packages can reference other packages, modeled by using one of the stereotypes «import» and «access» of Permission dependency, so the usage network is a graph. Other kinds of dependencies between packages usually imply that one or more dependencies among the elements exists. 3.13.2 Notation A package is shown as a large rectangle with a small rectangle (a “tab”) attached to the left side of the top of the large rectangle. It is the common folder icon. p1/lead: Point x = 3.14 y = 2.718 p2/lead,tail:Point x = 1 y = 1.414 lead: Point tail: Point roles objects March 2003 OMG-Unified Modeling Language, v1.5 3-17 3 UML Notation Guide The contents of the package may be shown within the large rectangle. Contents may also be shown by branching lines to contained elements, drawn outside of the package (see Figure 3-5 on page 3-18). A plus sign (+) within a circle is drawn at the end attached to the container. • If the contents of the package are not shown within the large rectangle, then the name of the package may be placed within the large rectangle. • If the contents of the package are shown within the large rectangle, then the name of the package may be placed within the tab. A keyword string may be placed above the package name. The predefined stereotypes facade, framework, stub, and topLevel are notated within guillemets. A list of properties may be placed in braces after or below the package name. Example: {abstract}. See Section 3.17, “Element Properties,” on page3-29 for details of property syntax. The visibility of a package element outside the package may be indicated by preceding the name of the element by a visibility symbol (‘+’ for public, ‘-’ for private, ‘#’ for protected, ‘~’ for package). Relationships may be drawn between package symbols to show relationships between some of the elements in the packages. An import or access relationship between two packages is drawn as a dashed arrow with open arrowhead, labeled with the string «import» or «access», respectively. Elements from imported or accessed packages may be shown outside the package symbol. As (public) elements in imported packages are added to the client namespace, they may alternatively be drawn inside the package symbol. 3.13.3 Presentation Options A tool may show visibility by a graphic marker, such as color or font. A tool may also show visibility by selectively displaying those elements that meet a given visibility level; for example, all of the public elements only. A diagram showing a package with contents must not necessarily show all its contents; it may show a subset of the contained elements according to some criterion. The contents of a package may also be shown using tree notation. The namespace ownership relationships between the package and its elements are marked with a circle with a cross in it at the owning end. 3.13.4 Style Guidelines It is expected that packages with large contents will be shown as simple icons with names, in which the contents may be dynamically accessed by “zooming” to a detailed view. 3-18 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.13.5 Example Figure 3-5 Packages and their access and import relationships. Figure 3-6 Some of the contents of the Editor package shown in a tree structure. Controller Diagram Elements Windowing System Domain Elements Graphics Core Microsoft Windows Motif WindowsCore MotifCore Editor «import» «import» «import» «import» «import» «import» «access» «access» Editor Controller Diagram Elements Domain Elements March 2003 OMG-Unified Modeling Language, v1.5 3-19 3 UML Notation Guide 3.13.6 Mapping A package symbol maps into a Package element. The name on the package symbol is the name of the Package element. If there is a string above the package name other than «model» or «subsystem», then it maps into a Package element with the corresponding stereotype. If there is a string «model» or «subsystem», then it maps into a Model or Subsystem element, respectively. A relationship icon drawn from the package symbol boundary to another package symbol maps into a corresponding relationship to the other package element. A symbol directly contained within the package symbol; that is, not contained within another symbol maps into a model element either owned or referenced by the package element. The alias used for a referenced element is often its pathname, in which case it is directly visible from the diagram that the element is not owned by the package. Only the reference is owned by the current package. Alternatively, a symbol shown outside the package symbol, attached to one of the symbols within the package symbol, denotes a referenced model element. Symbols connected to the package symbol by branching lines with a plus sign at the end attached to the package symbol, map to elements in the package. 3.14 Subsystem 3.14.1 Semantics Whereas a package is a generic mechanism for organizing model elements, a subsystem represents a behavioral unit in the physical system, and hence in the model. A subsystem offers interfaces and has operations, and its contents are partitioned into specification and realization elements. The specification of the subsystem consists of operations on the subsystem, together with specification elements such as use cases, state machines. Apart from defining a namespace, a subsystem serves as a specification unit for the behavior of its contained model elements. A subsystem may or may not be instantiable. 3.14.2 Notation A subsystem is notated basically in the same way as a package, with the addition of a fork symbol placed in the upper right corner of the large rectangle. The name of the subsystem (together with optional keyword, stereotype) is placed within the large rectangle. Optionally, especially if contents of the subsystem are shown within the large rectangle, the subsystem name and the fork are placed within the tab (the small rectangle). An instantiable subsystem has the string «instantiable» above its name. The large rectangle has three compartments, one for operations and one for each of the subsets specification elements and realization elements. These are usually shown by dividing the rectangle by a vertical line, and then dividing the area to the left of this 3-20 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide line into two compartments by a horizontal line. The operations are shown in the upper left compartment, the specification elements in the compartment below, and the realization elements in the right compartment. The latter two compartments are labeled ‘Specification Elements’ and ‘Realization Elements,’ respectively, to avoid potential ambiguity. The operations compartment is unlabeled. This is the general pattern for subsystem notation, although there are many different ways to customize it in a particular diagram, see Section 3.14.3, “Presentation Options,” on page 3-20 and Section 3.14.4, “Example,” on page 3-21. Figure 3-7 The general pattern for subsystem notation, with three compartments. The mapping from the realization part to the specification part; that is, to operations and specification elements, is drawn using dashed arrows with closed, hollow arrowheads. For collaborations, the mapping may also be expressed textually. When a subsystem is shown together with other, peer elements in a diagram, it is often shown without contents, in which case there are no compartments in the large rectangle. See Section 3.14.4, “Example,” on page 3-21. 3.14.3 Presentation Options The fork symbol may be replaced by the keyword «subsystem» placed above the name of the subsystem. The compartments may be rearranged within the subsystem symbol. One or more of the compartments may be collapsed or suppressed. In cases where more than one diagram is used to show all information about a particular subsystem, each diagram shows a subset of the subsystem’s features and/or contents. Hence, compartments not relevant in a particular diagram are suppressed. All contained elements in a subsystem may be shown together in one, non-labeled compartment; that is, no visual differentiating between specification elements and realization elements is done. Specification Elements Realization Elements March 2003 OMG-Unified Modeling Language, v1.5 3-21 3 UML Notation Guide Tools may provide alternative ways to differentiate specification elements from realization elements, such as different colors, using the keyword «specification» for specification elements, etc. As with packages, the contents of a subsystem may be shown using tree notation. Distinction between specification and realization elements may then be done; for example, by having two separate, labeled branches, or by showing the category separately for each element in the tree as suggested above. 3.14.4 Example Figure 3-8 An overview diagram showing subsystems with interfaces and their dependencies. Figure 3-9 All contained elements of a subsystem shown together without division into compartments. Here, the subsystem offers operation1(...) although this is not explicitly shown. In Figure 3-9 no visual separation between specification and realization elements is made. The following three figures are schematic examples where the specification/realization distinction is explicit. Together these figures constitute an example of how the basic notation for subsystem can be used to show different “views” of a subsystem in different diagrams, together giving the whole picture of the subsystem. SS1 SS2 SS3 operation1(...) : Type1 «Interface» 3-22 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide Figure 3-10 The specification part of a subsystem; compartment for realization part is suppressed. Implicit from the diagram is that the operation4(...) is either an operation of a specification element (UseCase1 or UseCase2) or of the subsystem itself. Furthermore, in cases where no operations are used for the specification but only contained specification elements, there is no operations compartment, and vice versa. Figure 3-11 The realization part of a subsystem; compartments for specification part; that is, operations and specification elements are suppressed. Alternatively, collaborations could be shown in a separate diagram. operation2(...) : Type2 operation3(...) : Type3 UseCase1 UseCase2 Specification Elements operation1(...) : Type1 «Interface» operation4(...) : Type4 «Interface» operation1(...) : Type1 Realization Elements March 2003 OMG-Unified Modeling Language, v1.5 3-23 3 UML Notation Guide Figure 3-12 The mapping between specification part and realization part shown using all three compartments, but only those realization elements with relevance to the mapping are shown. The figure also shows examples of different ways to express the mapping. Figure 3-13 A component modeled using a subsystem and classes stereotyped «focalClass» or «auxiliaryClass», respectively. Realization Elements operation1(...) : Type1 operation2(...) : Type2 representedOperation: operation2 Specification Elements operation3(...) : Type3 operation4(...) : Type4 «Interface» UseCase1 UseCase2 Realization ElementsSpecification Elements create(...) «Interface» ShoppingCartHome findByPrimaryKey(...) ... getItemCount(...) «Interface» ShoppingCart setItemCount(...) ...getTotal(...) setTotal(...) ... «focalClass» ShoppingCartImpl «auxiliaryClass» ContextObject «auxiliaryClass» RemoteObject «auxiliaryClass» HomeObject Context ShoppingCartHome Shoppingcart«call» «call» «call» ShoppingCart «auxiliaryClass» ShoppingCart ArtStoreClient «call» «call» DBbroker 3-24 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.14.5 Mapping A subsystem symbol maps into a Subsystem with the given name. The mapping is analogous to that of package symbols, with the following addition: A symbol within a compartment of the large rectangle labeled ‘Specification Elements’ or ‘Realization Elements’ is mapped to a specification or realization element of the subsystem, respectively. An operation signature string within a non-labeled compartment maps to an operation of the subsystem. Note that a compartment may coincide with the whole rectangle. A symbol, that is not an operation signature string, within a non-labeled compartment maps to an element contained in the subsystem. A dashed arrow with closed, hollow arrowhead from a symbol denoting a realization element to a symbol denoting a specification element or an operation maps to a «realize» relationship between the corresponding elements. 3.15 Model 3.15.1 Semantics A model captures a view of a physical system. Hence, it is an abstraction of the physical system with a certain purpose; for example, to describe behavioral aspects of the physical system to a certain category of stakeholders. A model contains all the model elements needed to represent a physical system completely according to the purpose of this particular model. The model elements in a model are organized into a package/subsystem hierarchy, where the top-most package/subsystem represents the boundary of the physical system. Different models of the same physical system show different aspects of the system. The pre-defined stereotype «systemModel» can be applied to a model containing the entire set of models for a physical system. Relationships between elements in different models have no semantic impact on the contents of the models because of the self-containment of models. However, they are useful for tracing refinements and for keeping track of requirements between models. Relationships between models express refinement, import, etc. 3.15.2 Notation A model is notated using the ordinary package symbol with a small triangle in the upper right corner of the large rectangle. Optionally, especially if contents of the model is shown within the large rectangle, the triangle may be drawn to the right of the model name in the tab. March 2003 OMG-Unified Modeling Language, v1.5 3-25 3 UML Notation Guide Relationships between models as well as relationships between elements in different models are shown using the notation for the given kind of relationship. In particular, trace dependencies are notated with a dashed line, with an optional open arrowhead, and the keyword «trace». 3.15.3 Presentation Options A model may be notated as a package, using the ordinary package symbol with the keyword «model» placed above the name of the model. 3.15.4 Example Figure 3-14 Three views of a physical system, each represented by a model. Figure 3-15 A «systemModel» containing an analysis model and a design model. AnalysisUse Case Design Model Model Model «systemModel» Analysis Design Model Model 3-26 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide Figure 3-16 Two examples of containment hierarchies with models and subsystems shown using branching lines. The left hierarchy is based on Model, whereas the right one is based on Subsystem. 3.15.5 Mapping A model symbol maps to a Model with the given name. The mapping is analogous to that of package symbols. Part 4 - General Extension Mechanisms The elements in this section are general purpose mechanisms that may be applied to any modeling element. The semantics of a particular use depends on a convention of the user or an interpretation by a particular constraint language or programming language; therefore, they constitute an extensibility device for UML. 3.16 Constraint and Comment 3.16.1 Semantics A constraint is a semantic relationship among model elements that specifies conditions and propositions that must be maintained as true; otherwise, the system described by the model is invalid (with consequences that are outside the scope of UML). Certain kinds of constraints (such as an association “xor” constraint) are predefined in UML, others may be user-defined. A user-defined constraint is described in words in a given language, whose syntax and interpretation is a tool responsibility. A constraint represents semantic information attached to a model element, not just to a view of it. A comment is a text string (including references to human-readable documents) attached directly to a model element. A comment can attach arbitrary textual information to any model element of presumed general importance but it has no semantic force. Comments may be used for explaining the reasons for decisions, among other things. March 2003 OMG-Unified Modeling Language, v1.5 3-27 3 UML Notation Guide 3.16.2 Notation A constraint is shown as a text string in braces ( { } ). There is an expectation that individual tools may provide one or more languages in which formal constraints may be written. One predefined language for writing constraints is OCL (see the Object Constraint Language Specification chapter); otherwise, the constraint may be written in natural language. Each constraint is written in a specific language, although the language is not generally displayed on the diagram (the tool must keep track of it, however). For an element whose notation is a text string (such as an attribute, etc.), the constraint string may follow the element text string in braces. For a list of elements whose notation is a list of text strings (such as the attributes within a class), a constraint string may appear as an element in the list. The constraint applies to all succeeding elements of the list until another constraint string list element or the end of the list. A constraint attached to an individual list element does not supersede the general constraint, but may augment or modify individual constraints within the constraint string. For a single graphical symbol (such as a class or an association path), the constraint string may be placed near the symbol, preferably near the name of the symbol, if any. For two graphical symbols (such as two classes or two associations), the constraint is shown as a dashed arrow from one element to the other element labeled by the constraint string (in braces). The direction of the arrow is relevant information within the constraint. The client (tail of the arrow) is mapped to the first position and the supplier (head of the arrow) is mapped to the second position in the constraint. For three or more graphical symbols, the constraint string is placed in a note symbol and attached to each of the symbols by a dashed line. This notation may also be used for the other cases. For three or more paths of the same kind (such as generalization paths or association paths), the constraint may be attached to a dashed line crossing all of the paths. A comment is shown as a text string (not enclosed in braces) within a note icon. Syntax for including comments within other elements (such as expressions or constraints) are not specified by UML but may be provided by a tool as part of the expression syntax for a particular language. 3-28 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.16.3 Example Figure 3-17 Constraints and comment 3.16.4 Mapping A constraint string is a string enclosed in braces ({ }). The constraint string maps into the body expression in a Constraint element. The mapping depends on the language of the expression, which is known to a tool but generally not displayed on a diagram. A constraint string following a list entry maps into a Constraint attached to the element corresponding to the list entry. A constraint string represented as a stand-alone list element maps into a separate Constraint attached to each succeeding model element corresponding to subsequent list entries (until superseded by another constraint or property string). A constraint string placed near a graphical symbol must be attached to the symbol by a hidden link by a tool operating in context. The tool must maintain the graphical linkage implicitly. The constraint string maps into a Constraint attached to the element corresponding to the symbol. A constraint string attached to a dashed arrow maps into a constraint attached to the two elements corresponding to the symbols connected by the arrow. A string enclosed in braces in a note symbol maps into a Constraint attached to the elements corresponding to the symbols connected to the note symbol by dashed lines. Member-of Chair-of {subset}Person Committee Person Company boss {Person.employer = Person.boss.employer} employerworker employee 0..1 ∗∗ ∗ ∗ ∗ 0..1 1 Represents an incorporated entity. March 2003 OMG-Unified Modeling Language, v1.5 3-29 3 UML Notation Guide A string (not enclosed in braces) in a note attached to the symbol for an element maps into a Comment attached to the corresponding element. 3.17 Element Properties Many kinds of elements have detailed properties that do not have a visual notation. In addition, users can define new element properties using the tagged value mechanism. A string may be used to display properties attached to a model element. This includes properties represented by attributes in the metamodel as well as both predefined and user-defined tagged values. 3.17.1 Semantics Note that we use property in a general sense to mean any value attached to a model element, including attributes, associations, and tagged values. In this sense it can include indirectly reachable values that can be found starting at a given element. Some kinds of properties would have syntax within expressions (not specified by UML) but no explicit UML notation. A tagged value is a keyword-value pair that may be attached to any kind of model element (including diagram elements as well as semantic model elements). The keyword is called a tag. Each tag represents a particular kind of property applicable to one or many kinds of model elements. Both the tag and the value are encoded as strings. Tagged values are an extensibility mechanism of UML permitting arbitrary information to be attached to models. It is expected that most model editors will provide basic facilities for defining, displaying, and searching tagged values as strings but will not otherwise use them to extend the UML semantics. It is expected, however, that back-end tools such as code generators, report writers, and the like will read tagged values to guide their semantics in flexible ways. 3.17.2 Notation A property (either a metamodel attribute or a tagged value) is displayed as a comma- delimited sequence of property specifications all inside a pair of braces ( { } ). A property specification has the form name = value where name is the name of a property (metamodel attribute or arbitrary tag) and value is an arbitrary string that denotes its value. If the type of the property is Boolean, then the default value is true if the value is omitted. That is, to specify a value of true you may include just the keyword. To specify a value of false, you omit the name completely. Properties of other types require explicit values. The syntax for displaying the value is a tool responsibility in cases where the underlying model value is not a string or a number. Note that property strings may be used to display built-in attributes as well as tagged values. 3-30 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide Boolean properties frequently have the form isName, where name is the name of some condition that may be true or false. In these cases, the form “name” may usually appear by itself, without a value, to mean “isName = true.” For example, {abstract} is the same as {isAbstract = true}. Tagged values can sometimes refer to other model elements (see Section 2.6.2.5, “TaggedValue,” on page 2-79). In that case, the usual tagged value format is used except that the value is the name of the model element that is referenced. Alternatively, it may be represented graphically using a «taggedValue» relationship, which uses the dependency notation. The direction of the dependency arrow is towards the referenced element. These two cases are illustrated in Figure 3-18 Figure 3-18 Alternative notations for tagged values as references 3.17.3 Presentation Options A tool may present property specifications on separate lines with or without the enclosing braces, provided they are marked appropriately to distinguish them from other information. For example, properties for a class might be listed under the class name in a distinctive typeface, such as italics or a different font family. «stereotype» Scheduler «stereotype» Manager { «taggedValue» jobScheduler : Scheduler [1] } «metaClass» Class «stereotype» Scheduler «stereotype» Manager «metaClass» Class jobSchedu ler [1] «stereotype»«stereotype» «taggedValue» «stereotype»«stereotype» March 2003 OMG-Unified Modeling Language, v1.5 3-31 3 UML Notation Guide 3.17.4 Style Guidelines It is legal to use strings to specify properties that have graphical notations; however, such usage may be confusing and should be used with care. 3.17.5 Example { author = “Joe Smith”, deadline = 31-March-1997, status = analysis } { abstract } 3.17.6 Mapping Each term within a string maps to either a built-in attribute of a model element or a tagged value (predefined or user-defined). A tool must enforce the correspondence to built-in attributes. 3.18 Stereotypes 3.18.1 Semantics A stereotype is, in effect, a new class of metamodel element that is introduced at modeling time. It represents a subclass of an existing metamodel element with the same form (attributes and relationships) but with a different intent. Generally a stereotype represents a usage distinction. A stereotyped element may have additional constraints on it from the base metamodel class. It may also have required tagged values that add information needed by elements with the stereotype. It is expected that code generators and other tools will treat stereotyped elements specially. Stereotypes represent one of the built-in extensibility mechanisms of UML. 3.18.2 Notation The general presentation of a stereotype is to use the symbol for the metamodel base element but to place a keyword string above the name of the element (if any). The keyword string (Section 3.9, “Keywords,” on page 3-11) is the name of the stereotype within matched guillemets, which are the quotation mark symbols used in French and certain other languages (for example, «foo»). Note – A guillemet looks like a double angle-bracket, but it is a single character in most extended fonts. Most computers have a Character Map utility. Double angle- brackets may be used as a substitute by the typographically challenged. The keyword string is generally placed above or in front of the name of the model element being described. If multiple stereotypes are defined for the same model element, they are placed vertically one below the other. The keyword string may also be used as an element in a list, in which case it applies to subsequent list elements until 3-32 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide another stereotype string replaces it, or an empty stereotype string («») nullifies it. Note that a stereotype name should not be identical to a predefined keyword applicable to the same element type. To permit limited graphical extension of the UML notation as well, a graphic icon or a graphic marker (such as texture or color) can be associated with a stereotype. The UML does not specify the form of the graphic specification, but many bitmap and stroked formats exist (and their portability is a difficult problem). The icon can be used in one of two ways: 1. It may be used instead of, or in addition to, the stereotype keyword string as part of the symbol for the base model element that the stereotype is based on. For example, in a class rectangle it is placed in the upper right corner of the name compartment. In this form, the normal contents of the item can be seen. 2. The entire base model element symbol may be “collapsed” into an icon containing the element name or with the name above or below the icon. Other information contained by the base model element symbol is suppressed. More general forms of icon specification and substitution are conceivable, but we leave these to the ingenuity of tool builders, with the warning that excessive use of extensibility capabilities may lead to loss of portability among tools. If multiple stereotypes are defined, the graphical icons or markers are omitted. UML avoids the use of graphic markers, such as color, that present challenges for certain persons (the color blind) and for important kinds of equipment (such as printers, copiers, and fax machines). None of the UML symbols require the use of such graphic markers. Users may use graphic markers freely in their personal work for their own purposes (such as for highlighting within a tool) but should be aware of their limitations for interchange and be prepared to use the canonical forms when necessary. The classification hierarchy of the stereotypes themselves can be displayed on a class diagram, as described in Section 3.35, “Stereotype Declaration,” on page 3-57. This capability is not required by many modelers who must use existing stereotypes but not define new kinds of stereotypes. 3.18.3 Examples Figure 3-19 on page 3-33 illustrates various notational forms of the stereotype notation. Note that the top four shapes are alternatives of each other. The next one shows how a dependency can be stereotyped and the bottom example illustrates a model element with multiple stereotypes. March 2003 OMG-Unified Modeling Language, v1.5 3-33 3 UML Notation Guide Figure 3-19 Varieties of Stereotype Notation 3.18.4 Mapping The use of a stereotype keyword maps into the stereotype relationship between the Element corresponding to the symbol containing the name and the Stereotype of the given name. The use of a stereotype icon within a symbol maps into the stereotype relationship between the Element corresponding to the symbol containing the icon and the Stereotype represented by the symbol. A tool must establish the connection when the symbol is created and there is no requirement that an icon represent uniquely one stereotype. The use of a stereotype icon, instead of a symbol, must be created in a context in which a tool implies a corresponding model element and a Stereotype represented by the icon. The element and the stereotype have the stereotype relationship. PenTracker «control» PenTracker «control» PenTracker PenTracker JobManager Scheduler«call» location: Point enable (Mode) location: Point enable (Mode) location: Point enable (Mode) Lock «control» reqQueue: Queue «semaphore» 3-34 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide Part 5 - Static Structure Diagrams Class diagrams show the static structure of the model, in particular, the things that exist (such as classes and types), their internal structure, and their relationships to other things. Class diagrams do not show temporal information, although they may contain reified occurrences of things that have or things that describe temporal behavior. An object diagram shows instances compatible with a particular class diagram. This section discusses classes and their variations, including templates and instantiated classes, and the relationships between classes (association and generalization) and the contents of classes (attributes and operations). 3.19 Class Diagram A class diagram is a graph of Classifier elements connected by their various static relationships. Note that a “class” diagram may also contain interfaces, packages, relationships, and even instances, such as objects and links. Perhaps a better name would be “static structural diagram” but “class diagram” is shorter and well established. 3.19.1 Semantics A class diagram is a graphic view of the static structural model. The individual class diagrams do not represent divisions in the underlying model. 3.19.2 Notation A class diagram is a collection of static declarative model elements, such as classes, interfaces, and their relationships, connected as a graph to each other and to their contents. Class diagrams may be organized into packages either with their underlying models or as separate packages that build upon the underlying model packages. 3.19.3 Mapping A class diagram does not necessarily match a single semantic entity. A package within the static structural model may be represented by one or more class diagrams. The division of the presentation into separate diagrams is for graphical convenience and does not imply a partitioning of the model itself. The contents of a diagram map into elements in the static semantic model. If a diagram is part of a package, then its contents map into elements in the same package (including possible references to elements accessed or imported from other packages). March 2003 OMG-Unified Modeling Language, v1.5 3-35 3 UML Notation Guide 3.20 Object Diagram An object diagram is a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The use of object diagrams is fairly limited, mainly to show examples of data structures. Tools need not support a separate format for object diagrams. Class diagrams can contain objects, so a class diagram with objects and no classes is an “object diagram.” The phrase is useful, however, to characterize a particular usage achievable in various ways. 3.21 Classifier Classifier is the metamodel superclass of Class, DataType, and Interface. All of these have similar syntax and are therefore all notated using the rectangle symbol with keywords used as necessary. Because classes are most common in diagrams, a rectangle without a keyword represents a class, and the other subclasses of Classifier are indicated with keywords. In the sections that follow, the discussion will focus on Class, but most of the notation applies to the other element kinds as semantically appropriate and as described later under their own sections. 3.22 Class A class is the descriptor for a set of objects with similar structure, behavior, and relationships. The model is concerned with describing the intension of the class, that is, the rules that define it. The run-time execution provides its extension, that is, its instances. UML provides notation for declaring classes and specifying their properties, as well as using classes in various ways. Some modeling elements that are similar in form to classes (such as interfaces, signals, or utilities) are notated using keywords on class symbols; some of these are separate metamodel classes and some are stereotypes of Class. Classes are declared in class diagrams and used in most other diagrams. UML provides a graphical notation for declaring and using classes, as well as a textual notation for referencing classes within the descriptions of other model elements. 3.22.1 Semantics A class represents a concept within the system being modeled. Classes have data structure and behavior and relationships to other elements. The name of a class has scope within the package in which it is declared and the name must be unique (among class names) within its package. 3-36 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.22.2 Basic Notation A class is drawn as a solid-outline rectangle with three compartments separated by horizontal lines. The top name compartment holds the class name and other general properties of the class (including stereotype); the middle list compartment holds a list of attributes; the bottom list compartment holds a list of operations. See Section 3.23, “Name Compartment,” on page 3-38 and Section 3.24, “List Compartment,” on page 3-38 for more details. 3.22.2.1 References By default a class shown within a package is assumed to be defined within that package. To show a reference to a class defined in another package, use the syntax Package-name::Class-name as the name string in the name compartment. A full pathname can be specified by chaining together package names separated by double colons (::). 3.22.3 Presentation Options Either or both of the attribute and operation compartments may be suppressed. A separator line is not drawn for a missing compartment. If a compartment is suppressed, no inference can be drawn about the presence or absence of elements in it. Compartment names can be used to remove ambiguity, if necessary (Section3.24, “ List Compartment,” on page 3-38). Additional compartments may be supplied as a tool extension to show other predefined or user-defined model properties (for example, to show business rules, responsibilities, variations, events handled, exceptions raised, and so on). Most compartments are simply lists of strings. More complicated formats are possible, but UML does not specify such formats; they are a tool responsibility. Appearance of each compartment should preferably be implicit based on its contents. Compartment names may be used, if needed. Tools may provide other ways to show class references and to distinguish them from class declarations. A class symbol with a stereotype icon may be “collapsed” to show just the stereotype icon, with the name of the class either inside the class or below the icon. Other contents of the class are suppressed. 3.22.4 Style Guidelines • Center class name in boldface. • Center keyword (including stereotype names) in plain face within guillemets above class name. March 2003 OMG-Unified Modeling Language, v1.5 3-37 3 UML Notation Guide • For those languages that distinguish between uppercase and lowercase characters, capitalize class names; that is, begin them with an uppercase character. • Left justify attributes and operations in plain face. • Begin attribute and operation names with a lowercase letter. • Show the names of abstract classes or the signatures of abstract operations in italics. As a tool extension, boldface may be used for marking special list elements; for example, to designate candidate keys in a database design. This might encode some design property modeled as a tagged value, for example. Show full attributes and operations when needed and suppress them in other contexts or references. 3.22.5 Example Figure 3-20 Class Notation: Details Suppressed, Analysis-level Details, Implementation-level Details 3.22.6 Mapping A class symbol maps into a Class element within the package that owns the diagram. The name compartment contents map into the class name and into properties of the class (built-in attributes or tagged values). The attribute compartment maps into a list of Attributes of the Class. The operation compartment maps into a list of Operations of the Class. The property string {location=name} maps into an implementationLocation association to a Component. The name is the name of the containing Component. Window display () size: Area visibility: Boolean hide () Window Window +default-size: Rectangle #maximum-size: Rectangle +create () +display () +size: Area = (100,100) #visibility: Boolean = true +hide () -xptr: XWindow* -attachXWindow(xwin:Xwindow*) {abstract, author=Joe, status=tested} 3-38 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.23 Name Compartment 3.23.1 Notation The name compartment displays the name of the class and other properties in up to three sections: An optional stereotype keyword may be placed above the class name within guillemets, and/or a stereotype icon may be placed in the upper right corner of the compartment. The stereotype name must not match a predefined keyword. The name of the class appears next. If the class is abstract, this can be indicated by italicizing its name (for those languages that support italicization) or by placing the keyword abstract in a property list below or after the name; for example, Invoice {abstract}. Note that any explicit specification of generalization status takes precedence over the name font. A list of strings denoting properties (metamodel attributes or tagged values) may be placed in braces below the class name. The list may show class-level attributes for which there is no UML notation and it may also show tagged values. The presence of a keyword for a Boolean type without a value implies the value true. For example, a leaf class shows the property “{leaf}”. The stereotype and property list are optional. Figure 3-21 Name Compartment 3.23.2 Mapping The contents of the name compartment map into the name, stereotype, and various properties of the Class represented by the class symbol. 3.24 List Compartment 3.24.1 Notation A list compartment holds a list of strings, each of which is the encoded representation of a feature, such as an attribute or operation. The strings are presented one to a line with overflow to be handled in a tool-dependent manner. In addition to lists of PenTracker «controller» { leaf, author=”Mary Jones”} March 2003 OMG-Unified Modeling Language, v1.5 3-39 3 UML Notation Guide attributes or operations, optional lists can show other kinds of predefined or user- defined values, such as responsibilities, rules, or modification histories. UML does not define these optional lists. The manipulation of user-defined lists is tool-dependent. The items in the list are ordered and the order may be modified by the user. The order of the elements is meaningful information and must be accessible within tools (for example, it may be used by a code generator in generating a list of declarations). The list elements may be presented in a different order to achieve some other purpose (for example, they may be sorted in some way). Even if the list is sorted, the items maintain their original order in the underlying model. The ordering information is merely suppressed in the view. An ellipsis ( . . . ) as the final element of a list or the final element of a delimited section of a list indicates that additional elements in the model exist that meet the selection condition, but that are not shown in that list. Such elements may appear in a different view of the list. 3.24.1.1 Group properties A property string may be shown as an element of the list, in which case it applies to all of the succeeding list elements until another property string appears as a list element. This is equivalent to attaching the property string to each of the list elements individually. The property string does not designate a model element. Examples of this usage include indicating a stereotype and specifying visibility. Keyword strings may also be used in a similar way to qualify subsequent list elements. 3.24.1.2 Compartment name A compartment may display a name to indicate which kind of compartment it is. The name is displayed in a distinctive font centered at the top of the compartment. This capability is useful if some compartments are omitted or if additional user-defined compartments are added. For a Class, the predefined compartments are named attributes and operations. An example of a user-defined compartment might be requirements. The name compartment in a class must always be present; therefore, it does not require or permit a compartment name. 3.24.2 Presentation Options A tool may present the list elements in a sorted order, in which case the inherent ordering of the elements is not visible. A sort is based on some internal property and does not indicate additional model information. Example sort rules include: • alphabetical order, • ordering by stereotype (such as constructors, destructors, then ordinary methods), • ordering by visibility (public, then package, then protected, then private). The elements in the list may be filtered according to some selection rule. The specification of selection rules is a tool responsibility. The absence of items from a filtered list indicates that no elements meet the filter criterion, but no inference can be 3-40 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide drawn about the presence or absence of elements that do not meet the criterion. However, the ellipsis notation is available to show that invisible elements exist. It is a tool responsibility whether and how to indicate the presence of either local or global filtering, although a stand-alone diagram should have some indication of such filtering if it is to be understandable. If a compartment is suppressed, no inference can be drawn about the presence or absence of its elements. An empty compartment indicates that no elements meet the selection filter (if any). Note that attributes may also be shown by composition (see Figure 3-45 on page 3-83). 3.24.3 Example Figure 3-22 Stereotype Keyword Applied to Groups of List Elements «constructor» Rectangle(p1:Point, p2:Point) «query» area (): Real aspect (): Real «update» move (delta: Point) scale (ratio: Real) . . . . . . Rectangle p1:Point p2:Point March 2003 OMG-Unified Modeling Language, v1.5 3-41 3 UML Notation Guide Figure 3-23 Compartments with Names 3.24.4 Mapping The entries in a list compartment map into a list of ModelElements, one for each list entry. The ordering of the ModelElements matches the list compartment entries (unless the list compartment is sorted in some way). In this case, no implication about the ordering of the Elements can be made (the ordering can be seen by turning off sorting). However, a list entry string that is a stereotype indication (within guillemets) or a property indication (within braces) does not map into a separate ModelElement. Instead, the corresponding property applies to each subsequent ModelElement until the appearance of a different stand-alone stereotype or property indicator. The property specifications are conceptually duplicated for each list Element, although a tool might maintain an internal mechanism to store or modify them together. The presence of an ellipsis (“...”) as a list entry implies that the semantic model contains at least one Element with corresponding properties that is not visible in the list compartment. 3.25 Attribute Strings in the attribute compartment are used to show attributes in classes. A similar syntax is used to specify qualifiers, template parameters, operation parameters, and so on (some of these omit certain terms). 3.25.1 Semantics Note that an attribute is semantically equivalent to a composition association; however, the intent and usage is normally different. bill no-shows Reservation operations guarantee() cancel () change (newDate: Date) responsibilities match to available rooms exceptions invalid credit card 3-42 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide The type of an attribute is a Classifier. 3.25.2 Notation An attribute is shown as a text string that can be parsed into the various properties of an attribute model element. The default syntax is: visibility name : type-expression [ multiplicity ordering ] = initial-value { property-string } • Where visibility is one of: + public visibility # protected visibility - private visibility ~ .package visibility The visibility marker may be suppressed. The absence of a visibility marker indicates that the visibility is not shown (not that it is undefined or public). A tool should assign visibilities to new attributes even if the visibility is not shown. The visibility marker is a shorthand for a full visibility property specification string. Visibility may also be specified by keywords (public, protected, private, package). This form is used particularly when it is used as an inline list element that applies to an entire block of attributes. Additional kinds of visibility might be defined for certain programming languages, such as C++ implementation visibility (actually all forms of nonpublic visibility are language-dependent). Such visibility must be specified by property string or by a tool-specific convention. • Where name is an identifier string that represents the name of the attribute. • Where [ multiplicity ordering] shows the multiplicity and the ordering of the attribute (Section 3.44, “Multiplicity,” on page 3-75). The term may be omitted, in which case the multiplicity is 1..1 (exactly one). • The ordering property is meaningful if the multiplicity upper bound is greater than one. It may be one of: • (absent) — the values are unordered • unordered — the values are unordered • ordered — the values are ordered • Where type-expression is either • if it is a simple word, the name of a classifier, or • a language-dependent string that maps into a ProgrammingLanguageDataType. • Where initial-value is a language-dependent expression for the initial value of a newly created object. The initial value is optional (the equal sign is also omitted). An explicit constructor for a new object may augment or modify the default initial value. March 2003 OMG-Unified Modeling Language, v1.5 3-43 3 UML Notation Guide • Where property-string indicates property values that apply to the element. The property string is optional (the braces are omitted if no properties are specified). A class-scope attribute is shown by underlining the name and type expression string; otherwise, the attribute is instance-scope. class-scope-attribute The notation justification is that a class-scope attribute is an instance value in the executing system, just as an object is an instance value, so both may be designated by underlining. An instance-scope attribute is not underlined; that is the default. There is no symbol for whether an attribute is changeable (the default is changeable). A nonchangeable attribute is specified with the property “{frozen}”. In the absence of a multiplicity indicator, an attribute holds exactly 1 value. Multiplicity may be indicated by placing a multiplicity indicator in brackets after the classifier name, for example: colors : Color [3] points : Point [2..* ordered] Note that a multiplicity of 0..1 provides for the possibility of null values: the absence of a value, as opposed to a particular value from the range. For example, the following declaration permits a distinction between the null value and the empty string: name : String [0..1] A stereotype keyword in guillemets precedes the entire attribute string, including any visibility indicators. A property list in braces follows the rest of the attribute string. 3.25.3 Presentation Options The type expression may be suppressed (but it has a value in the model). The initial value may be suppressed, and it may be absent from the model. It is a tool responsibility whether and how to show this distinction. A tool may show the visibility indication in a different way, such as by using a special icon or by sorting the elements by group. A tool may show the individual fields of an attribute as columns rather than a continuous string. If the type-expression string is not a word, then it is assumed to be expressed in the syntax of a particular programming language, such as C++ or Smalltalk. This form is assumed if the string is not a word. Specific tagged properties may be included in the string. The programming language must be known from the general context of the diagram or a tool supporting it. In this case, the type-expression maps into a ProgrammingLanguageDataType whose expression attribute specifies the language name and the string representation of the data type in that language. Particular attributes within a list may be suppressed (see Section 3.24, “List Compartment,” on page 3-38). 3-44 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.25.4 Style Guidelines Attribute names typically begin with a lowercase letter. Attribute names are in plain face. 3.25.5 Example +size: Area = (100,100) #visibility: Boolean = invisible +default-size: Rectangle #maximum-size: Rectangle -xptr: XWindowPtr 3.25.6 Mapping A string entry within the attribute compartment maps into an Attribute within the Class corresponding to the class symbol. The properties of the attribute map in accord with the preceding descriptions. If the visibility is absent, then no conclusion can be drawn about the Attribute visibilities unless a filter is in effect; for example, only public attributes shown. Likewise, if the type or initial value are omitted. The omission of an underline always indicates an instance-scope attribute. The omission of multiplicity denotes a multiplicity of 1. Any properties specified in braces following the attribute string map into properties on the Attribute. In addition, any properties specified on a previous stand-alone property specification entry apply to the current Attribute (and to others). 3.26 Operation Entries in the operation compartment are strings that show operations defined on classes and methods supplied by classes. 3.26.1 Semantics An operation is a service that an instance of the class may be requested to perform. It has a name and a list of arguments. 3.26.2 Notation An operation is shown as a text string that can be parsed into the various properties of an operation model element. The default syntax is: visibility name ( parameter-list ) : return-type-expression { property-string } • Where visibility is one of: + public visibility # protected visibility March 2003 OMG-Unified Modeling Language, v1.5 3-45 3 UML Notation Guide - private visibility ~ package visibility The visibility marker may be suppressed. The absence of a visibility marker indicates that the visibility is not shown (not that it is undefined or public). The visibility marker is a shorthand for a full visibility property specification string. Visibility may also be specified by keywords (public, protected, private, package). This form is used particularly when it is used as an inline list element that applies to an entire block of operations. Additional kinds of visibility might be defined for certain programming languages, such as C++ implementation visibility (actually all forms of nonpublic visibility are language-dependent). Such visibility must be specified by property string or by a tool-specific convention. • Where name is an identifier string. • Where return-type-expression is a language-dependent specification of the implementation type or types of the value returned by the operation. The colon and the return-type are omitted if the operation does not return a value (as for C++ void). A list of expressions may be supplied to indicate multiple return values. • Where parameter-list is a comma-separated list of formal parameters, each specified using the syntax: kind name : type-expression = default-value • where kind is in, out, or inout, with the default in if absent. • where name is the name of a formal parameter. • where type-expression is the (language-dependent) specification of an implementation type. • where default-value is an optional value expression for the parameter, expressed in and subject to the limitations of the eventual target language. • Where property-string indicates property values that apply to the element. The property string is optional (the braces are omitted if no properties are specified). A class-scope operation is shown by underlining the name and type expression string. An instance-scope operation is the default and is not marked. An operation that does not modify the system state (one that has no side effects) is specified by the property “{query}”; otherwise, the operation may alter the system state, although there is no guarantee that it will do so. The concurrency semantics of an operation are specified by a property string of the form “{concurrency = name}, where name is one of the names: sequential, guarded, concurrent. As a shorthand, one of the names may be used by itself in a property string to indicate the corresponding concurrency value. In the absence of a specification, the concurrency semantics are unspecified and must therefore be assumed to be sequential in the worst case. 3-46 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide The top-most appearance of an operation signature declares the operation on the class (and inherited by all of its descendents). If this class does not implement the operation; that is, does not supply a method, then the operation may be marked as “{abstract}” or the operation signature may be italicized to indicate that it is abstract. A subordinate appearance of the operation signature without the {abstract} property indicates that the subordinate class implements a method on the operation. The actual text or procedure of a method may be indicated in a note attached to the operation. If the objects of a class accept and respond to a given signal, an operation entry with the keyword «signal» indicates that the class accepts the given signal. The syntax is identical to that of an operation. The response of the object to the reception of the signal is shown with a state machine. Among other uses, this notation can show the response of objects of a class to error conditions and exceptions, which should be modeled as signals. The specification of operation behavior is given as a note attached to the operation. The text of the specification should be enclosed in braces if it is a formal specification in some language (a semantic Constraint); otherwise, it should be plain text if it is just a natural-language description of the behavior (a Comment). A stereotype keyword in guillemets precedes the entire operation string, including any visibility indicators. A property list in braces follows the entire operation string. 3.26.3 Presentation Options The argument list and return type may be suppressed (together, not separately). A tool may show the visibility indication in a different way, such as by using a special icon or by sorting the elements by group. The syntax of the operation signature string can be that of a particular programming language, such as C++ or Smalltalk. Specific tagged properties may be included in the string. A procedure body for a method may be shown in a note attached to the operation entry within the compartment (Figure 3-24 on page 3-47). The line is drawn to the string within the compartment. This approach is useful mainly for showing small method bodies. March 2003 OMG-Unified Modeling Language, v1.5 3-47 3 UML Notation Guide . Figure 3-24 Note showing method body 3.26.4 Style Guidelines Operation names typically begin with a lowercase letter. Operation names are in plain face. An abstract operation may be shown in italics. 3.26.5 Example Figure 3-25 Operation List with a Variety of Operations 3.26.6 Mapping A string entry within the operation compartment maps into an Operation or a Method within the Class corresponding to the class symbol. The properties of the operation map in accordance with the preceding descriptions. See the description of Section3.25, “Attribute,” on page 3-41 for additional details. Parameters without keywords map into Parameters with kind=in, otherwise according to the keyword. Return value names map into Parameters with kind=return. If the entry has the keyword «signal», then it maps into a Reception on the Class instead. report () BurglarAlarm isTripped: Boolean = false PoliceStation 1 station * { if isTripped then station.alert(self)} alert (Alarm) +create () +display (): Location +hide () -attachXWindow(xwin:Xwindow*) 3-48 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide The topmost appearance of an operation specification in a class hierarchy maps into an Operation definition in the corresponding Class or Interface. Interfaces do not have methods. In a Class, each appearance of an operation entry maps into the presence of a Method in the corresponding Class, unless the operation entry contains the {abstract} property (including use of conventions such as italics for abstract operations). If an abstract operation entry appears within a hierarchy in which the same operation has already been defined in an ancestor, it has no effect but is not an error unless the declarations are inconsistent. Note that the operation string entry does not specify the body of a method. 3.27 Nested Class Declarations 3.27.1 Semantics A class declared within another class belongs to the namespace of the other class and may only be used within it. This construct is primarily used for implementation reasons and for information hiding. 3.27.2 Notation A declaring class and a class in its namespace may be connected by a line, with an “anchor” icon on the end connected to a declaring class (Figure 3-26 on page 3-48). An anchor icon is a cross inside a circle. The contents of the package are declared within the class and belong to its namespace. 3.27.3 Mapping If Class B is attached to Class A by an “anchor” line with the “anchor” symbol on Class A, then Class B is declared within the Namespace of Class A. That is, the relationship between Class A and Class B is the namespace-ownedElement association. Figure 3-26 Nested class declaration DeclaringClass NestedClass March 2003 OMG-Unified Modeling Language, v1.5 3-49 3 UML Notation Guide 3.28 Type and Implementation Class 3.28.1 Semantics Classes can be stereotyped as Types or Implementation Classes (although they can be left undifferentiated as well). A Type is used to specify a domain of objects together with operations applicable to the objects without defining the physical implementation of those objects. A Type may not include any methods, but it may provide behavioral specifications for its operations. It may also have attributes and associations that are defined solely for the purpose of specifying the behavior of the type’s operations. An Implementation Class defines the physical data structure (for attributes and associations) and methods of an object as implemented in traditional languages (C++, Smalltalk, etc.). An Implementation Class is said to realize a Type if it provides all of the operations defined for the Type with the same behavior as specified for the Type’s operations. An Implementation Class may realize a number of different Types. 3.28.2 Notation An undifferentiated class is shown with no stereotype. A type is shown with the stereotype “«type».” An implementation class is shown with the stereotype “«implementationClass».” A tool is also free to allow a default setting for an entire diagram, in which case all of the class symbols without explicit stereotype indications map into Classes with the default stereotype. This might be useful for a model that is close to the programming level. The implementation of a type by a class is modeled as the Realization relationship, shown as a dashed line with a solid triangular arrowhead (a dashed “generalization arrow”). This symbol implies the realizing class provides at least all the operations of the Type, with conforming behavior, but it does not imply inheritance of structure (attributes or associations). The generalization hierarchy of a set of classes frequently parallels the generalization hierarchy of a set of types that they realize, but this is not mandatory, as long as each class provides the operations of the types that it realizes. 3-50 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.28.3 Example Figure 3-27 Notation for Types and Implementation Classes 3.28.4 Mapping A class symbol with a stereotype (including “type” and “implementationClass”) maps into a Class with the corresponding stereotype. A class symbol without a stereotype maps into a Class with the default stereotype for the diagram (if a default has been defined by the modeler or tool); otherwise, it maps into a Class with no stereotype. The realization arrow between two symbols maps into an Abstraction relationship, with the «realize» stereotype, between the Classifiers corresponding to the two symbols. Realization is usually used between a class and an interface, but may also be used between any two classifiers to show conformance of behavior. 3.29 Interfaces 3.29.1 Semantics An interface is a specifier for the externally-visible operations of a class, component, or other classifier (including subsystems) without specification of internal structure. Each interface often specifies only a limited part of the behavior of an actual class. Interfaces do not have implementation. They lack attributes, states, or associations; they only have operations. (An interface may be the target of a one-way association, Set «type» addElement(Object) removeElement(Object) testElement(Object):Boolean * elements Object «type» HashTableSet «implementationClass» addElement(Object) removeElement(Object) testElement(Object):Boolean 1 body HashTable «implementationClass» setTableSize(Integer) March 2003 OMG-Unified Modeling Language, v1.5 3-51 3 UML Notation Guide however, but it may not have an association that it can navigate.) Interfaces may have generalization relationships. An interface is formally equivalent to an abstract class with no attributes and no methods and only abstract operations, but Interface is a peer of Class within the UML metamodel (both are Classifiers). 3.29.2 Notation An interface is a Classifier and may be shown using the full rectangle symbol with compartments and the keyword «interface». A list of operations supported by the interface is placed in the operation compartment. The attribute compartment may be omitted because it is always empty. An interface may also be displayed as a small circle with the name of the interface placed below the symbol. The circle may be attached by a solid line to classifiers that support it. This indicates that the class provides all of the operations in the interface type (and possibly more). The operations provided are not shown on the circle notation; use the full rectangle symbol to show the list of operations. A class that uses or requires the operations supplied by the interface may be attached to the circle by a dashed arrow pointing to the circle. The dashed arrow implies that the class requires no more than the operations specified in the interface; the client class is not required to actually use all of the interface operations. The Realization relationship from a classifier to an interface that it supports is shown by a dashed line with a solid triangular arrowhead (a “dashed generalization symbol”). This is the same notation used to indicate realization of a type by an implementation class. In fact, this symbol can be used between any two classifier symbols, with the meaning that the client (the one at the tail of the arrow) supports at least all of the operations defined in the supplier (the one at the head of the arrow), but with no necessity to support any of the data structure of the supplier (attributes and associations). 3.29.3 Example Figure 3-28 Shorthand Version of Interface Notation +create() +login(UserName, Passwd) +find(StoreId) +getPOStotals(POSid) +updateStoreTotals(Id,Sales) +get(Item) -storeId: Integer -POSlist: List Store POSterminal POSterminalHome <> StoreHome Store POSterminal 3-52 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide Figure 3-29 Longhand Version of Interface Notation 3.29.4 Mapping A class rectangle symbol with stereotype «interface», or a circle on a class diagram, maps into an Interface element with the name given by the symbol. The operation list of a rectangle symbol maps into the list of Operation elements of the Interface. A dashed generalization arrow from a class symbol to an interface symbol, or a solid line connecting a class symbol and an interface circle, maps into an Abstraction dependency with the «realize» stereotype between the corresponding Classifier and Interface elements. A dependency arrow from a class symbol to an interface symbol maps into a Usage dependency between the corresponding Classifier and Interface. 3.30 Parameterized Class (Template) 3.30.1 Semantics A template is the descriptor for a class with one or more unbound formal parameters. It defines a family of classes, each class specified by binding the parameters to actual values. Typically, the parameters represent attribute types; however, they can also represent integers, other types, or even operations. Attributes and operations within the template are defined in terms of the formal parameters so they too become bound when the template itself is bound to actual values. A template is not a directly usable class because it has unbound parameters. Its parameters must be bound to actual values to create a bound form that is a class. Only a class can be a superclass or the target of an association (a one-way association from the template to another class is permissible, however). A template may be a subclass of an ordinary class. This implies that all classes formed by binding it are subclasses of the given superclass. Parameterization can be applied to other ModelElements, such as Collaborations or even entire Packages. The description given here for classes applies to other kinds of modeling elements in the obvious way. +create() +login(UserName, Passwd) +find(StoreId) +getPOStotals(POSid) +updateStoreTotals(Id,Sales) +get(Item) -storeId: Integer -POSlist: List Store POSterminal POSterminalHome <> StoreHome POSterminal +getPOStotals(POSid) +updateStoreTotals(Id,Sales) +get(Item) <> Store March 2003 OMG-Unified Modeling Language, v1.5 3-53 3 UML Notation Guide 3.30.2 Notation A small dashed rectangle is superimposed on the upper right-hand corner of the rectangle for the class (or to the symbol for another modeling element). The dashed rectangle contains a parameter list of formal parameters for the class and their implementation types. The list must not be empty, although it might be suppressed in the presentation. The name, attributes, and operations of the parameterized class appear as normal in the class rectangle; however, they may also include occurrences of the formal parameters. Occurrences of the formal parameters can also occur inside of a context for the class, for example, to show a related class identified by one of the parameters. 3.30.3 Presentation Options The parameter list may be comma-separated or it may be one per line. Parameters are restricted attributes, shown as strings with the syntax: name : type = default-value • Where name is an identifier for the parameter with scope inside the template. • Where type is a string designating a Classifier for the parameter. If it is a simple word, it must be the name of a Classifier. Otherwise it is a programming-language dependent string that maps into a ProgrammingLanguageDataType according to the programming language (if any) for the diagram context or specified in a support tool. • Where default-value is a string designating an Expression for a default value that is used when the corresponding argument is omitted in a Binding. The equal sign and expression may be omitted, in which case there is no default value and the argument must be supplied in a Binding. If the type name is omitted, the parameter type is assumed to be Classifier. The value supplied for an argument in a Binding must be the name of a Classifier (including a class or a data type). Other parameter types (such as Integer) must be explicitly shown. The value supplied for an argument in a Binding must be an actual instance value of the given kind. 3-54 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.30.4 Example Figure 3-30 Template Notation with Use of Parameter as a Reference 3.30.5 Mapping The addition of the template dashed box to a symbol causes the addition of the parameter names in the list as ModelElements within the Namespace of the ModelElement corresponding to the base symbol (or to the Namespace containing a ModelElement that is not itself a Namespace). Each of the parameter ModelElements has the templateParameter association to the base ModelElement. 3.31 Bound Element 3.31.1 Semantics A template cannot be used directly in an ordinary relationship such as generalization or association, because it has a free parameter that is not meaningful outside of a scope that declares the parameter. To be used, a template’s parameters must be bound to actual values. The actual value for each parameter is an expression defined within the scope of use. If the referencing scope is itself a template, then the parameters of the referencing template can be used as actual values in binding the referenced template. The parameter names in the two templates cannot be assumed to correspond because they have no scope outside of their respective templates. FArray FArray T,k:Integer «bind» (Address,24) T k..k AddressList March 2003 OMG-Unified Modeling Language, v1.5 3-55 3 UML Notation Guide 3.31.2 Notation A bound element is indicated by a text syntax in the name string of an element, as follows: Template-name ‘<‘ value-list ‘>’ • Where value-list is a comma-delimited non-empty list of value expressions. • Where Template-name is identical to the name of a template. For example, VArray designates a class described by the template Varray. The number and type of values must match the number and type of the template parameters for the template of the given name. The bound element name may be used anywhere that an element name of the parameterized kind could be used. For example, a bound class name could be used within a class symbol on a class diagram, as an attribute type, or as part of an operation signature. Note that a bound element is fully specified by its template; therefore, its content may not be extended. Declaration of new attributes or operations for classes is not permitted, for example, but a bound class could be subclassed and the subclass extended in the usual way. The relationship between the bound element and its template alternatively may be shown by a Dependency relationship with the keyword «bind». The arguments are shown in parentheses after the keyword. In this case, the bound form may be given a name distinct from the template. 3.31.3 Style Guidelines The attribute and operation compartments are normally suppressed within a bound class, because they must not be modified in a bound template. 3.31.4 Example See Figure 3-30 on page 3-54. 3.31.5 Mapping The use of the bound element syntax for the name of a symbol maps into a Binding dependency between the dependent ModelElement (such as Class) corresponding to the bound element symbol and the provider ModelElement (again, such as Class) whose name matches the name part of the bound element without the arguments. If the name does not match a template element or if the number of arguments in the bound element does not match the number of parameters in the template, then the model is ill formed. Each argument position in the bound element maps into a TemplateArgument bearing a binding link to the Binding dependency and a modelElement link to the 3-56 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide ModelElement that is implicitly substituted for the template parameter in the corresponding position in the template definition. An explicitly drawn «bind» dependency symbol maps to a Binding dependency with arguments as described above. 3.32 Utility A utility is a grouping of global variables and procedures in the form of a class declaration. This is not a fundamental construct, but a programming convenience. The attributes and operations of the utility become global variables and procedures. A utility is modeled as a stereotype of a classifier. 3.32.1 Semantics The instance-scope attributes and operations of a utility are interpreted as global attributes and operations. It is inappropriate for a utility to declare class-scope attributes and operations because the instance-scope members are already interpreted as being at class scope. 3.32.2 Notation A utility is shown as the stereotype «utility» of Class. It may have both attributes and operations, all of which are treated as global attributes and operations. 3.32.3 Example Figure 3-31 Notation for Utility 3.32.4 Mapping This is not a special symbol. It simply maps into a Class element with the «utility» stereotype. MathPak «utility» sin (Angle): Real sqrt (Real): Real random(): Real cos (Angle): Real March 2003 OMG-Unified Modeling Language, v1.5 3-57 3 UML Notation Guide 3.33 Metaclass 3.33.1 Semantics A metaclass is a class whose instances are classes. 3.33.2 Notation A metaclass is shown as the stereotype «metaclass» of Class. 3.33.3 Mapping This is not a special symbol. It simply maps into a Class element with the «metaclass» stereotype. 3.34 Enumeration 3.34.1 Semantics An Enumeration is a user-defined data type whose instances are a set of user-specified named enumeration literals. The literals have a relative order but no algebra is defined on them. 3.34.2 Notation An Enumeration is shown using the Classifier notation (a rectangle) with the keyword «enumeration». The name of the Enumeration is placed in the upper compartment. An ordered list of enumeration literals may be placed, one to a line, in the middle compartment. Operations defined on the literals may be placed in the lower compartment. The lower and middle compartments may be suppressed. 3.34.3 Mapping Maps into an Enumeration with the given list of enumeration literals. 3.35 Stereotype Declaration 3.35.1 Semantics A Stereotype is a user-defined metaelement whose structure matches an existing UML metaelement (its “base class”). Because it is user defined, a stereotype declaration is an element that appears at the “model” layer of the UML four-layer metamodeling hierarchy although it conceptually belongs in the layer above, the metamodel layer. 3-58 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide 3.35.2 Notation Because stereotypes span two different metamodeling layers, a special notation is required to clearly indicate the crossover between the two layers. Specifically, it is necessary to show how a model-level element (the stereotype) relates to its metaelement (its UML base class). This is denoted using a special stereotype of Dependency called «stereotype» as shown in Figure 3-32 on page 3-59. The Stereotype itself is shown using the Classifier notation (a rectangle) with the keyword «stereotype» (Figure 3-32). The name of the Stereotype is placed in the upper compartment. Constraints on elements described by the stereotype may be placed in a named compartment called Constraints. Required tags may be placed in a named compartment called Tags. Individual items (tags) in the list are defined according to the following format: tagDefinitionName : String [multiplicity] where string can be either a string matching the name of a data type representing the type of the values of the tag, or it is a reference to a metaclass or a stereotype. In the latter case, the string has the form: «metaclass» metaclassName or «stereotype» stereotypeName where metaclassName is the name of the referenced metaclass and is the name of the references stereotype. The multiplicity element is optional and conforms to standard rules for specifying multiplicities. In case of a range specification, a lower bound of zero indicates an optional tag. March 2003 OMG-Unified Modeling Language, v1.5 3-59 3 UML Notation Guide Figure 3-32 Notational form for declaring a stereotype In the example diagram in Figure 3-32, the stereotype Persistent is a stereotype of the UML metaelement Class. TableName is an optional tag whose type is a model type called String while SQLFile is a reference to an instance of Component in the model. An icon can be defined for the stereotype, but its graphical definition is outside the scope of UML and must be handled by an editing tool. An alternative and usually more compact way of specifying stereotypes and tags using tables is shown in Figure 3-33 and Figure 3-34, respectively. Figure 3-33 Tabular form for specifying stereotypes Figure 3-34 Tabular form for specifying tags Stereotype Base Class Parent Tags Constraints Description Architectural Element Generalizable Element N/A N/A N/A A generic stereotype that is the parent of all other stereotypes used for archi- tectural modeling . Capsule Class Architectural Element isDynamic self.isActive = true Indicates a class that is used to model the structural components of an archi- tecture specification. Tag Stereotype Type Multiplicity Description isDynamic Capsule UML::Datatypes::Boolean 1 Used to identify if the associated capsule class may be created and destroyed dynamically. Class «metaclass» «stereotype» Constraints {TableName should not be longer than 8 characters} «stereotype» Persistent Tags SQLFile : «metaclass» Component TableName : String [0..1] 3-60 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide Each row of the stereotype specification table in Figure 3-33 defines one stereotype and each row in the tag specification table in Figure 3-34 contains one tag definition. The columns of the stereotype specification table are defined as follows: • Stereotype - the name of the stereotype. • Base Class - the UML metamodel element that serves as the base for the stereotype. • Parent - the direct parent of the stereotype being defined (NB: if one exists, otherwise the symbol “N/A” is used). • Tags - a list of all tags of the tagged values that may be associated with this stereotype (or N/A if none are defined). • Constraints - a list of constraints associated with the stereotype. • Description - an informal description with possible explanatory comments. The columns of the tag specification table are defined as follows: • Tag - the name of the tag. • Stereotype - the name of the stereotype that owns this tag, or “N/A” if it is a stand alone tag. • Type - the name of the type of the values that can be associated with the tag. • Multiplicity - the maximum number of values that may be associated with one tag instance. • Description - an informal description with possible explanatory comments. In the case of both the stereotype specification table and the tag specification table, columns that are not applicable may be omitted. In the example stereotype specification table of Figure 3-34, two related stereotypes are defined. The first row declares the stereotype ArchitecturalElement, which is a stereotype of GeneralizableElement, while the second row declares the stereotype Capsule, which is a specialization of the ArchitecturalElement stereotype, but which applies only to instances of Class, which is a subclass of GeneralizableElement in the metamodel. The equivalent declaration as the one table in Figure 3-34, less the constraints and the informal descriptions, is shown graphically in Figure 3-35. Figure 3-35 Graphical equivalent of the stereotype declarations shown in Figure 3-34 GeneralizeableElement <> Classifier <> Class <> A rc hitecturalE lem ent <> Capsule <> <> <> March 2003 OMG-Unified Modeling Language, v1.5 3-61 3 UML Notation Guide 3.35.3 Mapping A classifier with a stereotype «metaclass» maps into a UML metaelement and a classifier with a stereotype «stereotype» maps into a Stereotype. The «stereotype» dependency maps to the baseClass attribute definition of the stereotype. The constraints listed in the Constraints compartment map to stereotype constraints and the items in the Tags compartment map to the defined tags of the stereotype. Each item in the Tags list maps to a TagDefinition. The string before the colon separator maps to the name of the tag definition while the string following the colon maps to an instance of Name. If a multiplicity specification is included in the item, it maps to the multiplicity attribute of the tag definition. 3.36 Powertype 3.36.1 Semantics A Powertype is a user-defined metaelement whose instances are classes in the model. 3.36.2 Notation A Powertype is shown using the Classifier notation (a rectangle) with the stereotype keyword «powertype». The name of the Powertype is placed in the upper compartment. Because the elements are ordinary classes, attributes and operations on the powertype are usually no