MASTER UML 2.0 Superstructure

ad/2002-09-02
Date: 9 September 2002
Revised submission to OMG RFP ad/00-09-02:
Unified Modeling Language: Superstructure

version 2 beta R1 (draft)
Submitters:
Alcatel, Computer Associates, Enea Business Software, Ericsson, Fujitsu, Hewlett-Packard, I-Logix,
International Business Machines, IONA, Kabira Technologies, Motorola, Oracle, Rational Software,
SOFTEAM, Telelogic, Unisys, and WebGain
Supporters:
Advanced Concepts Center LLC, Ceira Technologies, Commissariat L'Energie Atomique, Compuware,
DaimlerChrysler, Embarcadero Technologies, France Telecom, Fraunhofer FOKUS, Gentleware, Intellicorp, Jaczone, Kennedy Carter, KLOCwork, Lockheed Martin, Mercury Computer, MSC.Software,
Northeastern University, Popkin Software, Proforma, Sims Associates, Syntropy Ltd., Thales Group,
University of Kaiserslautern, VERIMAG, and 88solutions
Copyright 2001-2002 U2 Partners (www.u2-partners.org).

NOTICES
Since this document is a proposal to revise the OMG Unified Modeling Specification, some of its content is adapted
from the OMG Unified Modeling Language Specification v. 1.4, which contains the following copyright: 19972001 Object Management Group.
The information contained in this document is subject to change without notice.
The material in this document details a proposed specification by a consortium of vendors and users. This document
does not represent a commitment to implement any portion of this specification in any companies' products.
TRADEMARKS
OMG, OBJECT MANAGEMENT GROUP, CORBA, CORBA ACADEMY, CORBA ACADEMY & DESIGN, THE
INFORMATION BROKERAGE, OBJECT REQUEST BROKER, OMG IDL, CORBAFACILITIES, CORBASERVICES, CORBANET, CORBAMED, CORBADOMAINS, GIOP, IIOP, OMA, CORBA THE GEEK, MODEL
DRIVEN ARCHITECTURE, UNIFIED MODELING LANGUAGE, UML, and UML CUBE LOGO are registered
trademarks or trademarks of the Object Management Group, Inc.
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Submission summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Resolution of RFP requirements . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Responses to RFP issues to be discussed . . . . . . . . . . . . . . . . . . . . x
Optional versus mandatory interfaces . . . . . . . . . . . . . . . . . . . . . . x
Proposed compliance points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Changes to Adopted OMG Specifications . . . . . . . . . . . . . . . . . . . xii
How to Read this Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Part I. UML::Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Foundation::Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
The Root diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
The Namespaces diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
The Expressions diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
The Multiplicities diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
The Classifiers diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
The Features diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
The Classes diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
The Associations diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
The DataTypes diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
The Instances diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
The Packages diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Chapter 2. Foundation::PrimitiveTypes . . . . . . . . . . . . . . . . . . . . . . 83
PrimitiveTypes package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Chapter 3. Foundation::Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Profiles package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Part II. UML::Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 4. Basic::Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Chapter 5. Basic::Common Behaviors . . . . . . . . . . . . . . . . . . . . . . . 103
Class Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Chapter 6. Basic::Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Chapter 7. Basic::Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Chapter 8. Basic::Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Semantic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Chapter 9. Basic::InternalStructures . . . . . . . . . . . . . . . . . . . . . . . . 155
Chapter 10. Basic::UseCases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
TOC.fm Version 2 beta R1
September 9, 2002 11:32 am
Part III. UML::Common . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Chapter 11. Common::Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Chapter 12. Common::Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Chapter 13. Common::Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Chapter 14. Common::Collaborations . . . . . . . . . . . . . . . . . . . . . . . 301
Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Chapter 15. Common::CommonBehaviors. . . . . . . . . . . . . . . . . . . . 311
Class Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Chapter 16. Common::Components . . . . . . . . . . . . . . . . . . . . . . . . . 321
Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Chapter 17. Common::Deployments . . . . . . . . . . . . . . . . . . . . . . . . . 333
Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Chapter 18. Common::Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Chapter 19. Common::StateMachines. . . . . . . . . . . . . . . . . . . . . . . . 355
Part IV. UML::Complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Chapter 20. Complete::Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Chapter 21. Complete::Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Chapter 22. Complete::Associations . . . . . . . . . . . . . . . . . . . . . . . . . 459
Chapter 23. Complete::ComponentDeployments. . . . . . . . . . . . . . . 465
Chapter 24. Complete::Generalizations . . . . . . . . . . . . . . . . . . . . . . 471
Chapter 25. Complete::InformationFlows . . . . . . . . . . . . . . . . . . . . 485
Chapter 26. Complete::Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Chapter 27. Complete::ProtocolStateMachines . . . . . . . . . . . . . . . . 495
Chapter 28. Complete::Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Chapter 29. Complete::Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Part V. Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
ii
Chapter 30. Activity Diagrams - Common . . . . . . . . . . . . . . . . . . . . 527

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
Other Graphical Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Chapter 31. Activity Diagrams - Complete . . . . . . . . . . . . . . . . . . . . 535
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Other Graphical Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Chapter 32. Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Chapter 33. Component Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Chapter 34. Component Deployment Diagrams. . . . . . . . . . . . . . . . 553
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Chapter 35. Deployment Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Chapter 36. Interaction Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Communication Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Interaction Overview Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Timing Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Chapter 37. Internal Structure Diagrams . . . . . . . . . . . . . . . . . . . . . 579
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
iii
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579

Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Chapter 38. Package Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Chapter 39. Protocol State Machine Diagrams . . . . . . . . . . . . . . . . 587
Graphic Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Chapter 40. State Machine Diagrams . . . . . . . . . . . . . . . . . . . . . . . . 589
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Chapter 41. Use Case Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Appendix A: Standard Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Common . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Complete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Appendix B: Component Profile Examples . . . . . . . . . . . . . . . . . . 603
J2EE/EJB Component Profile Examples . . . . . . . . . . . . . . . . . . . . 603
.NET/COM Component Profile Examples. . . . . . . . . . . . . . . . . . . 603
Appendix C: Tabular Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Tabular Notation for Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Tabular Notation for State Machines . . . . . . . . . . . . . . . . . . . . . . . 607
Appendix D: XMI Serialization and Schema . . . . . . . . . . . . . . . . . 609
Appendix E: Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Notation Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Glossary Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
iv
0.1 Submission summary
Preface
This UML 2.0: Superstructure is the second of two complementary specifications that propose a major revision to the
Object Management Groups Unified Modeling Language (UML), for which the most current version is UML v1.4.
The first specification proposal, which serves as the architectural foundation for this proposal, is the UML 2.0: Infrastructure.
This UML 2.0: Superstructure defines the user level constructs required for UML 2.0 in response to the UML 2.0
Superstructure RFP (OMGs RFP ad/00-09-02). It is complemented by UML 2.0: Infrastructure which defines the
foundational language constructs required for UML 2.0 in response to the UML 2.0 Infrastructure RFP (OMGs RFP
ad/00-09-01). The two complementary specifications proposals cross-reference each other extensively and together
constitute a complete proposal for the UML 2.0 modeling language.
This Preface provides background information about this proposal, including the information suggested in Section 4.9.2 of the RFP in Part I and III of the Suggested Outline. The main body of this document (Parts I-V) describes
the technical content of the proposal.
0.1. Submission summary

Copyright waiver
This document may be freely copied by the OMG or by any member of the OMG, but any excerpts from this document should be properly attributed to it.
Submission contact points
The following persons may be contacted for information regarding this submission:
Cris Kobryn (Cris.Kobryn@telelogic.com)
Guus Ramackers (Guus.Ramackers@oracle.com)
Bran Selic (bselic@rational.com)
A complete list of U2 Partner representatives for each company that is submitting or supporting this proposal is
available on the Partners page of the U2 Partners web (www.u2-partners.org). In addition, the following mailing list
is available for distributing and requesting information: u2p-info@yahoogroups.com.
Guide to material in the submission
An overview of the technical content of this proposal is described in Part I, Introduction of the UML 2.0: Infrastructure.
Overall design rationale
The design rationales for the language architecture and the specification approach used by this proposal are provided
in Chapter 1, Language Architecture and Chapter 2, Language Formalism of the UML 2.0: Infrastructure,
respectively.
Statement of proof of concept
This proposed specification has completed the design phase and is in the process of being prototyped by more than
one of the Submitters. As a further indication of the technical viability of this proposal, all submitters to the Meta
Object Facility 2.0 Core RFP (OMG RFP ad/01-11-14).based their initial submissions on an earlier version of the
Infrastructure Library proposed in this UML 2.0: Infrastructure part of this submission.
Preface.fm Version 2 beta R1
0.2 Resolution of RFP requirements
Issues
This proposed specification draft is a work in progress, and the U2 Partners plan at least one more revision of this
specification draft (which the OMG schedule calls the second revision) before it is completed. Consequently, this
specification draft is expected to contain numerous errors, inconsistencies and unresolved issues. The top level issues
that are currently being resolved by the U2 Partners are summarized on the Issues page (www.u2-partners.org/
issues.htm) of the U2 Partners web (www.u2-partners.org). In addition, the following mailing list is available for
readers who want to report or discuss issues: u2p-issues@yahoogroups.com.
0.2. Resolution of RFP requirements

The following tables summarize how this proposal satisfies the mandatory and option requirements of the UML 2.0
Superstructure RFP ( ad/00-09-02):
Table 1: Superstructure RFP Mandatory Requirements
MANDATORY REQUIREMENT
RESOLUTION
6.5.1 a: Proposals shall enforce a clear

separation of concerns between the specification of the metamodel semantics and
notation, including precise bi-directional
mappings between them.
The proposed specification defines the semantics and notation for

each language construct, so that there is a straightforward and precise mapping between the concrete syntax (notation) and the semantics.
6.5.1 b: Proposals shall minimize the

impact on users of the current UML 1.x,
XMI 1.x and MOF 1.x specifications, and
will provide a precise mapping between
the current UML 1.x and the UML 2.0
metamodels. Proposals shall ensure that
there is a well-defined upgrade path from
the XMI DTD for UML 1.x to the XMI
DTD for UML 2.0. Wherever changes
have adversely impacted backward compatibility with previous specifications,
submissions shall provide rationales and
change summaries along with their precise mappings.
The proposed speficication defines precise mappings between UML

1.x and UML 2.0 metamodel constructs in the Changes from UML
1.4 section for each construct and package. The upgrade path
between the UML 1.x DTD and the UML 2.0 XMI Schema is
described in Appendix D, XMI Serialization and Schema.
6.5.1 c: Proposals shall identify language

elements to be retired from the language
for reasons such as being vague, gratuitous, too specific, or not used.
UML language constructs recommended for retirement will be

addressed in a future version of this specification proposal.
6.5.1 d: Proposals shall specify an XMI

DTD for the UML metamodel.
The specification of a UML 2.0 XMI Schema for this proposal is

described in Appendix D, XMI Serialization and Schema.
vi
6.5.2.1: Component-Based Development
Proposals shall support component

assembly and plug-substitutability by providing for the specification of both what a
component makes available to other components and its connection requirements
(e.g., which operations and signals it will
require from its connected components).
RESOLUTION
The requirements for component-based development are addressed
in Chapter 16, Common::Components, Chapter 23, Complete::ComponentDeployments. The modeling of specific component execution contexts, J2EE/EJB and .NET/COM are addressed in
Chapter B, Component Profile Examples.
Proposals shall support the specification of common interaction patterns that

might occur between two or more components as reusable and generalizable modeling elements.
Proposals shall support modeling of
component execution contexts (e.g., EJB
and CCM containers), and communication between an execution context and the
components that it contains.
Proposals shall enable definition of
profiles for models based on, at least, the
following component architectures: EJB,
CORBA components, and COM+.
6.5.2.2 Run-Time Architectures:
Proposals shall support the modeling
of the internal structureof a classifier in
terms of its hierarchical decomposition.
The internal structure shall be allowed to
contain instances of classifiers and links
between these instances, without affecting
the usage of these classifiers elsewhere.
The connections between instances shall,
at a minimum, specify possible communication.
The modeling of the internal structure of classifiers is addressed in

Chapter 9, Basic::InternalStructures and Chapter 18, Common::Ports.
The specification of the dynamic behavior of the internal structure of
classifiers is addressed in Chapter 19, Common::StateMachines.
Proposals shall support the specification of the dynamic behavior of the internal structure of a classifier, including its
connection to the statemachine of the
classifier, if any, its initial instantiation, as
well as the dynamic addition and removal
of parts and connections to/from the internal structure.
vii
6.5.3 Relationships:
Proposals shall specify how the features and behavior of all generalizable
model elements are affected by specialization. They shall also address the
replacement of features and behavior that
are specialized from an ancestor.
RESOLUTION
The requirements for relationships are addressed in the following
Chapter 1, Foundation::Kernel, Chapter 6, Basic::Dependencies, and Chapter 24, Complete::Generalizations.
Proposals shall specify what refine

and trace mean and provide usage
guidelines.
Proposals shall specify the scope that
is covered by an association. It shall be
possible that associations or initial
attribute values specified within a scope
are valid only within the context of that
scope. In particular, proposals shall clarify
the semantics of composite aggregation
with respect to scope.
6.5.4.1 State Machines:
Proposals shall provide for an encapsulation mechanism for states and state
machines, so that the internal details of a
composite state can be defined independently of its use in the enclosing state.
Proposals shall support reuse of behavioral specifications across multiple
classes.
The requirements for state machines are addressed in the following

chapter: Chapter 19, Common::StateMachines.
The requirements for prorocol state machines are addressed in the
following chapter: Chapter 27, Complete::ProtocolStateMachines.
Proposals shall clarify the semantics

of protocol state machines.
Proposals shall clarify the application
of state machines to Behavioral Features
and to Classifiers other than Classes.
Proposals shall specify how StateMachines can be specialized.
6.5.4.2 Activity Graphs:
Proposals shall provide for improved
control and data flow modeling in activity
graphs. For example, more permissive
concurrency or separate semantics for
control and data flow.
The requirements for activity graphs are addressed in the following

chapters: Chapter 12, Common::Activities and Chapter 21, Complete::Activities.
Proposals shall improve the management of events in activity graphs. Examples are keeping and referring to event
history or Boolean combination of events
in triggers.
viii
6.5.4.3 Interactions:
Proposals shall define mechanisms to
describe the decomposition of a role in an
interaction into an interaction of its constituent parts.
RESOLUTION
The requirements for interactions are addressed in the following
chapter: Chapter 8, Basic::Interactions.
Proposals shall provide mechanisms

to refer from one interaction to other
interactions to support composition of
interactions. It shall be possible to define,
at least, sequences of interactions, alternative interactions based on conditions, parallel execution of interactions, and
repetition of an interaction.
Table 2: Superstructure RFP Optional Requirements
OPTIONAL REQUIREMENTS
6.6.2 Structural Modeling:
Proposals may provide for data flow
modeling at a high level of abstraction.
For example, it may be possible to show
data or object flow between packages and
classifiers.
6.6.4 Behavioral Modeling:
RESOLUTION
The requirements for data flow modeling are addressed in the following chapter: Chapter 25, Complete::InformationFlows.
To be addressed in a future version of this proposal.
Proposals may support the grouping

of states into possibly overlapping sets of
states, such that it is possible to share
behavior across such sets.
Proposals may support specification
of the particular events that an instance
can receive and from which objects it can
receive them.
Proposals may provide for the capability to establish the target object of a
communication by various means with
differing levels of coupling between the
communicating objects.
ix
0.3 Responses to RFP issues to be discussed
Table 2: Superstructure RFP Optional Requirements
OPTIONAL REQUIREMENTS
6.6.5 Notation:
Proposals may review and improve
the consistency of how symbols and icons
are used in the various kinds of diagrams.
RESOLUTION
The notation for individual constructs is addressed along with their
abstract syntax, well-formedness and semantics. Diagram types are
described in Part IV, Diagrams.
Proposals may provide an improved

notation for defining patterns.
Proposals may define notation for
applying constraints on the instantiation of
templates (e.g., constraints on template
parameters that are checked at instantiation time).
6.6.6 Other:
Proposals may consider semantic
alignment with other specification language standards, such as ISO EXPRESS,
ITU-T SDL/MSC, ISO GRM, or ITU-T
RM-ODP.
The revisions to Classes with internal structure and Interactions

have been semantically aligned with ITU-T SDL and MSC, respectively. In addition, an effort has been made to ensure that constructs
that can modeled with ISO EXPRESS, can also be modeled with
this proposal.
0.3. Responses to RFP issues to be discussed

To be addressed in a future version of this proposal.
0.4. Optional versus mandatory interfaces

Since this is a modeling specification rather than a CORBA specification, the traditional subject of optional versus
mandatory interfaces is not applicable. However, the matter of XMI schema generation is relevant and is addressed in
Appendix D, XMI Serialization and Schema.
0.5. Proposed compliance points

The basic units of compliance for UML are the packages which define the UML metamodel. Unless otherwise
qualified, complying with a package requires complying with its abstract syntax, well-formedness rules, semantics, notation and XMI schema.
In the case of the UML Superstructure, the metamodel The is organized into medium-grain packages (compare
the InfrastructureLibrarys fine-grained packages) that support flexible compliance points. All UML 2.0 compliant
implementations are required to implement the UML::Foundation::Kernel and UML::Foundation::PrimitiveTypes
package. All other UML Superstructure packages are optional compliance points.
0.5 Proposed compliance points
Summary of Compliance Points

Table 0-1
Compliance Point
Valid Options
Foundation::Kernel
required; must be implemented to be compliant
Foundation::Primitives
required; must be implemented to be compliant
Foundation::Profiles
no/incomplete, complete, complete XMI schema
Basic::Actions
Basic::
CommonBehaviors
Basic::Dependencies
Basic::Interfaces
Basic::Interactions
Basic::InternalStructures
Basic::UseCases
Common::Actions
Common::Activities
Common::Classes
Common::Collaborations
Common::
CommonBehaviors
Common::Components
Common::Deployments
Common::Ports
Common::StateMachines
Complete::Actions
Complete::Activities
Complete::Associations
Complete::
ComponentDeployments
Complete::
Generalizations
Complete::
InformationFlows
Complete::Models
xi
0.6 Changes to Adopted OMG Specifications
Table 0-1
Compliance Point
Valid Options
Complete::
ProtocolStateMachines
Complete::
Subsystems
Complete::
Templates
0.6. Changes to Adopted OMG Specifications

The proposed specification, in conjunction with the specification proposal that complements this, the UML 2.0:
Superstructure are recommended to completely replace the current version of UML 1.x, except for Model Interchange Using CORBA IDL (see Chapter 5, Section 5.3 of the OMG UML Specification v1.4 and ad/01-02-17. It is
recommended that Model Interchange Using CORBA IDL is retired as an adopted technology because of lack of
vendor and user interest.
0.7. How to Read this Specification

The rest of this document contains the technical content of this proposal. As background for this specification, readers
are encouraged to first read the UML: Infrastructure proposal that complements this. Part I, Introduction of UML:
Infrastructure explains the language architecture structure and the formal approach used for its specification. Afterwards the reader may choose to either explore the InfrastructureLibrary, described in Part II, Infrastructure Library,
or the UML Foundation package which reuses it, described in Part I, UML::Foundation. The former specifies the
flexible metamodel library that is reused by the latter; the latter defines the basic constructs used to define the UML
metamodel.
With that background the reader should be well preparted to explore the user level constructs defined in this
UML: Superstructure proposal. These concepts are organized into three peer packages of UML::Foundation, which
correspond to three additional compliance levels: Basic (Level 1); Common (Level 2) and Complete (Level 3). These
abstract syntax, well-formedness rules, semantics and notations for each of these packages is specified in Part I,
UML::Basic, Part II, UML::Common and Part III, UML::Complete, respectively. Alternatively, the reader may
choose to explore the user level constructs as they are organized by diagrams in Part IV, Diagrams.
Although the chapters are organized in a logical manner and can be read sequentially, this is a reference specification is intended to be read in a non-sequential manner. Consequently, extensive cross-references are provided to
facilitate browsing and search.
0.8. Acknowledgements
The following persons were members of the core team that designed and wrote this specification: Don Baisley, Morgan Bjrkander, Conrad Bock, Steve Cook, Philippe Desfray, Nathan Dykman, Anders Ek, David Frankel, Eran Gery,
ystein Haugen, Sridhar Iyengar, Cris Kobryn, Birger Mller-Pedersen, James Odell, Gunnar vergaard, Karin
Palmkvist, Guus Ramackers, Jim Rumbaugh, Bran Selic, Thomas Weigert and Larry Williams.
xii
0.8 Acknowledgements
In addition, the following persons contributed valuable ideas and feedback that significantly improved the content and the quality of this specification: Colin Atkinson, Ken Baclawski, Mariano Belaunde, Steve Brodsky, Bruce
Douglass, Sbastien Gerard, Mario Jeckle, Larry Johnson, Allan Kennedy, Mitch Kokar, Thomas Kuehne, Michael
Latta, Dave Mellor, Jeff Mischkinksky, Hiroshi Miyazaki, Jishnu Mukerji, Ileana Ober, Barbara Price, Tom Rutt,
Oliver Sims, Cameron Skinner, Jeff Smith, Doug Tolbert, and Ian Wilkie.
xiii
0.8 Acknowledgements
xiv
Part I. UML::Foundation
This part describes the structure and contents of the UML::Foundation packages. The package Foundation is one of
the cornerstones of the UML specification, and other packages in UML build on this package. The Foundation is an
intrinsic part of the UML specification, and reuses the packages defined in the InfrastructureLibrary. How those
packages are reused is specified in detail in subsequent chapters.
Foundation
PrimitiveTypes
import
Kernel
import
Profiles
Figure 1-1. The Foundation package is owned by the UML package, and contains the packages Kernel,
PrimitiveTypes, and Profiles.
The Foundation has a structure that is similar to both the one used in package InfrastructureLibrary and the one
used in UML 1.x. This is to allow easy comparisons between the metamodels, and also to make it easier to verify that
backward compatibility issues are met.
The packages PrimitiveTypes and Profiles of the InfrastructureLibrary are directly reused through simple
imports from their Foundation counterparts. As is described in subsequent chapters, the situation is slightly more
complex when it comes to the package Kernel, which imports the (subpackages of the) packages Abstractions and
Constructs. Rather than containing a number of fine-grained packages intended for flexible reuse in different dimensions, the Kernel is a flat structure that contains all metaclasses from the Abstractions and Constructs packages. However, the Kernel package also adds additional features to some of those metaclasses, and also adds some additional
metaclasses that are specific to UML.
The other top-level packages in UML (Basic, Common, and Complete) and their subpackages are dependent on
the Foundation package, in particular its Kernel subpackage.
Part-Foundation.fm Version 2 beta R1
UML::Foundation
Part-Foundation.fm Version 2 beta R1
1 Foundation::Kernel
Chapter 1. Foundation::Kernel
The Kernel package is the central part of the UML::Foundation, and primarily reuses the Abstractions and Constructs
packages of the InfrastructureLibrary. .
Foundation
PrimitiveTypes
Kernel
Profiles
Figure 1-2. The Kernel package is owned by the Foundation package.

The reuse is accomplished by extending the relevant subpackages of Abstractions and Constructs. In many cases,
the reused classes are extended in the UML::Foundation with additional features, associations, or superclasses. In
subsequent diagrams showing abstract syntax, the subclassing of elements from the infrastructure library is always
elided since this information only adds to the complexity without increasing understandability. Each metaclass is
completely described as part of this chapter; the text from the infrastructure library is repeated here, but is specially
marked in blue font and change bars to facilitate easy identification of added parts.
It should also be noted that while both Abstractions and Constructs contained several subpackages, Kernel is a
flat structure that only contains metaclasses. The reason for this distinction is that the infrastructure library has been
designed for flexibility and reuse, while the Kernel in reusing the infrastructure library has to bring together the different aspects of the reused metaclasses. In order to organize this chapter, we therefore use diagrams rather than packages as the grouping mechanism.
The packages that are explicitly extended from the InfrastructureLibrary::Core are the following:
Abstractions::Instances
Constructs::PackageExtensions
Constructs::Aggregations
Constructs::Navigations
Constructs::Classes
Constructs::DataTypes
All other packages of the InfrastructureLibrary::Core are extended through the ones that are explicitly extended.
Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am
1.1 The Root diagram
1.1. The Root diagram
+owner
Element
0.. 1
+ownedElement
*
0..1
*
NamedElement
+ name : String [0..1]
+ visibility : VisibilityKind [0..1]
+ / qualifiedName : St ring [0..1]
Relationship
+ownedComment
[ownedElement]
Comment
+ body : String
*
*
<<enumeration>>
VisibilityKind
public
private
protected
package
DirectedRelationship
+relatedElement
1.. *
+target
+source
[relatedElement] 1..* [relatedElement]
1..*
+annotatedElement
Element
Figure 1-3. The Root diagram of the Kernel package.
Comment
A comment is a textual annotation that can be attached to one or more elements.
Description
A comment gives the ability to attach various remarks to elements. A comment carries no semantic force, but may
contain information that is useful to a modeler.
Comment is is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Comments::Comment.
Attributes
body: String
Specifies a string that is the comment.
Associations
annotatedElement: Element
References the Element(s) being commented
Constraints
No additional constraints.
Semantics
A Comment adds no semantics to the annotated elements, but may represent information useful to the reader of the
model.
Notation
A Comment is shown as a rectangle with a bent corner in the upper right corner. The rectangle contains the body of
the Comment. The connection to each annotated element is shown by a separate dashed line.
Examples
This class was added

by Alan Wright after
meeting with the
mission planning team.
Account
Figure 1-4. Comment notation.
A directed relationship represents a relationship between a collection of source model elements and a collection of
target model elements.
Description
A directed relationship references one or more source elements and one or more target elements. Directed relationship is an abstract class.
DirectedRelationship is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Relationships::DirectedRelationship.
Attributes
No additional attributes.
Associations
source: Element [1..*]
Specifies the sources of the DirectedRelationship.
target: Element [1..*]
Specifies the targets of the DirectedRelationship.
Constraints
Semantics
DirectedRelationship has no specific semantics. The various subclasses of DirectedRelationship will add semantics
appropriate to the concept they represent.
Element
Notation
There is no general notation for a DirectedRelationship. The specific subclasses of Relationship will define their own
notation. In most cases the notation is a variation on a line drawn from the source(s) to the target(s).
Element
An element is a constituent of a model.
Description
Element is an abstract class with no superclass. Element has an abstract composition association to itself to support
the general capability for elements to own other elements.
An element can own comments.
Element is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Elements::Element and InfrastructureLibrary::Core::Abstractions::Comments::Element.
Attributes
Associations
ownedElement: Element
The Elements owned by this element. This is an abstract association.
owner: Element [0..1]
The Element that owns this element. This is an abstract association.
ownedComment: Comment
The Comments owned by this element. This is a specialization of the ownedElement association.
Constraints
[1] An element may not directly or indirectly own itself.
not self.allOwnedElements()->includes(self)
[2] Elements that must be owned must have an owner.

self.mustBeOwned() implies self.owner->notEmpty()
Additional Operations
[1] The query allOwnedElements() gives all of the direct and indirect owned elements of an element.
Element::allOwnedElements(): Set(Element);
allOwnedElements = self.ownedElements->union(self.ownedElements->collect(e | e.allOwnedElements()))
[2] The query mustBeOwned() indicates whether elements of this type must have an owner. Subclasses of Element
that do not require an owner must override this operation.
Element::mustBeOwned() : Boolean;
mustBeOwned = true
Semantics
Subclasses of Element will provide semantics appropriate to the concept they represent.
The abstract ownedElement association is specialized (directly or indirectly) by all composition associations in
the metamodel. Thus ownedElement provides a convenient way to access all the elements that are directly owned by
an Element.
The comments for an Element add no semantics but may represent information useful to the reader of the model.
NamedElement
Notation
There is no general notation for an Element. The specific subclasses of Element define their own notation.
NamedElement
See The Namespaces diagram on page 8.
Relationship
Relationship is an abstract concept that specifies some kind of relationship between elements.
Description
A relationship references one or more related elements. Relationship is an abstract class. The relationship may be
between the model elements themselves (such as a dependency between two packages) or a relationship between
the elements that are specified by the related model elements.
Relationship is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Elements::Relationship.
Attributes
Associations
relatedElement: Element [1..*] Specifies the elements related by the Relationship.
Constraints
Semantics
Relationship has no specific semantics. The various subclasses of Relationship will add semantics appropriate to the
concept they represent.
Notation
There is no general notation for a Relationship. The specific subclasses of Relationship will define their own notation.
In most cases the notation is a variation on a line drawn between the related elements.
VisibilityKind
1.2 The Namespaces diagram
1.2. The Namespaces diagram
NamedElement
name : Strin g [ 0.. 1]
vis ibi lit y : Vi sibil ityKi nd [ 0. .1]
/ q ualifiedNa me : String [ 0.. 1]
+outerElements
+ownedMember
[ownedE lement, member]
+member
/
+context
Constraint
0..1
+namespace
[owner]
0.. 1
<<enumeration>>
VisibilityKind
public
private
protected
package
Namespace
0.. 1
*
+constraint
[ownedMember]
[namespace, context]
0..1
Di rectedRelat ionship
+importedMember
[member]
Pack agingNamespace
AutonomousElement
* vis ibi lit y : Vi sibil ityKi nd

+ownedMember isExpan ded : Boo lean = fal se
[ ow nedM em ber]
0..1
*
1
+importingNamespace
[source, owner]
1
+impo rt ingNamespace
[sou rce, owner]
+importedElement
[target]
*
+elementImport
[ownedElement]
ElementImport
visibi lity : Vi sibil ityKind

ali as : St ring [0. .1]
*
+im port
[ ownedEl em ent]
1
+importedNamespace
[ target ]
1
Mem berImport
visibility : VisibilityKind
Figure 1-5. The Namespaces diagram of the Kernel package.
AutonomousElement
An autonomous element is an element that can be owned by a packaging namespace.
Description
AutonomousElement is a specialization of Element. AutonomousElement is abstract.
An autonomous elements may be expanded through the use of package extensions.
AutonomousElement is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::PackagingNamespaces::AutonomousElement and InfrastructureLibrary::Core::Constructs::PackageExtensions::AutonomousElement.
Attributes
isExpanded: Boolean
Indicates that an AutonomousElement is expanded based on a PackageExtension.

Expanded AutonomousElements need not be interchanged through XMI, but can
always be calculated from the set of packages and package extensions that are
interchanged. Expanded elements are used as ordinary elements, but must not
necessarily have an explicit repository representation. The default value is false.
visibility: VisibilityKind
Specifies the visibility of the AutonomousElement that determines whether it is

visible outside its PackagingNamespace.
Associations
No additional associations.
Constraint
Constraints
Semantics
No additional semantics.
Notation
The keyword {expanded} within curly brackets can be used after or below the name of an autonomous element to
indicate that it has been expanded, i.e., calculated from the applicable package extensions.
Style Guidelines
Expanded elements are normally not shown.
Examples
See PackageExtension on page 74.
Constraint
See The Expressions diagram on page 18.
ElementImport
An element import identifies an element in another packaging namespace, and allows the element to be referenced
using its name without a qualifier.
Description
An element import is defined as a directed relationship between an importing packaging namespace and an autonomous element in another packaging namespace that is to be added to the namespace of the importing packaging
namespace.
An element import can be used by packages, and has the capabilities to control the imported name through an
alias and to set the visibility of the imported element.
Element import is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Imports::ElementImport
and InfrastructureLibrary::Core::Constructs::Packages::ElementImport.
Attributes
alias: String [0..1]
Specifies the name that should be added to the namespace of the importing Package in lieu of the name of the imported AutonomousElement. The aliased name
must not clash with any other member name in the importing Package. By
default, no alias is used.
visibility: VisibilityKind [0..1] Specifies the visibility of the imported AutonomousElement within the importing
Package. The visibility of the ElementImport may be either the same or more
restricted than that of the imported element. The default visibility is the same as
that of the imported element. If the imported element does not have a visibility, it
is possible to add visibility to the element import.
ElementImport
Associations
importedElement: AutonomousElement [1]

Specifies the AutonomousElement that an importingNamespace imports. The
association is an abstract specialization of the target association from DirectedRelationship to Element.
importingNamespace: PackagingNamespace
Specifies the PackagingNamespace that imports an AutonomousElement from
another PackagingNamespace. The association is an abstract specialization of the
owner association from Element to Element, and of the source association from
DirectedRelationship to Element. Note that this association must be concretely
specialized from a (subclass of) PackagingNamespace in order for it to be able to
import AutonomousElements.
Constraints
[1] The visibility of an ElementImport is either public or private.
self.visibility = #public or self.visibility = #private
[2] An importedElement has either public visibility or no visibility at all.

self.importedElement.visibility.noEmpty() implies self.importedElement.visibility = #public
[3] The visibility of an ElementImport is not optional.

not self.visibility->isEmpty()
[1] The query getName() returns the name under which the imported AutonomousElement will be known in the
importing PackagingNamespace. This may be overridden to introduce aliasing.
ElementImport::getName(): String;
getName = importedElement.name
[2] The query getName() returns the name under which the imported AutonomousElement will be known in the
importing PackagingNamespace.
Package::getName() : String;
getName =
if self.alias->notEmpty() then
self.alias
else
importedElement.name
endif
Semantics
An element import adds the name of an autonomous element in another namespace to the importing namespace. It
works by reference, which means that it is not possible to add features to the element import itself, but it is possible to
modify the referenced element in the namespace from which it was imported. An element import is used to selectively import individual elements without relying on a member import.
In case of a nameclash with an outer name (an element that is defined in an enclosing namespace is available
using its unqualified name in enclosed namespaces) in the importing namespace, the outer name is hidden by an element import, and the unqualified name refers to the imported element. The outer name can be accessed using its qualified name.
If more than one element with the same name would be imported to a namespace as a consequence of element
imports or member imports, the names of the imported elements must be qualified in order to be used and the elements are not added to the importing namespace. If the name of an imported element is the same as the name of an
10
ElementImport
element owned by the importing namespace, the name of the imported element must be qualified in order to be used
and is not added to the importing namespace.
An imported element can be further imported by other namespaces using either element or member imports.
Notation
An element import is shown using a dashed arrow with an open arrowhead from the importing namespace to the
imported element. The keyword import is shown near the dashed arrow if the visibility is public, otherwise the keyword use is shown. If the imported element is a package, the keyword may optionally be preceded by element .
If an element import has an alias, this is used in lieu of the name of the imported element. The aliased name may
be shown after or below the keyword import.
Presentation Options
As an alternative to the dashed arrow, it is possible to show an element import by having a text that uniquely identifies the imported element within curly brackets either below or after the name of the namespace. The textual syntax is
then:
{element import <qualifiedName>} or {element use <qualifiedName>}
If the imported element should should have an alias, the textual syntax is:
{element import <qualifiedName> as <alias>} or {element use <qualifiedName> as <alias>}
Examples
Two examples of how to use element import are shown in Figure 1-6. From within the package Program, it is possible
to refer to a class in the package Types using its qualified name. By using an element import, it is possible to refer
directly to a class in another package using its name. In this case, both Time and Point can be used directly in the
package Program, but Type::Integer has to be qualified.
Types
Integer
Types
Time
import
Program
Point
Program
import
Figure 1-6. Examples of element import
11
MemberImport
Types
Shapes
dataType
Real
import
Double
Circle
radius : Double
Figure 1-7. Examples of element import with aliasing
MemberImport
A member import is a relationship that allows one packaging namespace to refer to elements of another packaging
namespace using unqualified names.
Description
A member import is defined as a directed relationship that identifies a packaging namespace whose members are to
be imported by an importing packaging namespace.
MemberImport is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Imports::ElementImport.
Attributes
visibility: VisibilityKind
Specifies the visibility of the imported AutonomousElements within the importing Namespace, i.e., whether imported elements will in turn be visible to other
namespaces that use that importingNamespace as an importedNamespace. If the
MemberImport is public, the imported elements will be visible outside the
Namespace, while if it is private they will not. By default, the value of visibility
is public.
Associations
importedNamespace: PackagingNamespace [1]

Specifies the PackagingNamespace whose members are imported to another
PackagingNamespace. The association is an abstract specialization of the target
association from DirectedRelationship to Element.
importingNamespace: PackagingNamespace [1]

Specifies the PackagingNamespace that imports the members of another PackagingNamespace. The association is an abstract specialization of the source association from DirectedRelationship to Element and of the owner association from
Element to Element.
Constraints
12
NamedElement
Semantics
A member import is a relationship between an importing namespace and an imported namespace, indicating that the
importing namespace adds the names of the members in the imported namespace to its own namespace. Conceptually, a member import is equivalent to having an element import to each individual member of the imported
namespace, unless there is already a separately-defined element import.
In case of a nameclash with an outer name (an element that is defined in an enclosing namespace is available
using its unqualified name in enclosed namespaces) in the importing namespace, the outer name is hidden by a member import, and the unqualified name refers to the imported element. The outer name can be accessed using its qualified name.
If more than one element with the same name would be imported to a namespace as a consequence of element
imports or member imports, the names of the imported elements must be qualified in order to be used and the elements are not added to the importing namespace. If the name of an imported element is the same as the name of an
element owned by the importing namespace, the name of the imported element must be qualified in order to be used
and is not added to the importing namespace.
An imported element can be further imported by other namespaces using either element or member imports.
Note that importing a package causes importing even of the unnamed members of that package.
Notation
A member import is shown using a dashed arrow with an open arrowhead from the importing namespace to the
imported namespace. The keyword import is shown near the dashed arrow.
NamedElement
A named element is an element in a model that may have a name.
Description
A named element represents elements that may have a name. The name is used for identification of the named element within the namespace in which it is defined. A named element also has a qualified name that allows it to be
unambiguously identified within a hierarchy of nested namespaces. Named element is an abstract superclass.
NamedElement has a visibility attribute.
NamedElement is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Namespaces::NamedElement and InfrastructureLibrary::Core::Abstractions::Visibilities::NamedElement.
Attributes
name: String [0..1]
The name of the NamedElement
/ qualifiedName: String [0..1] A name which allows the NamedElement to be identified within a hierarchy of
nested Namespaces. It is constructed from the names of the containing
namespaces starting at the root of the hierarchy and ending with the name of the
NamedElement itself. This is a derived attribute.
visibility: [0..1]
Determines the visibility of the NamedElement within different Namespaces

within the overall model.
Associations
namespace: Namespace [0..1] Specifies the namespace that owns the NamedElement. This abstract association
specializes the owner association from Element to Element.
13
Namespace
Constraints
[1] If there is no name, or one of the containing namespaces has no name, there is no qualified name.
self.name->isEmpty() or self.allNamespaces()->select(ns | ns.name->isEmpty())->notEmpty()
implies self.qualifiedName->isEmpty()
[2] When there is a name, the qualified name is constructed from the names of the containing namespaces.
self.name->notEmpty() implies
self.qualifiedName = self.allNamespaces()->iterate( ns : Namespace; result: String = self.name |
ns.name->union(self.separator())->union(result))
[3] If a NamedElement is not owned by a Namespace, it does not have a visibility.

self.namespace->isEmpty() implies self.visibility->isEmpty()
[1] The query allNamespaces() gives the sequence of namespaces in which the NamedElement is nested, working
outwards.
NamedElement::allNamespaces(): Sequence(Namespace);
allNamespaces =
if self.namespace->isEmpty()
then Sequence{}
else Sequence{}->append(self.namespace)->union(self.namespace.allNamespaces())
endif
[2] The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a
Namespace. By default, two named elements are distinguishable if (a) they have unrelated types or (b) they have
related types but different names.
NamedElement::isDistinguishableFrom(n:NamedElement, ns: Namespace): Boolean;
isDistinguishable =
if self.oclIsKindOf(n.oclType) or n.oclIsKindOf(self.oclType)
then ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty()
else true
endif
[3] The query separator() gives the string that is used to separate names when constructing a qualified name.
NamedElement::separator(): String;
separator = ::
Semantics
The name attribute is used for identification of the named element within namespaces where its name is accessible.
Note that the attribute has a multiplicity of [ 0..1 ] which provides for the possibility of the absence of a name (which
is different from the empty name).
The visibility attribute provides the means to specify the appearance of a named element in different namespaces
within a model. It is intended for use in conjunction with import and generalization mechanisms.
Namespace
A namespace is an element in a model that contains a set of named elements that can be identified by name.
Description
A namespace is a named element that can own other named elements. Each named element may be owned by at most
one namespace. A namespace provides a means for identifying named elements by name. named elements can be
identified by name in a namespace either by being directly owned by the namespace or by being introduced into the
namespace by other means e.g. importing or inheriting. namespace is an abstract metaclass.
14
Namespace
A namespace can own constraints. The constraint does not necessarily apply to the namespace itself, but may
also apply elements in the namespace.
Namespace is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Namespaces::Namespace and
InfrastructureLibrary::Core::Abstractions::Visibilities::Namespace.
Attributes
Associations
member: NamedElement [0..*] A collection of NamedElements identifiable within the Namespace, either by
being owned or by being introduced by importing or inheritance. This association
is abstract.
ownedMember: NamedElement [0..*]A collection of NamedElements owned by the Namespace. This abstract
association is a specialization of the ownedElement association from Element to
Element, and a specialization of the member association from Namespace to
NamedElement.
constraint: Constraint
The Constraints owned by this Namespace. The association is a concrete specialization of the ownedMember association from Namespace to NamedElement.
Constraints
[1] All the members of a Namespace are distinguishable within it.
membersAreDistinguishable()
[1] The query getNamesOfMember() gives a set of all of the names that a member would have in a Namespace. In
general a member can have multiple names in a Namespace if it is imported more than once with different
aliases. Those semantics are specified by overriding the getNamesOfMember operation. The specification here
simply returns a set containing a single name, or the empty set if no name.
Namespace::getNamesOfMember(element: NamedElement): Set(String);
getNamesOfMember =
if member->includes(element) then Set{}->include(element.name) else Set{} endif
[2] The Boolean query membersAreDistinguishable() determines whether all of the namespaces members are distinguishable within it.
Namespace::membersAreDistinguishable() : Boolean;
membersAreDistinguishable =
self.member->forAll( memb |
self.member->excluding(memb)->forAll(other |
memb.isDistinguishableFrom(other, self)))
Semantics
A namespace provides a container for named elements. It provides a means for resolving composite names, such as
name1::name2::name3. The member association identifies all named elements in a namespace called N that can be
referred to by a composite name of the form N::<x>. Note that this is different from all of the names that can be
referred to unqualified within N, because that set also includes all unhidden members of enclosing namespaces.
Named elements may appear within a namespace according to rules that specify how one named element is distinguishable from another. The default rule is that two elements are distinguishable if they have unrelated types, or
related types but different names. This rule may be overridden for particular cases, such as operations which are distinguished by their signature.
15
PackagingNamespace
The constraints for a Namespace represent well formedness rules for the constrained elements. These constraints
are evaluated when determining if the model elements are well formed.
Notation
No additional notation. Concrete subclasses will define their own specific notation.
PackagingNamespace
A packaging namespace is a namespace that may only contain autonomous elements.
Description
A packaging namespace can own autonomous elements. Packaging namespace is an abstract metaclass.
A packaging namespace may import members, either through element imports or member imports, thereby making it possible to refer to members of other packages using unqualified names.
PackagingNamespace is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::PackagingNamespaces::PackagingNamespace and InfrastructureLibrary::Core::Abstractions::Imports::PackagingNamespace.
Attributes
Associations
ownedMember: AutonomousElement
Specifies the AutonomousElements that are owned by the PackagingNamespace.
The association is a specialization of the ownedMember association from
Namespace to NamedElement.
elementImport: ElementImport References the ElementImports that are owned by the PackagingNamespace. The
Element.
import: Import
/ importedMember: AutonomousElement
References the AutonomousElements that are members of the PackagingNamespace as a result of imports.
References the MemberImports that are owned by the PackagingNamespace. The

Element.
Constraints
[1] The importedMember association is derived from the element imports and the package imports.
self.importedMember->includesAll(self.importMembers(self.elementImport.importedElement.asSet()
->union(self.import.importedNamespace->collect(p | p.visibleMembers()))))
[1] The query visibleMembers() defines which members of a PackagingNamespace can be accessed outside it.
PackagingNamespace::visibleMembers() : Set(AutonomousElement);
visibleMembers = member->select( m | self.makesVisible(m))
[2] The query makesVisible() defines whether a PackagingNamespace makes an element visible outside itself. By
default this is true always - even if the element has no name.
PackagingNamespace::makesVisible(el: Namespaces::NamedElement) : Boolean;
16
VisibilityKind
pre: self.member->includes(el)
makesVisible = true
[3] The query getNamesOfMember() is overridden to take account of importing. It gives back the set of names that
an element would have in a PackagingNamespace, either because it is owned, or if not owned then imported individually, or if not imported individually then in a package.
PackagingNamespace::getNamesOfMember(element: NamedElement): Set(String);
getNamesOfMember =
if self.ownedMember->includes(element)
then Set{}->include(element.name)
else let elementImports : ElementImport = self.elementImport->select(ei | ei.importedElement = element) in
if elementImports->notEmpty()
then elementImports->collect(el | el.getName())
else
self.import->select(pi |
pi.importedNamespace.visibleMembers()->includes(element))->collect(pi |
pi.importedNamespace.getNamesOfMember(element))
endif
endif
[4] The query importMembers() defines which of a set of AutonomousElements are actually imported into the
namespace. This excludes hidden ones, i.e., those which have names that conflict with names of owned members, and also excludes elements which would have the same name when imported.
PackagingNamespace::importMembers(imps: Set(AutonomousElement)) : Set(AutonomousElement);
importMembers = self.excludeCollisions(imps)->select( imp | self.ownedMember->forAll(mem |
imp.isDistinguishableFrom(mem, self)))
[5] The query excludeCollisions() excludes from a set of AutonomousElements any that would not be distinguishable from each other in this namespace
PackageingNamespace::excludeCollisions(imps: Set(AutonomousElement) : Set(AutonomousElement);
excludeCollisions = imps->reject( imp1 | imps->exists( imp2 | not imp1.isDistinguishableFrom(imp2, self)))
Semantics
The purpose of a packaging namespace is to provide an owning namespace for autonomous elements.
Notation
No additional notation. Specific subclasses define their own notation.
VisibilityKind
VisibilityKind is an enumeration type.
Description
VisibilityKind is an enumeration of the following literal values:
public
private
protected
package
[1] The query bestVisibility() examines a set of VisibilityKinds that includes only public and private, and returns
public as the preferred visibility.
VisibilityKind::bestVisibility(vis: Set(VisibilityKind)) : VisibilityKind;
17
1.3 The Expressions diagram
pre: not vis->includes(#protected) and not vis->includes(#package)

bestVisibility = if vis->includes(#public) then #public else #private endif
Semantics
VisibilityKind is intended for use in the specification of visibility in conjunction with, for example, the Imports, Generalizations and Packages packages. Detailed semantics are specified with those mechanisms. If the Visibility package is used without those packages, these literals will have different meanings, or no meanings.
A public element is visible to all elements that can access the contents of the namespace that owns it.
A private element is only visible inside the namespace that owns it.
A protected element is visible to elements that have a generalization relationship to the namespace that owns it.
A package element is owned by a namespace that is not a package, and is visible to elements that are in the same
package as its owning namespace.
In circumstances where a named element ends up with multiple visibilities, for example by being imported multiple
times, public visibility overrides private visibility.
1.3. The Expressions diagram
Element
Multiplicity
+specification
[ownedElement]
ValueSpecification
+multiplicity
0..1
AutonomousElement
0..1
Constraint
0..1
+context
+constrai nt
[ownedMember]
[ nam espace, co ntext]
LiteralInteger
0.. 1
LiteralSpecification
Expression
+constrainedElement
+ body : String [0..1]

+ lang uage : String [0..1]
+ value : Integer
Namespace
0..1
LiteralString
+ value : Strin g
LiteralBoolean
El em ent
{ordered}
LiteralNull
+ value : Boolean
Figure 1-8. The Expressions diagram of the Kernel package.
Constraint
A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the
purpose of declaring some of the semantics of a model element.
Description
Constraint contains a ValueSpecification that specifies additional semantics for one or more model elements. 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 using a specified language, whose syntax and interpretation is a tool responsibil-
18
Constraint
ity. One predefined language for writing constraints is OCL. In some situations, a programming language such as
Java may be appropriate for expressing a constraint. In other situations natural language may be used.
Constraint contains an optional name, although they are commonly unnamed.
Constraint is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Constraints::Constraint.
Attributes
Associations
constrainedElement: Element The Elements referenced by this Constraint. Note that the constrainedElement
collection is ordered.
context: Namespace [0..1]
specification: ValueSpecificationA condition that must be true when evaluated in order for the constraint to be
satisfied. The association is a specialization of the ownedElement association
from Element to Element.
References the Namespace that is the context for evaluating this constraint.
Constraints
[1] The value specification for a constraint must evaluate to a boolean value.
self.specification.isOclKindOf(Boolean)
[2] Evaluating the value specification for a constraint must not have side effects.
Cannot be expressed in OCL.
[3] A constraint cannot be applied to itself.

not self.constrainedElement->includes( self )
Semantics
A Constraint represents additional semantic information attached to the constrained elements. A constraint is an
assertion that indicates a restriction that must be satisfied by a correct design of the system. The constrained elements
are those elements required to evaluate the constraint expression. In addition, the context of the Constraint may be
accessed. For example, in OCL self is used to refer to the context element.
Constraints are expressed as a text string in some language. If a formal language such as OCL is used, then tools
may be able to verify some aspects of the constraints.
In general there are many possible owners for a Constraint. The only restriction is that the owning element must
have access to the constrainedElements.
The owner of the Constraint will determine when the constraint expression is evaluated. For example, this allows
an Operation to specify if a Constraint represents a precondition or a postcondition.
Notation
A Constraint is shown as a text string in braces ({}) according to the following BNF:
constraint ::= { [ <name> : ] <expression> }
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. Figure 1-9 shows a constraint string that follows an attribute within a class symbol.
For a Constraint that applies to a single element (such as a class or an association path), the constraint string may
be placed near the symbol for the element, preferably near the name, if any. A tool must make it possible to determine
the constrained element.
19
Constraint
For a Constraint that applies to two elements (such as two classes or two associations), the constraint may be
shown as a dashed line between the elements labeled by the constraint string (in braces). Figure 1-10 shows an {xor}
constraint between two associations.
The constraint string may be placed in a note symbol and attached to each of the symbols for the constrained elements
by a dashed line. Figure 1-11 shows an example of a constraint in a note symbol.
If the constraint is shown as a dashed line between two elements, then an arrowhead may be placed on one end.
The direction of the arrow is relevant information within the constraint. The element at the tail of the arrow is mapped
to the first position and the element at the head of the arrow is mapped to the second position in the constrainedElements collection.
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.
Examples
Stack
size: Integer {size >= 0}
push()
pop()
Figure 1-9. Constraint attached to an attribute.
Person
Account
{xor}
Corporation
Figure 1-10. {xor} constraint.
20
Expression
0..1
boss
employee
Person
employer
Company
0..1
{self.boss->isEmpty() or
self.employer = self.boss.employer
Figure 1-11. Constraint in a note symbol.
Expression
An expression is a textual statement that denotes a (possibly empty) set of values when evaluated in a context.
Description
An expression contains a language-specific text string used to describe a value or values, and an optional specification of the language.
One predefined language for specifying expressions is OCL. Natural language or programming languages may
also be used.
Expression is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Expressions::Expression.
Attributes
body: String [0..1]
The text of the expression.
language: String [0..1]
Specifies the language in which the expression is stated. The interpretation of the
expression body depends on the language. If language is unspecified, it might be
implicit from the expression body or the context.
Associations
Constraints
[1] Evaluation of an expression yields zero or more values.
These operations are not defined within the specification of UML. They should be defined within an implementation
that implements constraints so that constraints that use these operations can be evaluated.
[1] The query value() gives an integer value for an expression intended to produce one.
Expression::value(): Integer;
pre: self.isIntegral()
[2] The query isIntegral() tells whether an expression is intended to produce an integer.
21
LiteralBoolean
Expression::isIntegral(): Boolean;
[3] The query isPositive() tells whether an integer expression has a positive value.
Expression::isPositive(): Boolean;
[4] The query isNonNegative() tells whether an integer expression has a non-negative value.
Expression::isNonNegative(): Boolean;
Semantics
The interpretation of the expression body depends on the language. If the language is unspecified, it might be implicit
from the expression body or the context.
It is assumed that a linguistic analyzer for the specified language will evaluate the body.
Notation
An Expression is displayed as a text string in a particular language. The syntax of the string is the responsibility of a
tool and a linguistic analyzer for the language.
An Expression is displayed as a part of the notation for its containing element.
The language of an Expression, if specified, is often not shown on a diagram. Some modeling tools may impose
a particular language or assume a particular default language. The language is often implicit under the assumption
that the form of the expression makes its purpose clear. If the language name is shown, it should be displayed in
braces ({}) before the expression string.
Style Guidelines
A language name should be spelled and capitalized exactly as it appears in the document defining the language. For
example, use OCL, not ocl.
Examples
The following are three examples of expressions expressed in different languages:
a>0
{OCL} i > j and self.size > i
average hours worked per week
LiteralBoolean
A literal boolean is a specification of a boolean value.
Description
A literal boolean contains a Boolean-valued attribute.
LiteralBoolean is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Expressions::LiteralBoolean.
Attributes
value: Boolean
The specified Boolean value.
22
LiteralInteger
Associations
Constraints
Semantics
Notation
A LiteralBoolean is typically shown as either the word true or the word false, corresponding to its value. A
LiteralBoolean is often shown as part of a more complex specification string for another element.
LiteralInteger
A literal integer is a specification of an integer value.
Description
A literal integer contains an Integer-valued attribute.
LiteralInteger is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Expressions::LiteralInteger.
Attributes
value: Integer
The specified Integer value.
Associations
Constraints
Semantics
Notation
A LiteralInteger is typically shown as its integer value, often as part of a more complex specification string for
another element.
LiteralNull
A literal null specifies the lack of a value.
Description
A literal null is used to represent null, i.e., the absence of a value.
LiteralNull is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Expressions::LiteralNull.
23
Attributes
Associations
Constraints
Semantics
LiteralNull is intended to be used to explicitly model the lack of a value.
Notation
Notation for a LiteralNull varies depending on where it is used in the metamodel. It often appears as the word null.
Other notations are described for specific uses.
A literal specification identifies an actual value or values being modeled.
Description
A literal specification is an abstract specialization of ValueSpecification that identifies an actual value or values being
modeled.
LiteralSpecification is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Expressions::LiteralSpecification.
Attributes
Associations
Constraints
Semantics
No additional semantics. Subclasses of LiteralSpecification are defined to specify literal values of different types.
Notation
No specific notation.
LiteralString
A literal string is a specification of a string value.
24
Namespace
Description
A literal string contains a String-valued attribute.
LiteralString is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Expressions::LiteralString.
Attributes
value: String
The specified String value.
Associations
Constraints
Semantics
Notation
A LiteralString is typically shown as its string value, often as part of a more complex specification string for another
element.
Namespace
ValueSpecification
A value specification is the specification of a (possibly empty) set of instances, including both objects and data values.
Description
ValueSpecification is an abstract class used to identify a value or values in a model. It may reference an instance or it
may be an expression denoting an instance or instances when evaluated.
ValueSpecification is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Expressions::ValueSpecification.
Attributes
Associations
multiplicity: Multiplicity [0..1] Implies that the associated value specification represents a set of instances as
described by the value specification, compatible with this multiplicity. (Specializes Element.ownedElement) The InstanceSpecification represents a constraint
on the eventual instances.
25
ValueSpecification
Constraints
[1] The multiplicity associated with a value specification must only contain a single multiplicity range and its upper
and lower bound must be equal, i.e., the multiplicity must imply a specific value.
[2] The multiplicity must be consistent with the multplicities on any features specifying the instances represented by
the value specification.
Semantics
A value specification yields zero or more values. It is required that the type and number of values is suitable for the
context where the value specification is used.
A multiplicity associated with a value specification indicates that the the value specification will yield a set of
instances corresponding to the multiplicity, which must be a specific value. All instances in this set are described by
the associated value specification and must be, individually and taken together, constent with the feature that specified the instances represented by the value specification.
Notation
The multiplicity is shown as a value in square brackets following the namestring of the value specification.
The multiplicity may also be shown as a multiplicity mark in the top right corner of the symbol representing the value
specification.
26
1.4 The Multiplicities diagram
1.4. The Multiplicities diagram
Element
TypedElement
Classifier
+type
1
*
0..1
Multiplicity
+ isOrdered : Boolean = false
0.. 1
+multiplicity
[ownedElement]
+upper
[ownedElement]
0..1
ValueSpecification
1
+lower
[ownedElement]
0..1
Figure 1-12. The Root diagram of the Kernel package.
Multiplicity
A multiplicity is a definition of a non-empty set of non-negative integers which is used to specify the allowable cardinalities for an instantiation of an associated element.
Description
A multiplicity represents an inclusive interval of non-negative integers beginning with a lower bound and ending with an upper bound. Each bound is defined by a value specification. The upper bound may be infinite.
Multiplicity is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Multiplicities::Multiplicity.
Attributes
isOrdered: Boolean
For a multivalued multiplicity, this attribute specifies whether the values in an

instantiation of an associated element are sequentially ordered. Default is false.
Associations
lower: ValueSpecification [1] The specification of the lower bound for this multiplicity. The association is a
concrete specialization of the ownedElement association from Element to Element.
27
Multiplicity
upper: ValueSpecification [1] The specification of the upper bound for this multiplicity. The association is a
concrete specialization of the ownedElement association from Element to Element.
Constraints
[1] A multiplicity must define at least one valid cardinality that is greater than zero.
self.isUnbounded() or self.upperBound() > 0
[2] The lower bound must be a non-negative integer literal or an expression that evaluates to a non-negative integer
literal.
(self.lower.oclIsKindOf(LiteralInteger) and self.lower.asOclType(LiteralInteger).value >= 0)
or (self.lower.oclIsKindOf(Expression) and self.lower.isNonNegative())
[3] The upper bound must be a positive integer literal, or an expression that evaluates to a positive integer literal, or a
literal null.
(self.upper.oclIsKindOf(LiteralInteger) and self.upper.asOclType(LiteralInteger).value > 0)
or (self.upper.oclIsKindOf(Expression) and self.upper.isPositive())
or (self.upper.oclIsKindOf(LiteralNull)
[4] The upper bound must be greater than or equal to the lower bound.
self.isUnbounded() or (self.upperBound() >= self.lowerBound())
[5] If a non-literal ValueSpecification is used for the lower or upper bound, then evaluating that specification must
not have side effects.
[6] If a non-literal ValueSpecification is used for the lower or upper bound, then that specification must be a constant
expression.
[1] The query isMultivalued() checks whether this multiplicity has an upper bound greater than one.
Multiplicity::isMultivalued : Boolean;
isMultivalued = self.isUnbounded() or self.upperBound() > 1
[2] The query includesCardinality() checks whether the specified cardinality is valid for this multiplicity.
Multiplicity::includesCardinality(C : Integer) : Boolean;
includesCardinality = (self.lowerBound() <= C) and (self.isUnbounded() or self.upperBound() >= C)
[3] The query includesMultiplicity() checks whether this multiplicity includes all the cardinalities allowed by the
specified multiplicity.
Multiplicity::includesMultiplicity(M : Multiplicity) : Boolean;
includesMultiplicity = (self.lowerBound() <= M.lowerBound()) and
(self.isUnbounded() or ((not M.isUnbounded()) and self.upperBound() >= M.upperBound()))
[4] The query isUnbounded() checks whether the multiplicity has an infinite upper bound.
Multiplicity::isUnbounded() : Boolean;
isUnbounded = self.upper.oclIsKindOf(LiteralNull)
[5] The query lowerBound() returns the lower bound of the multiplicity as an integer.
Multiplicity::lowerBound() : Integer;
lowerBound =
if self.lower.oclIsKindOf(LiteralInteger) then
self.lower.oclAsType(LiteralInteger).value
else
if self.lower.oclIsKindOf(Expression) then self.lower.value() endif
endif
[6] The query upperBound() returns the lower bound of the multiplicity for a bounded multiplicity as an integer. This
operation only applies to bounded multiplicities.
28
Multiplicity
Multiplicity::upperBound() : Integer;
pre: not self.isUnbounded()
upperBound =
if self.upper.oclIsKindOf(LiteralInteger) then
self.upper.oclAsType(LiteralInteger).value
else
if self.upper.oclIsKindOf(Expression) then self.upper.value() endif
endif
Semantics
A Multiplicity defines a set of integers that define valid cardinalities. Specifically, cardinality C is valid for Multiplicity M if M.includesCardinality(C).
A Multiplicity is specified as a closed (inclusive) interval of integers starting with the value of the lower bound
and ending with the value of the upper bound. If the upper bound is specified by LiteralNull, then the upper bound is
infinity.
If a Multiplicity is multivalued, then an instantiation of an associated element has a set of values. The Multiplicity is a constraint on the number of values that may validly occur in that set.
If the Multiplicity is specified as ordered (i.e. isOrdered is true), then the set of values in an instantiation of the
associated element is ordered. This ordering implies that there is a mapping from positive integers to the elements of
the set of values. If a Multiplicity is not multivalued, then the value for isOrdered has no semantic effect.
If a multivalued Multiplicity is specified as unordered (i.e. isOrdered is false), then no assumptions can be made
about the order of the values in an instantiation of the associated element.
Notation
A multiplicity specification is shown as a text string containing the bounds of the interval, followed by an optional
ordering specification. The bounds are shown in the format:
lower-bound..upper-bound
where lower-bound and upper-bound are value specifications. The star character (*) is used as part of a multiplicity
specification to represent the unlimited (or infinite) upper bound.
A specification of ordered or unordered can appear after the bounds.
If the Multiplicity is associated with an element whose notation is a text string (such as an attribute, etc.), the
multiplicity string will be placed within square brackets ([]) as part of that text string. If specified, the ordering
appears in braces ({}) within the square brackets after the bounds. Figure 1-13 shows two multiplicity strings as part
of attribute specifications within a class symbol.
If the Multiplicity is associated with an element that appears as a symbol (such as an association end), the multiplicity string is displayed without square brackets and may be placed near the symbol for the element. If specified, the
ordering appears in braces ({}) after the bounds. Figure 1-14 shows two multiplicity strings as part of the specification of two association ends.
If the lower bound is equal to the upper bound, then an alternate notation is to use the string containing just the upper
bound. For example, 1 is semantically equivalent to 1..1.
A multiplicity with zero as the lower bound and an unspecified upper bound may use the alternative notation
containing a single star * instead of 0..*.
The following BNF defines the syntax for a multiplicity string, including support for the presentation options
listed above.
multiplicity ::= <multiplicity_range> [ { <order_designator> } ]
multiplicity_range ::= [ lower .. ] upper
29
TypedElement
lower ::= integer | expression

upper ::= integer | * | expression
<order_designator> ::= ordered | unordered
Examples
Customer
purchase : Purchase [*] {ordered}
account: Account [0..5]
Figure 1-13. Multiplicity within a textual specification
purchase
Purchase
account
Customer
* {ordered}
Account
0..5
Figure 1-14. Multiplicity as an adornment to a symbol
TypedElement
See The Features diagram on page 37.
30
1.5 The Classifiers diagram
1.5. The Classifiers diagram

Namespace
NamedElement
AutonomousElement RedefinableElement
DirectedRelationshi
p
+redefiningElement
RedefinableElement
+ isLeaf : Boolean = false
Feature
+ isStatic : Boolean = false
Classifier
+ isAbstract : Boolean = false
+ isLeaf : Boolean = false
*
+redefinedElement
*
+redefinitionContext
+feature
[member]
*
+specific
[source, owner]
+generalization
[ownedElement]
Generalization
+general
[target]
+specialization
/
+featuringClassifier
+inheritedMember
[member]
NamedElement
1..*
*
+redefinedClassifier
[redefinedElement]
*
Figure 1-15. The Classifiers diagram of the Kernel package.
Classifier
A classifier is a classification of instancesit describes a set of instances that have something in common. A classifier can have features that characterize its instances.
Description
A classifier is a namespace whose members can include features. A typed elements type is a classifierthe classifier
defines a limit on the typed elements range of permitted values. Classifier is an abstract class.
A classifier can own generalizations, thereby making it possible to define generalization relationships to other
classifiers.
A classifier may have any number of attributes.
Classifier is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Classifiers::Classifier, InfrastructureLibrary::Core::Abstractions::Generalizations::Classifier, and InfrastructureLibrary::Core::Constructs::Attributes::Classifier.
Attributes
isAbstract: Boolean
If true, the Classifier does not provide a complete declaration and can typically
not be instantiated. An abstract classifier is intended to be used by other classifiers e.g. as the target of generalization relationships. Default value is false.
attribute : Attribute [*]
Each attribute of the classifier. The association is an abstract specialization of the
feature association from Classifier to Feature, and of the redefinitionContext

association from RedefinableElement to Classifier.
31
isLeaf: Boolean
Classifier
Indicates whether it is possible to further specialize a Classifier. If the value is

true, then it is not possible to further specialize the Classifier. The default value is
false.
Associations
feature : Feature [*]
Specifies each feature of the classifier. The association is an abstract specialization of the member association from Namespace to NamedElement.
generalization: Generalization Specifies all Generalization relationships of this Classifier. These Generalizations navigate to more general classifiers in the overall generalization hierarchy.
The association is a specialization of the ownedElement association from Element to Element, and the source association from DirectedRelationship to Element.
/ inheritedMember: NamedElementReferences all elements inherited by this classifier from the general classifier.
The association is a specialization of the member association from Namespace to
NamedElement.
redefinedClassifier: Classifier References a classifier of a superclass (direct or indirect) that is redefined by this
classifier. The association is a specialization of the redefinedElement association
from RedefinableElement to RedefinableElement.
Constraints
[1] Generalization hierarchies must be directed and acyclical. A classifier can not be both a transitively general and
transitively specific classifier of the same classifier.
not self.allParents()->includes(self)
[2] A classifier may only specialize classifiers of a valid type.

self.parents()->forAll(c | self.maySpecializeType(c))
[3] The inheritedMember association is derived by inheriting the inheritable members of the parents
self.inheritedMember->includesAll(self.inherit(self.parents->collect(p | p.inheritableMembers(self)))
[1] The query parents() gives all of the immediate ancestors of a generalized Classifier.
Classifier::parents(): Set(Classifier);
parents = generalization.general
[2] The query allParents() gives all of the direct and indirect ancestors of a generalized Classifier
Classifier::allParents(): Set(Classifier);
allParents = self.parents()->union(self.parents()->collect(p | p.allParents())
[3] The query inheritableMembers() gives all of the members of a classifier that may be inherited in one of its
descendants, subject to whatever visibility restrictions apply.
Classifier::inheritableMembers(c: Classifier): Set(NamedElement);
pre: c.allParents->includes(self)
inheritableMembers = member->select(m | c.hasVisibilityOf(m))
[4] The query hasVisibilityOf() determines whether a named element is visible in the classifier. By default all are visible. It is only called when the argument is something owned by a parent.
Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
pre: self.allParents()->collect(c | c.member)->includes(n)
hasVisibilityOf =true
[5] The query conformsTo() gives true for a classifier that conforms to another. This can be used in the specification
of signature conformance for operations.
Classifier::conformsTo(other: Classifier): Boolean;
32
Feature
conformsTo = (self=other) or (self.allParents()->includes(other))
[6] The query inherit() defines how to inherit a set of elements. Here the operation is defined to inherit them all. It is
intended to be redefined in circumstances where inheritance is affected by redefinition.
Classifier::inherit(inhs: Set(NamedElement)): Set(NamedElement);
inherit = inhs
[7] The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type.
It is intended to be redefined by classifiers that have different specialization constraints.
Classifier::maySpecializeType(c : Classifier) : Boolean;
maySpecializeType = self.oclIsKindOf(c.oclType)
Semantics
A classifier is a classification of entities of a modeled system.
A Classifier may participate in generalization relationships with other Classifiers of the same kind. An instance
of a specific Classifier is also an (indirect) instance of the general Classifier. The specific semantics of how generalization affects each concrete subtype of Classifier varies.
Notation
The default notation for a classifier is a solid-outline rectangle containing the classifiers name, and optionally with
compartments separated by horizontal lines containing features or other members of the classifier. The specific type
of classifier can be shown in guillemets above the name. Some specializations of Classifier have their own distinct
notations.
The name of an abstract Classifier is shown in italics.
Different kinds of classifiers have different notation. For those notations that support compartments, attributes
can be shown within compartments, either in the same compartment, or spread between compartments. Particular
attributes within a list may be suppressed.
Any compartment may be suppressed. A separator line is not drawn for a suppressed 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.
Feature
A feature is a property or behavior that characterizes instances of a classifier.
Description
A feature declares behavioral or structural characteristic of instances of classifiers. Feature is an abstract class.
Feature is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Classifiers::Feature.
Attributes
isStatic: Boolean
Specifies if the Feature is defined for the Classifier (true) or for the Instances of the Classifier (false). The default value is false.
Associations
featuringClassifier: Classifier [1..*]

The Classifiers that have this Feature as a feature. The association is a special-
33
Generalization
ization of the association from Namespace to NamedElement where the end on

the NamedElement side is member.
Constraints
Semantics
A Feature represents some characteristic for its featuring classifiers. A Feature can be a feature of multiple classifiers.
For example, a navigable association end is a feature of the association which owns it, and of the classifier at the
other end of the association.
Notation
No general notation. Subclasses define their specific notation.
Generalization
A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. Each
instance of the specific classifier is also an instance of the general classifier. Thus, the specific classifier indirectly has
features of the more general classifier.
Description
A generalization relates a specific classifier to a more general classifier, and is owned by the specific classifier.
Generalization is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Generalizations::Generalization.
Attributes
Associations
general: Classifier [1]
References the general classifier in the Generalization relationship.

The association is a specialization of the target association from DirectedRelationship to Element.
specific: Classifier [1]
References the specializing classifier in the Generalization relationship.

The association is a specialization of the source association from DirectedRelationship to Element.
Constraints
No additional constraints
Semantics
Where a generalization relates a specific classifier to a general classifier, each instance of the specific classifier is also
an instance of the general classifier. Therefore, features specified for instances of the general classifier are implicitly
specified for instances of the specific classifier. Any constraint applying to instances of the general classifier also
applies to instances of the specific classifier.
34
RedefinableElement
Notation
A Generalization is shown as a line with an hollow triangle as an arrowhead between the symbols representing the
involved classifiers. The arrowhead points to the symbol representing the general classifier.
Multiple Generalization relationships that point to a single element can be connected together in the shared-target
style. See the example section below.
Examples
Shape
Polygon
Ellipse
Shape
Polygon
Ellipse
Separate target style
Spline
Shared target style
Spline
Figure 1-16. Examples of generalizations between classes.
RedefinableElement
A redefinable element is an element that, when defined in the context of a classifier, can be redefined more specifically or differently in the context of another classifier that specializes (directly or indirectly) the other classifier.
Description
A redefinable element is a named element that can be redefined in the context of a generalization. RedefinableElement is an abstract metaclass.
RedefinableElement is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Redefinitions::RedefineableElement.
Attributes
isFinal: Boolean
Indicates whether this RedefinableElement may be further redefined (false) or

not (true). The default value is false.
Associations
redefinedElement: RedefinableElement The redefinable element that is being redefined by this element. This is
an abstract association.
35
RedefinableElement
redefinitionContext: Classifier References the contexts that this element may be redefined from. This is an
abstract association.
Constraints
[1] At least one of the redefinition contexts of the redefining element must be a specialization of at least one of the
redefinition contexts for each redefined element.
self.redefinedElement->forAll(e | self.isRedefinitionContextValid(e))
[2] A redefining element must be consistent with each redefined element.

self.redefinedElement->forAll(re | re.isConsistentWith(self))
[1] The query isConsistentWith() specifies, for any two RedefinableElements in a context in which redefinition is
possible, whether redefinition would be logically consistent. By default, this is false; this operation must be overridden for subclasses of RedefinableElement to define the consistency conditions.
RedefinableElement::isConsistentWith(redefinee: RedefinableElement): Boolean;
pre: redefinee.isRedefinitionContextValid(self)
isConsistentWith = false
[2] The query isRedefinitionContextValid() specifies whether the redefinition contexts of this RedefinableElement
are properly related to the redefinition contexts of the specified RedefinableElement to allow this element to
redefine the other. By default at least one of the redefinition contexts of this element must be a specialization of
at least one of the redefinition contexts of the specified element.
RedefinableElement::isRedefinitionContexValid(redefinable: RedefinableElement): Boolean;
isRedefinitionContextValid = self.redefinitionContext->exists(c |
redefinable.redefinitionContext->exists(c | c.allParents()->includes(r))
)
Semantics
A RedefinableElement represents the general ability to be redefined in the presence of generalization relationships.
The semantics of redefinition varies for each specialization of the abstract assocation that relates a redefining element to what it redefines. A redefinable element is a specification concerning instances of a classifier that is the elements redefinition context. For a classifier that specializes that more general classifier (directly or indirectly),
another element can redefine the element from the general classifier in order to augment, constrain, or override the
specification as it applies more specifically to instances of the specializing classifier.
A redefining element must be consistent with the element it redefines, but it can add specific constraints or other
details that are particular to instances of the specializing redefinition context that do not contradict invariant constraints in the general context.
A redefinable element may be redefined multiple times. Furthermore, one redefining element may redefine multiple inherited redefinable elements.
Semantic Variation Points
There are various degrees of compatibility between the redefined element and the redefining element, such as name
compatibility (the redefining element has the same name as the redefined element), structural compatibility (the client
visible properties of the redefined element are also properties of the redefining element), or behavioral compatibility
(the redefining element is substitutable for the redefined element). Any kind of compatibility involves a constraint on
redefinitions. The particular constraint chosen is a semantic variation point.
Notation
No general notation. See the subclasses of RedefinableElement for the specific notation used.
36
1.6 The Features diagram
1.6. The Features diagram
+ feature
[memb er]
Feature
+featuringClassifier
Classifier
1..*
Element
+t ype
TypedElement
*
St ructuralFeature
settability : ChangeabilityK ind = unrestricted
<<enumeration>>
ChangeabilityKind
Namespace
unrestricted
readOnly
addOnly
removeOnly
<< enumeration>>
ParameterDirectionKind
in
inout
out
return
NamedElement
+parameter
[ member]
*
BehavioralFeature
Param eter
{ordered}
0..1
direction : P arameterDirectionKind = in
+formalParameter
[parameter, ownedMember]
0..1
{ordered}
{ordered}
ReturnResult
direction : ParameterDirectionKind = return
Classifier
+raisedException
*
ValueSpecification
0..1
+returnResult
0..1
+default
[ ow nedEl ement]
0..1
Figure 1-17. The Features diagram of the Kernel package.
BehavioralFeature
A behavioral feature is a dynamic feature of a classifier.
Description
A behavioral feature declares a behavioral aspect of one or more classifiers. Different kinds of behavioral aspects are
modeled by subclasses of BehavioralFeature. BehavioralFeature is an abstract metaclass.
BehavioralFeature is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Features::BehavioralFeature.
Attributes
37
ChangeabilityKind
Associations
parameter: Parameter {ordered}Specifies the parameters of the BehavioralFeature. The association is an abstract,
ordered specialization of the member association from Namespace to NamedElement.
returnResult: ReturnResult
Specifies the return parameters of the BehavioralFeature. The association is a

specialization of the parameter association from BehavioralFeature to Parameter.
Constraints
[1] The direction of a Parameter can only be return if it is also a ReturnResult.
self.parameter->forAll(p | p.direction = return implies p.oclIsKindOf(ReturnResult))
[1] The query isDistinguishableFrom() determines whether two BehavioralFeatures may coexist in the same
Namespace. It specifies that they have to have different signatures.
BehavioralFeature::isDistinguishableFrom(n: NamedElement, ns: Namespace): Boolean;
isDistinguishableFrom =
if n.oclIsKindOf(BehavioralFeature)
then
if ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->notEmpty()
then Set{}->include(self)->include(n)->isUnique( bf | bf.parameter->collect(type))
else true
endif
else true
endif
Semantics
The list of parameters describes the order and type of arguments that can be given when the BehavioralFeature is
invoked.
Notation
No additional notation.
ChangeabilityKind
Changeability kind is an enumeration type.
Description
ChangeabilityKind is an enumeration of the following literal values:
unrestricted
Indicates that there is no restriction no adding new values, changing a value, or

removing values to an occurrence of a StructuralFeature.
readOnly
Indicates that adding new values, changing values, and removing values or an
occurrence of a StructuralFeature is not permitted.
addOnly
Indicates that there is no restriction on adding new values to an occurrence of a

StructuralFeature, but changing and removing values are restricted.
removeOnly
Indicates that there is no restriction on removing values from an occurrence of a

StructuralFeature, but adding new values and changing values is not permitted.
38
Parameter
Parameter
A parameter declares an argument of a behavioral feature.
Description
A parameter is a specification of an argument used to pass information into or out of an invocation of a behavioral
element.
A parameter is a kind of typed element in order to allow the specification of an optional multiplicity on parameters. In addition, it can own a value specification to support the specification of an optional default value.
Parameter is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::BehavioralFeatures::Parameter
and InfrastructureLibrary::Core::Constructs::Operations::Parameter.
Attributes
direction: ParameterDirectionKindIndicates whether a parameter is being sent into or out of a behavioral element. The default value is in.
Associations
default: ValueSpecification [0..1]

Defines a ValueSpecification whose evaluation yields a value to be used when no
argument is supplied for the Parameter. The association is a specialization of the
ownedElement association from Namespace to NamedElement.
Constraints
Semantics
A parameter specifies arguments that are passed into or out of an invocation of a behavioral element like an operation. A parameters type restricts what values can be passed.
A parameter may be given a name, which then identifies the parameter uniquely within the parameters of the
same behavioral feature. If it is unnamed, it is distinguished only by its position in the ordered list of parameters.
A parameter specifies how arguments are passed into or out of an invocation of a behavioral feature like an operation. The type and multiplicity of a parameter restrict what values can be passed, how many, and whether the values
are ordered.
If a default is specified for a parameter, then it is evaluated at invocation time and used as the argument for this
parameter if and only if no argument is supplied at invocation of the behavioral feature.
Notation
See Operation.
Style Guidelines
A parameter name typically starts with a lowercase letter.
ParameterDirectionKind
Parameter direction kind is an enumeration type.
39
ReturnResult
Description
ParameterDirectionKind is an enumeration of the following literal values:
in
Indicates that parameter values are passed into the behavioral element by the
caller.
inout
Indicates that parameter values are passed into a behavioral element by the caller
and then back out to the caller from the behavioral element.
out
Indicates that parameter values are passed from a behavioral element out to the
caller.
return
The direction can only be return if the Parameter is a ReturnResult, and means
that the return result is passed like parameter values from a behavioral element
back out to the caller.
ReturnResult
A return result is a specification of information that is returned from an invocation of an operation.
Description
A return result is a kind of typed element that describes the values that may be returned from an operation.
ReturnResult is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Operations::ReturnResult.
Attributes
Associations
Constraints
[1] The direction of a ReturnResult is return.
self.direction = return
Semantics
A return result specifies values that are returned from an invocation of a behavioral feature like an operation. The
type and multiplicity of a return result restricts what values can be returned, how many, and whether the values are
ordered.
Notation
See Operation.
StructuralFeature
A structural feature is a typed feature of a classifier that characterizes instances of the classifier.
Description
A structural feature declares a structural aspect of the instances of a classifier, and it is related to a classifier that acts
as a constraint on the possible values of the structural feature. Structural feature is an abstract metaclass.
40
TypedElement
A structural feature has an attribute settability that determines a clients access rights to its values.
StructuralFeature is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::StructuralFeatures::StructuralFeature and InfrastructureLibrary::Core::Abstractions::Changeabilities::StructuralFeature.
Attributes
settability: ChangeabilityKind States whether and how the features value may be modified.
Associations
Constraints
Semantics
A structural feature specifies that instances of the featuring classifier have a feature whose value or values are of a
specified type.
Notation
The settability of a structural feature is specified using the name of the ChangeabilityKind instance within curly
brackets, e.g {readOnly}.
It is permissible in the notation to show a ChangeabilityKind whose name is made up of multiple words as words separated by a white space or a hyphen, e.g. {add only} or {read-only}.
TypedElement
A typed element has a type that is given by a classifier.
Description
A typed element is an element that has a type in the form of a classifier that serves as a constraint on the range of values the element can represent. Typed element is an abstract metaclass.
A typed element can own a multiplicity, which specifies valid cardinalities for the set of values associated with
an instantiation of the typed element.
TypedElement is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Classifiers::TypedElement
and InfrastructureLibrary::Core::Abstractions::Multiplicities::TypedElement.
Attributes
Associations
type: Classifier [1]
The type of the TypedElement.
multiplicity: Multiplicity [0..1] The Multiplicity for this TypedElement. The association is a concrete specialization of the ownedElement association from Element to Element.
41
1.7 The Classes diagram
Constraints
Semantics
The type of a typed element is a classifier. Values represented by the element are constrained to be instances of the
classifier.
See Multiplicity for a description of the general semantics. Specific semantics are described in the subclasses of
TypedElement.
Notation
No additional notation. Subclasses define the specific notation for including multiplicities.
1.7. The Classes diagram
StructuralFeature
+nestedClassifier
Classifier
[redefinitionContext]
[ownedMember]
+attribute
[feature]
*
{ordered}
+ownedAttribute
[attribute, ownedMember]
0..1
* {ordered}
[namespace, redefinitionContext]
[namespace,
redefinitionContext]
Attribute
+ isDerived : Boolean = false
+default
[ownedElement] ValueSpecification
0..1
0..1
Class
0..1
BehavioralFeature
0..1
*
+redefinedAttribute
[redefinedElement]
*
+ownedOperation
[feature, ownedMember]
* {ordered}
Operation
[context, namespace]
0..1
[context, namespace]
0..1
+precondition
[ownedMember]
Constraint
*
+postcondition
[ownedMember]
*
*
+redefinedOperation
* [redefinedElement]
Figure 1-18. The Classes diagram of the Kernel package.
Attribute
An attribute is a structural feature of a classifier that characterizes instances of the classifier. An attribute relates an
instance of a classifier to a value or values through a named relationship.
Description
Attribute is a subclass of StructuralFeature. It represents a declared state of an instance of a classifier in terms of a
named relationship to a value or values.
42
Attribute
Attribute is a subclass of Multiplicities::TypedElement. The range of valid values can be controlled by setting the
attributes type. The number of attribute values for a single instance of the classifier can be controlled by setting the
attributes multiplicity.
In the context of generalization, an attribute in a general classifier can be redefined in a more specific classifier.
The name and visibility of an attribute are not required to match those of any attribute it redefines. An attribute that is
redefined is excluded from being an inheritedMember of the featuring classifier of the redefining attribute, regardless
of whether it has the same name as the redefining attribute.
Attribute is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Attributes::Attribute.
Attributes
isDerived : Boolean
Specifies whether the Attribute is derived, i.e. its value or values can be computed from other information. The default value is false.
Associations
default : ValueSpecification [0..1]

References an optional value specification telling how to set the attribute when creating
an instance in the absence of a specific setting for the attribute. The association is a
specialization of the ownedElement association from Element to Element.
redefinedAttribute : Attribute [*]

References the attributes that are redefined by this attribute. This association is a
specialization of the redefinedElement association.
Constraints
[1] The query isConsistentWith() specifies, for any two Attributes in a context in which redefinition is possible,
whether redefinition would be logically consistent. A redefining attribute is consistent with a redefined attribute
if the type of the redefining attribute conforms to the type of the redefined attribute, the multiplicity of the redefining attribute (if.specified) is contained in the multiplicity of the redefined attribute, and the redefining attribute
is derived if the redefined attribute is derived.
Attribute::isConsistentWith(redefinee: RedefinableElement): Boolean;
isConsistentWith = (redefinee.oclIsKindOf(Attribute) and
let attr: Attribute = redefinee.oclAsType(Attribute) in
attr.type.conformsTo(self.type) and
(attr.multiplicity->isEmpty() or (self.multiplicity->notEmpty() and
self.multiplicity.includesMultiplicity(attr.multiplicity))) and
(not self.isDerived or attr.isDerived)
[2] The query allRedefinedAttributes() gives all of the direct and indirect redefined attributes of an attribute.
Attribute::allRedefinedAttributes() : Set(Attribute);
allRedefinedAttributes = self.redefinedAttribute->union(self.redefinedAttribute->
collect(a | a.allRedefinedAttributes)
Semantics
All instances of a classifier have attribute values corresponding to the attributes of the classifier. An attribute value
conforms to the attributes type.
If there is a default specified for an attribute, this default is evaluated when an instance is created in the absence
of a specific setting for the attribute. The evaluated default then becomes the initial value (or values) of the attribute
for the instance.
43
Attribute
If an attribute is derived, then its value or values can be computed from other information. Actions involving a
derived attribute behave the same as for a nonderived attribute. Derived attributes are often specified to be unchangeable (i.e. clients cannot directly change values). But where a derived attribute is changeable, an implementation is
expected to appropriately change the source information of the derivation. The derivation for a derived attribute may
be specified by a constraint.
Where one classifier specializes another, an attribute of the specific classifier can redefine an attribute of the general classifier in order to more specifically characterize instances of the specializing classifier. For any instance of the
specific classifier, the redefining attributes value or values are exactly the same as those of the redefined attribute
seen from the perspective of the more general classifier. An attribute that redefines another attribute implicitly preserves the redefined attributes constraints such as type and multiplicity, including ordering. A redefining attribute
can further constrain type or multiplicity, but it must do so in a way that does not contradict constraints on the redefined attribute: a type can be made more specific but not more general, ordering can be added but not taken away, a
multiplicity upper bound can be reduced but not increased, and a lower bound can be increased but not reduced.
An attribute can be derived even if it redefines an attribute that is not derived. This means that the attribute can be
derived for instances of the featuring classifier of the redefining attribute, but it is not necessarily derived for all instnaces of the more general featuring classifier of the redefined attribute.
If an attribute has a specified default, and the attribute redefines another attribute with a specified default, then
the redefining attributes default is used for instances of the featuring classifier in place of the more general default
from the redefined attribute.
The precise lifecycle semantics of attribute values are a semantic variation point.
Notation
An attribute can be shown as a text string that can be parsed into the various properties of an attribute. The basic syntax is (with optional parts shown in braces):
[visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }]

In the following bullets, each of these parts is described:
visibility is a visibility symbol such as + or -. See VisibilityKind on page 17.
/ means the attribute is derived.
name is the name of the attribute.
type identifies a classifier that is the attributes type.
multiplicity shows the attributes multiplicity in square brackets. The term may be omitted when a multiplicity of
1 (exactly one) is to be assumed. See Multiplicity on page 27.
default is an expression for the default value or values of the attribute.
property-string indicates property values that apply to the element. The property string is optional (the braces are
omitted if no properties are specified). Settability can also be shown as a property-string, e.g. {addOnly}.
An attribute with the same name as an attribute that would have been inherited is interpreted to be a redefinition.
To indicate redefinition where a name is being changed, a property-string can include the keyword redefines followed by the redefined attributes name, e.g. {redefines x}. Note that a redefined attribute is not inherited as into a
namespace where it is redefined, so its name can be reused in the featuring classifier, either for the redefining
attribute, or alternately for some other attribute.
The type, visibility, default, multiplicity, property string may be suppressed from being displayed, even if there are
values in the model.
44
Class
The individual properties of an attribute can be shown in columns rather than as a continuous string.
Style Guidelines
Attribute names typically begin with a lowercase letter. Multiword names are often formed by concatenating the
words and using lowercase for all letter except for upcasing the first letter of each word but the first.
Examples
ClassA
name: String
shape: Rectangle
+ size: Integer [0..1]
/ area: Integer {readOnly}
height: Integer= 5
width: Integer
ClassB
id {redefines name}
shape: Square
height = 7
/ width
Figure 1-19. Examples of attributes.

The attributes in Figure 1-19 are explained below.
ClassA::name is an attribute with type String.
ClassA::shape is an attribute with type Rectangle.
ClassA::size is a public attribute of type Integer with multiplicity 0..1.
ClassA::area is a derived attribute with type Integer. Its changeability is read-only.
ClassA::height is an attribute of type Integer with a default initial value of 5.
ClassA::width is an attribute of type Integer
ClassB::id is an attribute that redefines ClassA::name.
ClassB::shape is an attribute that redefines ClassA::shape. It has type Square, a specialization of Rectangle.
ClassB::height is an attribute that redefines ClassA::height. It has a default of 7 for ClassB instances which overrides the ClassA default of 5.
ClassB::width is a derived attribute that redefines ClassA::width, which is not derived.
Class
A class describes a set of objects that share the same specifications of features, constraints, and semantics.
45
Class
Description
Class is a kind of classifier whose features are attributes and operations.
Class is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Classes::Class.
Attributes
Associations
ownedAttribute : Attribute
The attributes owned by the class. This ordered association specializes the
attribute association of Attributes package and the ownedMember association of
the Namespaces package.
ownedOperation : Operation
The operations owned by the class. This ordered association specializes the feature association of the Classifiers package and the ownedMember association of
the Namespaces package.
nestedClassifier: Classifier
References all the Classifiers that are defined (nested) within the Class. The association is a specialization of the ownedMember association from Namespace to
NamedElement.
Constraints
Semantics
The purpose of a class is to specify a classification of objects and to specify the features that characterize the structure
and behavior those objects.
When an object is instantiated in a class, for every attribute of the class that has a specified default, if an initial
state of the attribute is not specified explicitly for the instantiation, then the default value specification is evaluated to
set the initial state of the attribute for the object.
Notation
A class is shown using the classifier symbol. As class is the most widely used classifier, the word class need not be
shown in guillemets above the name. A classifier symbol without a metaclass shown in guillemets indicates a class.
A class is often shown with three compartments. The middle compartment holds a list of attributes while the bottom
compartment holds a list of operations.
Attributes or operations may be presented grouped by visibility. A visibility keyword or symbol can then be
given once for multiple features with the same visibility.
Additional compartments may be supplied to show other details, such as constraints, or to divide features.
Style Guidelines
Center class name in boldface.
Capitalize the first letter of class names (if the character set supports uppercase).
Left justify attributes and operations in plain face.
Begin attribute and operation names with a lowercase letter.
Put the class name in italics if the class is abstract.
46
Operation
Show full attributes and operations when needed and suppress them in other contexts or when merely referring to
a class.
Examples
Window
Window
+ size: Area = (100, 100)
# visibility: Boolean = true
+ defaultSize: Rectangle
- xWin: XWindow
Window
size: Area
visibility: Boolean
display()
hide()
- attachX(xWin: XWindow)
display()
hide()
Figure 1-20. Class notation: details suppressed, analysis-level details, implementation-level details.
Window
public
size: Area = (100, 100)
defaultSize: Rectangle
protected
visibility: Boolean = true
private
xWin: XWindow
public
display()
hide()
private
attachX(xWin: XWindow)
Figure 1-21. Class notation: attributes and operations grouped according to visibility.
Operation
An operation is a feature which declares a service that can be performed by instances of the featured classifiers.
Description
The specification of an operation defines what service it provides, not how this is done, and can include a list of preand postconditions.
An operation is identified by its name and its signature.
Operation is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Operations::Operation.
47
Operation
Attributes
Associations
formalParameter: Parameter
Specifies the formal parameters for this Operation. This association is a specialization of the parameter association from BehavioralFeature to BehavioralFeatures::Parameter, and of the ownedMember association from Namespace to
NamedElement
postcondition: Constraint
An optional set of Constraints specifying what is fulfilled when performance of

the Operation is completed, if the precondition was fulfilled before its invocation.
Namespace to NamedElement, and a specialization of the context association
from Constraint to Namespace.
precondition: Constraint
An optional set of Constraints specifying what must be fulfilled when the

Operation is invoked.
Namespace to NamedElement, and a specialization of the context association
from Constraint to Namespace.
raisedException: Classifier
References the Classifiers representing exceptions that may be raised during an

invocation of this operation.
redefinedOperation: Operation References the Operations that are redefined by this Operation. This association
is a specialization of the redefinedElement association.
returnResult: ReturnResult
Specifies the return results for this Operation. This association is a specialization
of the parameter association from BehavioralFeature to BehavioralFeatures::Parameter, and of the ownedMember association from Namespace to
NamedElement
Constraints
[1] The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible,
whether redefinition would be logically consistent. A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result.
Operation::isConsistentWith(redefinee: RedefinableElement): Boolean;
isConsistentWith = (redefinee.oclIsKindOf(Operation) and
let op: Operation = redefinee.oclAsType(Operation) in
self.formalParameter.size() = op.formalParameter.size() and
self.returnResult.size() = op.returnResult.size() and
forAll(i | op.formalParameter[i].type.conformsTo(self.formalParameter[i].type)) and
forAll(i | op.returnResult[i].type.conformsTo(self.returnResult[i].type))
)
Semantics
An operation is invoked on an instance of the classifier for which the operation is a feature. The formal parameters
define the type, and number, of arguments that must be provided when invoking the operation. The return results
define the type, and number, of arguments that will be returned from a successful invocation of the operation.
48
Operation
The preconditions for an operation define conditions that must be true when the operation is invoked. These preconditions may be assumed by an implementation of this operation.
The postconditions for an operation define conditions that will be true when the invocation of the operation is
completes successfully, assuming the preconditions were satisfied. These postconditions must be satisfied by any
implementation of the operation.
An operation may raise an exception during its invocation. When an exception is raised, it should not be assumed
that the postconditions of the operation are satisfied.
An operation may be redefined in a specialization of the featured classifier. This redefinition may specialize the
types of the formal parameters or return results, add new preconditions or postconditions, add new raised exceptions,
or otherwise refine the specification of the operation.
The behavior of an invocation of an operation when a precondition is not satisfied is a semantic variation point.
Notation
An operation is shown as a text string of the form:
visibility name ( parameter-list ) : property-string
Where visibility is the operations visibility -- visibility may be suppressed.
Where name is the operations name.
Where parameter-list is a comma-separated list of formal parameters, each specified using the syntax:
name : type-expression [multiplicity] = default-value
Where name is the parameters name.
Where type-expression identifies the type of the parameter.
Where multiplicity is the parameters multiplicity in square brackets -- multiplicity may be suppressed in
which case [1] is assumed.
Where default-value is a value specification for the default value of the parameter. The default value is
optional (the equal sign is also omitted if the default value is omitted).
Where property-string optionally shows other properties of the operation enclosed in braces.
The parameter list can be suppressed.
Style Guidelines
An operation name typically begins with a lowercase letter.
Examples
The following are examples of operations:
display ()
-hide ()
+createWindow (location: Coordinates, container: Container [0..1]): Window
+toString (): String
49
1.8 The Associations diagram
1.8. The Associations diagram
Classifier
StructuralFeature
Relationship
1..*
+endType
[relatedElement]
Associati on
/
+ i sDerived : Boolean = false
0..1
+end
AssociationEnd
2..* {ordered}
+association
[namespace, featuringClassifier, redefinitionContext]
*
+redefinedEnd
[redefinedElement]
+end
[end]
Aggregation
+ isComposite : Boolean
0..1
1..*
/
+aggregateEnd
[end]
0..1
1
+partEnd
[end]
0..1
+otherEnd
1..*
+otherEnd
1
Attribute
NavigableEnd
reference
[attribute]
+referencingClassifier
Classifier
Figure 1-22. The Associations diagram of the Kernel package.
Aggregation
An aggregation is a kind of binary association that specifies an aggregation relationship (a whole/part relationship).
Description
An aggregation has two ends, an aggregate end and a part end. An aggregation specifies that an instance of a classifier
on the aggregate end aggregates an instance of the classifier at the part end. The aggregate instance may in turn be
part of another aggregate.
Aggregation is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Aggregations::Aggregation.
Attributes
isComposite : Boolean
Indicates the nature of the aggregation. If false, the classifier at the aggregate end
represents a shared aggregate, and the instance specified by the classifier at the
50
Aggregation
part end may be contained in other aggregates. If true, the classifier at the aggregate end represents a composite aggregate, and the instance specified by the classifier at the part end is strongly owned by the composite and may not be a
composite part of any other instance.
Associations
aggregateEnd : AssociationEnd [1]

Indicates the association end connected to the classifier specifying the aggregate.
(Specializes Aggregation::end.)
end : AssociationEnd [2]
partEnd : AssociationEnd [1] Indicates the association end connected to the classifier specifying the part. (Specializes Aggregation::end.)
Specializes AssociationEnd::end in order to restrict multiplicity to 2. This association is abstract.
Constraints
[1] A specialization of a composite aggregation is also a composite aggregation.
self.isComposite implies self.specialization->forAll(g | g.specific.oclAsType(Aggregation).isComposite)
[2] A multiplicity on an aggregate end of a composite aggregation must not have an upper bound greater than 1.
(self.isComposite and self.aggregateEnd.multiplicity->notEmpty()) implies
((not self.aggregateEnd.multiplicity.isUnbounded()) and
self.aggregateEnd.multiplicity.upperBound() <= 1)
Semantics
An association may represent an aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. At the instance level, a link of an Aggregation relates an instance of a classifier connected at the part end to
an instance of a classifier connected at the aggregate end. The added meaning of an aggregate link over a nonaggregate link is that the instance at the part end is part of the instance at the aggregate end.
Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one
composite at a time. If a composite is deleted, all of its parts are deleted with it. Note that a part can (where allowed)
be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions define transitive asymetric relationshipstheir links form a directed, acyclic graph.
A noncomposite aggregation, also called shared aggregation, denotes weak aggregation, where the part may be
included in multiple separate aggregates. Deletion of an instance does not cause deletion of its noncomposite parts.
Precise semantics of shared aggregation varies by application area and modeler.
The order and way in which part instances are created is not defined.
Notation
An aggregation is shown using the same notation as a binary association, but with a diamond at the aggregate end. A
hollow diamond indicates shared aggregation. A solid, filled diamond indicates composition.
If there are two or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation
ends into a single segment. Any adornments on that single segment aply to all of the aggregation ends.
51
Association
Examples
Window
1
1
+scrollbar
+title
+body
Slider
Header
1
Panel
Figure 1-23. Composite aggregation is depicted as a black diamond.
Association
An association declares a relationship that may occur between instances of classifiers at the associations ends. Each
association end declares how an instance of the classifier at the association end participates in the relationship. An
instance of an association is called a link.
Description
An association specifies a semantic relationship that can occur between instances of other classifiers. It has at least
two association ends, each of which is connected to a classifier that is the type of the end. The same classifier may be
the type of more than one end of an association.
An association represents a set of links relating instances of the connected classifiers.
Association is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Associations::Association.
Attributes
isDerived : Boolean
Specifies whether the relationship is derived from other model elements such as
other associations or constraints. The default value is false.
Associations
end : AssociationEnd [2..* ordered] Each end represents participation of instances of the classifier connected to
the end in links of the association. This is a specialization of the ownedMember
association from Namespace to NamedElement and a specialization of the feature association from Classifier to Feature.
/ endType: Classifier [1..*]
References the classifiers that are used as types of the ends of the association.
This is derived from self.end->collect(e | e.type).
Constraints
[1] An association specializing another association has the same number of ends as the other association.
self.parents()->forAll(p | p.end.size() = self.end.size())
[2] When an association specializes another association, every end of the specific association redefines exactly one
end of the general association, and every end of the general association is redefined by at least one end of the specific association.
self.parents()->select(p | p.oclIsKindOf(Association)->forAll(ga | self.end->forAll
52
Association
(se | se.redefinedEnd->select(re | ga.end->includes(re))->size() = 1)

and ga.end->forAll(ge | self.end->exists(se | se.redefinedEnd->includes(ge)))
Semantics
An association declares that there can be links between instances of the associated classifiers. A link has one value for
each end of the assocation, where each value is an instance of the classifier that is the type of the end.
Associations are generalizable, as are other classifiers. An association can specialize a more general association,
in which case the two associations have the same number of ends, and the ends of the specific association redefine the
ends of the general association. A link of the specific association is a link of the general association by matching the
value for each end of the specific association to a redefined end that is an end of the general association. By matching
each ends value to a corresponding redefined end of the general assocaition, the link of a specific association is also
a link of the more general association. The type of each end of the specific association matches or specializes the type
of each redefined end of the general association. Where an association specializes multiple general associations, its
ends redefine all ends of each general association.
Order of an associations ends does not affect semantics of associations. The correlation of ends across a generalization is based on redefinition of ends, not on order. However, order can be relevant to reading an association name
with respect to its ends.
If an end of an association redefines more than one end of a single general association, then a link of the specific
association is correspondingly a link of the general association by more than one mapping of ends.
Links of an abstract association occur only indirectly as links of nonabstract associations that specialize the
abstract association. An abstract association can also be specialized by a derived association -- each derived link of
the specific association is also a link of the general association.
Links of a derived association are derived or implied based on other information. Derivations can be expressed
using constraints. An abstract association can be specialized by a derived association each derived link of the specific association is also a link of the general association.
Notation
Any association may be drawn as a diamond (larger than a terminator on a line) with a solid line for each association
end connecting the diamond to the classifier that is the ends type. An association with more than two ends can only
be drawn this way.
A binary assocation is normally drawn as a solid line connecting two classifiers, or a solid line connecting a single classifier to itself (the two ends are distinct). A line may may consist of one or more connected segments. The
individual segments of the line itself have no semantic significance, but they may be graphically meaningful to a tool
in dragging or resizing an association symbol.
An association symbol may be adorned as follows:
The associations name can be shown as a name string near the association symbol, but not near enough to an end
to be confused with the ends name.
A slash appearing in front of the name of an association, or in place of the name if no name is shown, marks the
association as being derived.
A property string may be placed near the association symbol, but far enough from any end to not be confused
with a property string on an end.
An abstract association is shown using italics for its name and end names.
On a binary association drawn as a solid line, a solid triangular arrowhead next to or in place of the name of the
association and pointing along the line in the direction of one end indicates that end to be the last in the order of the
ends of the association. The arrow indicates that the association is to be read as associating the end away from the
direction of the arrow with the end to which the arrow is pointing (see Figure 1-24).
53
Association
Generalizations between associations can be shown using a generalization arrow between the association symbols.
When two lines cross, the crossing may optionally be shown with a small semicircular jog to indicate that the lines do
not intersect (as in electrical circuit diagrams).
A generalization arrow is not necessary where an end of the specific association clearly redefines an end of the
general association. See details about the notation for redefining ends in the descriptions of notation for AssociationEnd. It is also permissible to not explicitly show every redefined end as long as those that are shown clearly imply the
others. For a binary association, explicitly naming a redefined end of one end implies that the other end redefines the
named redefined ends opposite end.
Style Guidelines
Lines may be drawn using various styles, including orthogonal segments, oblique segments, and curved segments.
The choice of a particular set of line styles is a user choice.
Generalizations between associations are best drawn using a different color or line width than what is used for the
associations.
54
Association
Examples
Year
W PlayedInYear
*
year
season
Team
*
team
Player
goalie
Figure 1-24. Binary and ternary associations.

Figure 1-24 shows a binary association from Player to Year named PlayedInYear. The solid triangle indicates the
order of reading: Player PlayedInYear Year. The figure further shows a ternary association between Team, Year, and
Player with ends named team, season, and goalie respectively.
Figure 1-25. Association generalization.

In the example in Figure 1-25, the association B specializes the association A. The association ends of A are redefined in B. B::son has redefinedEnd A::child, and B::father has redefinedEnd A::parent. These redefinitions are
shown using square brackets in the diagram. Because B specializes A, each B link is logically an A linkevery sonto-father link is more generally a child-to-parent link with the person who is B::son as A::child and the person
who is B::father as A::parent.
Figure 1-25 shows more notational elements than are actually necessary to state the model. First, the generalization arrow between A and B can be omitted because the generalization is implied by the redefinition of the ends. Second, either of the names of the redefined ends can be omitted ([child] or [father], but not both) because either
redefinition implies the other.
55
Association
The example in Figure 1-26 below shows a simple derived association where derivation is based on a single constraint on one of the connected classifiers. The association AB is derived from the two other associations based on a
constraint.
/AB
B
*
b
{b=c.b}
1
C
Figure 1-26. Derived association.

In other cases derivations are not so directly stated. In the following example, Figure 1-27, two constraints provide the derivation of AB. The two constraints, expressed from the perspective of E and C, require AB to include links
corresponding to all EF and CD links. The two constraints could have been combined into one complex constraint on
A, but having separate constraints on the subtypes of A frees the definition of A from being aware of its subtypes and
allows the derivation to be extended from the outside by adding further constraints in other subclasses.
/AB
E
{b->includesAll(f)}
CD
{b->includesAll(d)}
f 1..*
EF
Figure 1-27. Derived association with derivation implied by multiple constraints.
56
AssociationEnd
If the association UncleOf is a specialization of RelativeOf with an end uncle redefining an end relative, then a
link of UncleOf representing that George is Pauls uncle is also a link of RelativeOf representing more generally that
George is Pauls relative.
RelativeOf
*
*
relative
Person
*
uncle
[relative]
UncleOf
Figure 1-28. Derived association with derivation implied by multiple constraints.

In the previous example of UncleOf specializing RelativeOf, if relative is the first end of RelativeOf, there is no
requirement that uncle be the first end of UncleOf. It can be first or second without regard to the ordering of UncleOf
ends.
If UncleOf has two ends, uncle and nephew, and both ends redefine relative, then a link of UncleOf that George
is Pauls uncle is a link of RelativeOf that George is Pauls relative and also a link of RelativeOf that Paul is Georges
relative.
AssociationEnd
Each association end is part of one association. An association specifies the participation of instances of a classifier in
the links of the association.
Description
An association end is a kind of structural feature that has a type, and optionally, a name and a multiplicity.
AssociationEnd is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Associations::AssociationEnd.
Attributes
Associations
association : Association [1]
Specifies the association that owns the end. Specializes NameElement::namespace, Feature::featuringClassifier, and RedefinableElement::redefinitionContext.
/ otherEnd : AssociationEnd [1..*]

Refers to the other end or ends of the same association. The association is derived
to be all ends of the owning association besides this one.
57
AssociationEnd
redefinedEnd : AssociationEnd [*]

Specifies each end being redefined by this end. See explanation of association
generalization above. Specializes RedefinableElement::redefinedElement.
Constraints
[1] Where an end redefines another end, the end's type is either the same as or a specialization (directly or indirectly)
of the redefined end's type.
self.redefinedEnd->forAll(e | self.type = e.type or self.type.allParents()->includes(e.type)
[2] The multiplicity of an end must not have a higher maximum upper bound than that of any end it redefines
(directly or indirectly).
let m = self.multiplicity
let rm = self.redefinedEnd.multiplicity in
m->isEmpty() or
if m.isUnbounded()
then rm->forAll(r | r.isUnbounded())
else rm->forAll(r | r.isUnbounded() or r.upperBound() >= m.upperBound())
endif
[3] The other ends equals all other association ends in the containing association except for this end.
otherEnd = self.association.end->reject(e | e = self)
Semantics
An association end defines a structural feature of an associationa feature whose value in each link is exactly one
instance of the ends type. The multiplicity of an association end constrains the number of links of the association
having the same values for the other ends. An ends multiplicity that specifies ordering indicates that links of the
association having the same values for the other ends are retrievable in a controllable order.
Where one end redefines another end, the multiplicity upper bound of the redefined end implicitly holds true for
the redefining end; hence, the redefining end must not have a higher upper bound than the redefined end. But a redefined ends lower bound or specification of ordering do not implicitly apply to the redefining end. Ordering can be
added to a redefined end, but it cannot be taken away.
Note: For n-ary associations, the lower multiplicity of an end is typically 0. If the lower multiplicity for an
end of an n-ary association of 1 (or more) implies that one link (or more) must exist for every possible combination of values for the other ends.
Notation
An association end is the connection between the line depicting an association and the icon (often a box) depicting the
connected classifier. A name string may be placed near the end of the line to show the name of the association end.
The name is optional and suppressible.
Various other notations can be placed near the end of the line as follows:
1.
2.
3.
A multiplicity.
A property string enclosed in curly braces. To indicate ordering, the word ordered can be used as a property
string, e.g. {ordered}.
The name of a redefined end can appear in square brackets (as described for Association above). Multiple redefined end names can be separated by commas in the same square brackets. Presence of a redefined end implies a
generalization of the association.
58
NavigableEnd
Examples
The following example shows association ends with various adornments.
a
A
B
0..1
* {ordered}
d [b]
C
1
0..1
Figure 1-29. Association ends with various adornments.

The following adornments are shown on the four association ends in Figure 1-29.
Names a, b, and d on three of the ends.
Multiplicities 0..1 on a, * on b, 1 on the unnamed end, and 0..1 on d.
Specification of ordering on b.
Redefinition on d. Its redefinedEnd is b, so the association having the d end is a specialization of the association
having the b end.
Given an association having ends child and parent, both of type Person, a multiplicity upper bound of 2 on parent
constrains there to be at most two links with the same value for child. A multiplicity lower bound of 2 on parent
requires existence of at least two links for every instance of childs type, Person.
If an end father redefines the end parent with multiplicity 2, father can have multiplicity 1 an upper bound of
1 cannot exceed parents upper bound of 2 because every father is a parent, but fathers lower bound of 1 can be less
than parents lower bound of 2 not every parent needs to be a father.
NavigableEnd
A navigable end is an association end that is also an attribute of the classifier that is the type of the other end.
Description
A navigable is both a kind of an association end and a kind of an attribute. A navigable end extends the definition of
the classifier at the other end (the referencingClassifier) by being an attribute of that classifier (but not an owned
attribute). A navigable end is owned by its association.
NavigableEnd is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Navigations::NavigableEnd.
Attributes
No addtional attributes.
59
NavigableEnd
Associations
otherEnd : AssociationEnd [1] Redefines otherEnd of AssociationEnd in order to constrain its multiplicity to 1.
A navigable end has exactly one other end.
/ referencingClassifier : Classifier[1]
Designates the classifier that has this end as an attribute. The association is
derived -- it is the other ends type.
Constraints
[1] The referencingClassifier is the type of the other end.
referencingClassifier = self.otherEnd.type
[2] The association containing a navigable end must be in the same namespace as the referencing classifier.
self.association.namespace = self.referencingClassifier.namespace
Semantics
A navigable end is a feature (an end) of its owning association, and is also a feature (an attribute) of the referencing
classifier. Each link of the association corresponds with exactly one attribute value from the perspective of one
instance of the referencing classifier.
As an attribute, a navigable end can redefine other attributes and be redefined by other attributes, whether or not
the other attributes are also navigable ends. Attribute redefinition occurs relative to generalization of the referencing
classifier and should not be confused with end redefinition, which occurs relative to generalization of the association.
Notation
A stick arrowhead on the end of an association indicates the end is navigable. A visibility symbol can be added as an
adornment on a navigable end to show the ends visibility as an attribute of the featuring classifier.
There are two frequently-encountered ways in which one navigable association end redefines another. One is
simply an end redefinition with no attribute redefinition. The second involves both end redefinition and attribute
redefinition at the same time. The second case is identified based on the notation for attribute redefinition which is
shown either by having the same name for both attributes (navigable ends in this case) or by the presense of a property-string with the keyword {redefines}.
The notation for an attribute can be applied to a navigable assocation end name.
Various options may be chosen for showing navigation arrows on a diagram. In practice, it is often convenient to suppress some of the arrows and just show exceptional situations:
Show all arrows. The absence of an arrow indicates navigation is not supported.
Suppress all arrows. No inference can be drawn about navigation. This is similar to any situation in which information is suppressed from a view.
Suppress arrows for associations with navigability in both directions, and show arrows only for associations with
one-way navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no
navigation at all; however, the latter case occurs rarely in practice.
60
NavigableEnd
Examples
AB
B
*
CD
0..10 {ordered}
1 {readOnly}
Figure 1-30. Examples of navigable ends.

Three navigable ends are shown in Figure 1-30.
AB::b, a.k.a A::b
a navigable end of AB, and an attribute of A. It is multivalued.
CD::b, a.k.a C::b
a navigable end of CD, and an attribute of C, it redefines A::b both as an

attribute, and therefore, as an end (this implies that CD is a specialization of AB
even though no generalization arrow is shown). For a C instance, b has 10 or less
values and is ordered.
CD::c, a.k.a D::c
another navigable end of CD, it has a single value for any instance of D, and has
restricted settability.
Figure 1-31 shows A::b from Figure 1-30 using attribute notation. A navigable end is an attribute, so it can be shown
using attribute notation. It is possible to use both kinds of notations at the same time.
A
b: B[*]
Figure 1-31. Example of navigable end shown with attribute notation.
61
1.1 The DataTypes diagram
1.1. The DataTypes diagram
Classifier
+ownedAtt ribute
0..1
DataTy pe
[ namespace, redefinit ionContext]
{ordered} *
[ namespace, redefinit ionContext]
{ordered} *
Attribute
Operation
+ownedOperation
0..1
InstanceSpecification
PrimitiveTy pe
Enumeration
+classifier
[ clas sifier]
EnumerationValue
Figure 1-32. The DataTypes diagram of the Kernel package.
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 enumeration types.
Description
A data type defines a kind of classifier in which operations are all pure functions (i.e., they can return data values but
they cannot change data values, 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.
A data type may also contain attributes to support the modeling of structured data types.
DataType is implicitly a subclass of InfrastructureLibrary::Core::Constructs::DataTypes::DataType.
Attributes
62
DataType
Associations
ownedAttribute: Attribute
The Attributes owned by the DataType. This association is a concrete specialization
of the ownedMember association from Namespace to NamedElement, and the

feature association between Classifier and Feature.
ownedOperation: Operation
The Operations owned by the DataType. This association is a concrete specialization
of the ownedMember association from Namespace to NamedElement, and the

feature association between Classifier and Feature.
Constraints
Semantics
A data type is a special kind of classifier, similar to a class, whose instances are values (not objects). For example, the
integers and strings are usually treated as values. A value does not have an identity, so two occurrences of the same
value cannot be differentiated. Usually, a data type is used for specification of the type of an attribute. An enumeration type is a user-definable type comprising a finite number of values.
If a data type has attributes, then instances of that data type will contain attribute values matching the attributes.
Any restrictions on the capabilities of data types, such as constraining the types of their attributes or disallowing the
use of composition associations, is a semantic variation point.
Notation
A data type is denotated using the rectangle symbol with keyword dataType or, when it is referenced by e.g. an
attribute, denoted by a string containing the name of the data type.
The attribute compartment is often suppressed, especially when a data type does not contain attributes. The operation
compartment 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.
Additional compartments may be supplied 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, although more complicated formats are also possible. Appearance of each
compartment should preferably be implicit based on its contents. Compartment names may be used, if needed.
A data-type symbol with a stereotype icon may be collapsed to show just the stereotype icon, with the name of
the data type either inside the rectangle or below the icon. Other contents of the data type are suppressed.
Style Guidelines
Center the name of the data type in boldface.
Center keyword (including stereotype names) in plain face within guillemets above data-type name.
For those languages that distinguish between uppercase and lowercase characters, capitalize names (i.e, begin
them with an uppercase character).
Left justify attributes and operations in plain face.
Begin attribute and operation names with a lowercase letter.
Show full attributes and operations when needed and suppress them in other contexts or references
63
Enumeration
Examples
dataType
Integer
size: Integer
Figure 1-33. Notation of data type: to the left is an icon denoting a data type and to the right is a reference to a data
type which is used in an attribute.
Enumeration
An enumeration is a data type whose instances are enumerated in the model.
Description
An enumeration defines a kind of data type. Each instance of an enumeration is modeled as an enumeration value.
Enumeration is implicitly a subclass of InfrastructureLibrary::Core::Constructs::DataTypes::Enumeration.
Attributes
Associations
Constraints
[1] The enumeration literals for this enumeration are all EnumerationValues that have this enumeration as their classifier.
literal = EnumerationValue.allInstances->select(i | i.classifier = self)
Semantics
The run-time instances of an Enumeration are data values. Each such value corresponds to exactly one EnumerationValue.
Notation
An enumeration may be shown using the classifier notation (a rectangle) with the keyword <<enumeration>>. The
name of the enumeration is placed in the upper compartment. A compartment listing the attributes for the enumeration is placed below the name compartment. A compartment listing the operations for the enumeration is placed
below the attribute compartment. A list of enumeration values may be placed, one to a line, in the bottom compartment. The attributes and operations compartments may be suppressed, and typically are suppressed if they would be
empty.
Enumeration values may also be shown separately from the enumeration symbol using instance notation. If the enumeration values are shown using instance notation, then the enumeration values compartment for enumeration symbol will usually be suppressed. See EnumerationValue.
64
EnumerationValue
Examples
enumeration
VisibilityKind
public
private
Figure 1-34. Example of an enumeration
EnumerationValue
An enumeration value is a user-defined data value for an enumeration.
Description
An enumeration value defines an element of the run-time extension of an enumeration data type.
An enumeration value has a name that can be used to identify it within its enumeration datatype. The enumeration value name is scoped within and must be unique within its enumeration. Enumeration literal names are not global
and must be qualified for general use.
EnumerationValue is implicitly a subclass of InfrastructureLibrary::Core::Constructs::DataTypes::EnumerationValue.
Attributes
Associations
classifier: Enumeration
The Enumeration that this EnumerationValue is a member of. This association is a

concrete specialization of the classifier association from InstanceSpecification to
Classifier.
Constraints
Semantics
An EnumerationValue is an instance specification and may appear in models to define an instance of an Enumeration.
The run-time values corresponding to enumeration literals can be compared for equality.
Notation
An EnumerationValue is typically shown, one to a line, in the middle compartment of the enumeration notation.
If an EnumerationValue is defined in a different namespace than the enumeration, then it may still be displayed
as part of a enumeration notation, with an arrowhead in a box adornment in the top right corner of the enumeration
symbol to indicate that this is an extension of an enumeration defined elsewhere. See the examples section below.
An EnumerationValue may also be shown using instance notation with the addition of the <<literal>> keyword.
65
PrimitiveType
Examples
<<enumeration>>
VisibilityKind
package
Figure 1-35. Extending an enumeration.
<<enumeration>>
Visibility Kind
<<literal>>
public : VisibilityKind
Figure 1-36. Extending an enumeration.
PrimitiveType
A primitive type defines a predefined data type, without any relevant substructure (i.e. it has no parts). A primitive
datatype may have an algebra and operations defined outside of UML, for example, mathematically.
Description
The run-time instances of a primitive type are data values. The values are in many-to-one correspondence to mathematical elements defined outside of UML (for example, the various integers).
The instances of primitive type used in UML itself include Boolean, Integer, and String (see Chapter 2, Foundation::PrimitiveTypes).
PrimitiveType is implicitly a subclass of InfrastructureLibrary::Core::Constructs::DataTypes::PrimitiveType.
Attributes
No addtional attributes.
Associations
Constraints
Semantics
Instances of primitive types do not have identity. If two instances have the same representation, then they are indistinguishable.
Notation
Instances of the predefined primitive types (see Chapter 2, Foundation::PrimitiveTypes) may be denoted with the
same notation as provided for references to such instances (see the subtypes of LiteralBoolean on page 22).
66
1.2 The Instances diagram
Examples
See Chapter 2, Foundation::PrimitiveTypes for examples.
1.2. The Instances diagram
AutonomousElement
Element
+owningInst ance
+slot
[owner]
[ownedElement]
1
Slot
*
StructuralFeature
+definingFeature
0..1
Classifier
1.. *
+specification
[ownedElement] ValueSpecification
+classifier
0..1
0..1
+instanc e
1
InstanceValue
*
+value
[ownedElement]
* {ordered}
Figure 1-37. The Instances diagram of the Kernel package.
An instance specification is a model element that represents an instance in a modeled system.
Description
An instance specification specifies existence of an entity in a modeled system and completely or partially describes
the entity. The description includes:
Classification of the entity by one or more classifiers of which the entity is an instance. If the only classifier specified is abstract, then the instance specification only parially describes the entity.
The kind of instance, based on its classifier or classifiers for example, an instance specification whose classifier is a class describes an object of that class, while an instance specification whose classifier is an association
describes a link of that association.
Specification of values of structural features of the entity. Not all structural features of all classifiers of the
instance specification need be represented by slots, in which case the instance specification is a partial description.
Specification of how to compute, derive or construct the instance (optional).
InstanceSpecification is a concrete class.
InstanceSpecification is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Instances::InstanceSpecification.
67
Attributes
Associations
classifier : Classifer [1..*]
The classifier or classifiers of the represented instance. If multiple classifiers are

specified, the instance is classified by all of them.
slot : Slot [*]
A slot giving the value or values of a structural feature of the instance. An

instance specification can have one slot per structural feature of its classifiers,
including inherited features. It is not necessary to model a slot for each structural
feature, in which case the instance specification is a partial description. Specializes Element.ownedElement.
specification : ValueSpecification [0..1]A specification of how to compute, derive, or construct the instance. Specializes Element.ownedElement.
Constraints
[1] The defining feature of each slot is a structural feature (directly or inherited) of a classifier of the instance specification.
self.slot->forAll(s | self.classifier.feature->includes(s.definingFeature) or
self.allParents().feature->includes(s.definingFeature))
[2] One structural feature (including the same feature inherited from multiple classifiers) is the defining feature of at
most one slot in an instance specification.
self.classifier.allStructuralFeatures().slot->
forAll(s1, s2 | s1.owningInstance = s2.owningInstance implies s1 = s2)
[1] The query allStructuralFeatures() gives for each classifier the list of structural features it contains directly or
through inheritance.
Classifier::allStructuralFeatures: Set(StructuralFeature)
allStructuralFeatures = self.inheritedMember->union(self.feature)
Semantics
An instance specification may specify the existence of an entity in a modeled system. An instance specification may
provide an illustration or example of a possible entity in a modeled system. An instance specification describes the
entity. These details can be incomplete. The purpose of an instance specification is to show what is of interest about
an entity in the modeled system. The entity conforms to the specification of each classifier of the instance specification, and has features with values indicated by each slot of the instance specification. Having no slot in an instance
specification for some feature does not mean that the represented entity does not have the feature, but merely that the
feature is not of interest in the model.
An instance specification can represent an entity at a point in time (a snapshot). Changes to the entity can be
modeled using multiple instance specifications, one for each snapshot.
68
Note: When used to provide an illustration or example of an entity in a modeled system, an InstanceSpecification class does not depict a precise run-time structure. Instead, it describes information about such structures. No conclusions can be drawn about implementation detail of run-time structure. When used to specify
the existence of an entity in a modeled system, an instance specification represents part of that system.
Instance specifications can be modeled incompletely required structural features can be omitted, and classifiers of an instance specification can be abstract, even though an actual entity would have a concrete classification.
Notation
An instance specification is depicted using the same notation as its classifier, but in place of the classifier name
appears an underlined concatenation of the instance name (if any), a colon (:) and the classifier name or names. If
there are multiple classifiers, the names are all shown separated by commas. Classifier names can be omitted from a
diagram.
If an instance specification has a value specification as its specification, the value specification is shown either
after an equal sign (=) following the name, or without an equal sign below the name. If the instance specification is
shown using an enclosing shape (such as a rectangle) that contains the name, the value specification is shown within
the enclosing shape.
streetName: String
"S. Crown Ct."
Figure 1-38. An instance of String.

Slots are shown using similar notation to that of the corresponding structural features. Where a feature would be
shown textually in a compartment, a slot for that feature can be shown textually as a feature name followed by an
equal sign (=) and a value specification. Other properties of the feature, such as its type, can optionally be shown.
myAddress: Address
streetName = "S. Crown Ct."
streetNumber : Integer = 381
Figure 1-39. Slots with values.

An instance specification whose classifier is an association represents a link and is shown using a the same notation
as for an association, but the solid path or paths connect instance specifications rather than classifiers. It is not necessary to show an underlined name where it is clear from its connection to instance specifications that it represents a
link and not an association. End names can adorn the ends. Navigation arrows can be shown, but if shown, they must
69
InstanceValue
agree with the navigation of the association ends..
Don : Person
father
son
Josh : Person
Figure 1-40. Instance specifications representing two objects connected by a link.

Presentation Option
A slot value for an attribute can be shown using a notation similar to that for a link. A solid path runs from the owning
instance specification to the target instance specification representing the slot value, and the name of the attribute
adorns the target end of the path. Navigability, if shown, must be only in the direction of the target.
InstanceValue
An instance value is a value specification that identifies an instance.
Description
An instance value specifies the value modeled by an instance specification.
Attributes
Associations
instance: InstanceSpecification [1]The instance that is the specified value.
Constraints
Semantics
The instance specification is the specified value.
Notation
An instance value can appear using textual or graphical notation. When textual, as can appear for the value of an
attribute slot, the name of the instance is shown. When graphical, a reference value is shown by connecting to the
instance. See InstanceSpecification.
Slot
A slot specifies that an entity modeled by an instance specification has a value or values for a specific structural feature.
Description
A slot is owned by an instance specification. It specifies the value or values for its defining feature, which must be a
structural feature of a classifier of the instance specification owning the slot.
70
Slot
Slot is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Instances::Slot.

Attributes
Associations
definingFeature : StructuralFeature [1]

The structural feature that specifies the values that may be held by the slot.
owningInstance : InstanceSpecification [1]

The instance specification that owns this slot. (Specializes Element.owner)
value : InstanceSpecification [* ordered]

The value or values corresponding to the defining feature for the owning instance
specification.
Constraints
Semantics
A slot relates an instance specification, a structural feature, and a value or values. It represents that an entity modeled
by the instance specification has a structural feature with the specified value or values. The values in a slot must conform to the defining feature of the slot (in type, multiplicity, etc.).
Notation
See InstanceSpecification on page 67.
71
1.3 The Packages diagram
1.3. The Packages diagram
PackagingNamespace
Aut onomousElement
MemberImport
[elementImport]
+elementImport
Package
0..1
ElementImport
*
+packageImport
[ import]
0..1
+importedPackage
[importedNamespace]
1
PackageImport
+extendingPackage
[source, owner]
+packageExtension
[ownedElement]
PackageExt ension
*
+extendedPackage
[target]
1
Figure 1-41. The Packages diagram of the Kernel package.
Package
A package is used to group elements, and provides a namespace for the grouped elements.
Description
A package is a packaging namespace for its members. A package may contain other packages. Apart from its owned
members, all of which are autonomous elements, a package may also have package imports to other packages, or element imports to autonomous elements (or their aliases) of other packages.
A package can own package extensions, which define the ability to incrementally build on the contents of other
packages.
Package is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Packages::Package and InfrastructureLibrary::Core::Constructs::PackageExtensions::Package.
72
Package
Attributes
Associations
elementImport: ElementImport References the ElementImports owned by the Package. The association is a specialization of the elementImport association from PackagingNamespace to
Imports::ElementImport.
packageImport: PackageImportReferences the PackageImports that are owned by the Package. The association
is a specialization of the import association from PackagingNamespace to MemberImport.
packageExtension: PackageExtensionReferences the PackageExtensions that are owned by the Package. The
Element.
Constraints
[1] If an element that is owned by a package has visibility, it is public or private.
self.ownedElements->forAll(e | e.visibility->notEmpty() implies e.visbility = #public or e.visibility = #private)
[1] The query mustBeOwned() indicates whether elements of this type must have an owner.
Package::mustBeOwned() : Boolean
mustBeOwned = false
[1] The query visibleMembers() defines which members of a Package can be accessed outside it.
Package::visibleMembers() : Set(AutonomousElement);
visibleMembers = member->select( m | self.makesVisible(m))
[2] The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no
visibility and elements with public visibility are made visible.
Package::makesVisible(el: Namespaces::NamedElement) : Boolean;
pre: self.member->includes(el)
makesVisible = el.visibility->isEmpty() or el.visibility = #public
Semantics
A package is a packaging namespace and is also an autonomous element that can be contained in other packaging
namespaces.
The elements that are directly available by name for use within a package are owned elements, imported elements, and elements in enclosing (outer) namespaces. Owned and imported elements may each have a visibility that
determines whether they are available outside the package.
A package cannot be instantiated. A package owns its owned members, with the implication that if a package is
removed from a model, so are the elements owned by the package.
The public contents of a package is always accessible through the use of qualified names.
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. The members of the package may be shown within the large rectangle. Members may also be shown by
branching lines to member elements, drawn outside the package. A plus sign (+) within a circle is drawn at the end
attached to the namespace (package).
73
PackageExtension
If the members of the package are not shown within the large rectangle, then the name of the package should be
placed within the large rectangle.
If the members of the package are shown within the large rectangle, then the name of the package should be
placed within the tab.
The visibility of a package element may be indicated by preceding the name of the element by a visibility symbol (+
for public and - for private).
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, e.g., only public elements. 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.
Elements that become available for use in a importing package through a package import or an element import
may have a distinct color or be dimmed to indicate that they cannot be modified.
Examples
There are three representations of the same package Types in Figure 1-42. The one on the left just shows the package
without revealing any of its members. The middle one shows some of the members within the borders of the package,
and the one to the right shows some of the members using the alternative membership notation.
Types
Types
Types
Integer
Time
Shape
Point
Figure 1-42. Examples of a package with members

See PackageExtension on page 74.
PackageExtension
A package extension defines how one package extends other packages by merging their contents.
Description
A package extension is the relationship between an extending package and a package being extended.
PackageExtension is implicitly a subclass of InfrastructureLibrary::Core::Constructs::PackageExtensions::PackageExtension.
Attributes
74
PackageExtension
Associations
extendedPackage: Package [1] References the Package that is extended by an extending Package through the
PackageExtension. The association is a specialization of the target association
from DirectedRelationship to Element.
extendingpackage: Package
References the Package that is extending another Package through the PackageExtension. The association is a specialization of the source association from
DirectedRelationship to Element and of the owner association from Element to
Element.
Constraints
Semantics
A package extension between two packages implies a set of expansions, where the contents of the extended package
is expanded in the extending package. Each element has its own specific expansion rules.
An element with private or package visibility in the extended package is not expanded in the extending package.
This applies recursively to all owned elements of the extended package.
A classifier from an extended package expands to a classifier with the same name in the extending package if it
does not already contain a (non-expanded, i.e., explicit) classifier of the same kind with the same name. In the former
case, the expanded classifier has an expanded generalization to the classifier from the extended package and
expanded generalizations to each superclass of the classifier from the extended package as expanded or explicitly
specialized in the extending package, if any. In the latter case, the (non-expanded) classifier has an expanded generalization to the classifier from the extended package. Classifiers of the same kind with the same name from multiple
extended packages expand to a single classifier in the extending package with expanded generalizations to each such
classifier in the extended packages. Each nested classifier is recursively expanded the same way.
Note: If features from multiple classifiers are somehow conflicting, the same rules that apply for multiple
inheritance are used.
A subpackage from an extended package is expanded to a subpackage with the same name in the extending package if it does not already contain a (non-expanded) subpackage with the same name. In the former case, the expanded
subpackage has an expanded package extension to the subpackage from the extended package. In the latter case, the
(non-expanded) subpackage has an expanded package extension to the subpackage from the extended package. Subpackages with the same name from multiple extended packages expand to a single subpackage in the extending package with expanded package extensions to each such subpackage in the extended packages. Each nested subpackage is
recursively expanded the same way.
A member import owned by an extended packaging namespace is in the extending package expanded to the same
kind of member import referring to the same target packaging namespace or its expansion.
An element import owned by an extended packaging namespace is in the extending package expanded to an element import referring to the same target autonomous element or its expansion.
An autonomous element owned by an extended package that does not have a specific rule is expanded as a copy
in the extending package.
75
PackageExtension
Notation
A PackageExtension is shown using a dashed line with a stick arrowhead pointing from the extending package (the
source) to the extended package (the target). In addition, the keyword extend is shown near the dashed line.
Target
extend
Source
Figure 1-43. Notation for package extension.

Examples
A simple case of package extension is shown in Figure 1-44, where an empty Buildings package extends a Units
package.
Units
player
Player
unit
Unit
*
*
name: String
armor: Integer
Building
Warrior
extend
Buildings
Figure 1-44. An empty package extending another package.

This basically means that the contents of the Units package is available in the Buildings package; the Buildings
package will have a number of expanded generalizations defined in such a way that Buildings::Unit specializes
Units::Unit, Buildings::Player specializes Units::Player, Buildings::Warrior specializes Units::Warrior, and Buildings::Building specializes Units::Building. In addition, the association is specialized in the Buildings package. This,
however, is not enough. The expanded classes Buildings::Warrior and Buildings::Building also specializes the
locally defined Buildings::Unit. The implied expansion of the package extension is shown in Figure 1-45. Since we
76
PackageExtension
make no changes to any of the elements, these derived elements are normally not shown in a diagram, and the Buildings package would be shown as empty.
Buildings
player
Units::
Unit
Units::
Player
unit
*
name: String
armor: Integer
Unit
{expanded}
unit
[unit]
player
[player]
Player
{expanded}
*
*
Units::
Warrior
Units::
Building
Building
Warrior
{expanded}
{expanded}
Figure 1-45. The expanded Buildings package.
Note: Cases where the differences between package extension and package import become apparent are
shown in subsequent examples. Somewhat simplified, an extending package gets the same contents as the
packages being extended, and it is allowed to add features to its contained elements. Had package import
been used instead, any additions to an imported element would have been made to the original definition in
the imported package.
77
PackageExtension
In the example shown in Figure 1-46, the Sales package extends both the Factories and Insurance packages. In addition, it contains an explicit definition of Car that subclasses Factories::Car.
Factories
Vehicle
Insurances
insurance
Vehicle
Car
0..1
Insurance
-value: Integer
extend
extend
Sales
Factories::
Car
Car
price: Integer
Figure 1-46. A package with explicit definitions extending another packages.

The expansion of the Sales package is shown in Figure 1-47. Note that the class Sales::Car is not a subclass of
the expanded class Sales::Vehicle because of the explicit specialization of the class Factories::Car. Furthermore, the
attribute value is not available in the class Sales::Car.
78
PackageExtension
Factories
Vehicle
Insurances
insurance
Vehicle
Car
0..1
Insurance
-value: Integer
extend
extend
Sales
Factories::
Vehicle
Insurances::
Vehicle
insurance
Factories::
Car
Insurance
Car
0..1
insurance
[insurance]
Vehicle
Insurances::
Insurance
{expanded}
{expanded}
0..1
price: Integer
Figure 1-47. The expanded Sales package.

In the example shown in Figure 1-48 a few features are added to the class Buildings::Building. This means that
this class is not expanded, but actually defined in the namespace of Buildings. However, since it has the same name as
the corresponding class in Units, which is extended by Buildings, the Units::Building will be specialized with Build-
79
PackageExtension
ings::Building through a generalization relationship. Note that only the additions are shown in package Buildings; the
rest of its contents is implied by the package extension relationship between the packages.
Units
Buildings
player
Player
unit
Unit
Unit
extend
createdUnit
name: String
armor: Integer
Produces
Building
Building
Warrior
capacity: Integer
0..1
Figure 1-48. Adding features to a class.

The expanded Buildings package is shown in Figure 1-49.
Buildings
player
Units::
Unit
Units::
Player
unit
*
name: String
armor: Integer
unit
[unit]
createdUnit
player
[player]
Player
{expanded}
Unit
*
*
Produces
Units::
Warrior
Units::
Building
Building
0..1
Warrior
{expanded}
capacity: Integer
Figure 1-49. The expanded Buildings package.

(If package import had been used instead of package extension in Figure 1-48, then the Buildings::Building class
would hide the imported Units::Building, and the two definitions be completely unrelated and type incompatible.)
80
PackageImport
PackageImport
A package imports allows one package to import the members of another package, thereby making it possible to refer
to elements of the imported package as if they were defined in the importing package (i.e., without using qualified
names).
Description
A package import is a kind of member import that can only be owned by packages. Additionally, a package import is
only capable of importing the members of other packages, but not from any other packaging namespace.
PackageImport is implicitly a subclass of InfrastructureLibrary::Core::Constructs::Packages::PackageImport.
Attributes
visibility: VisibilityKind [0..1] Specifies the visibility of the imported AutonomousElements within the importing Package, i.e., whether imported elements will in turn be visible to other packages that use that importingPackage as an importedPackage. If the
PackageImport is public, the imported elements will be visible outside the package, while if it is private they will not. By default, the value of visibility is public.
Associations
importedPackage: Package [1] References the Package that is being imported by an importing Package through
the PackageImport. The association is a concrete specialization of the importedNamespace association from MemberImport to Namespace.
Constraints
[1] The visibility of an PackageImport is either public or private.
Semantics
Notation
A package import is shown using a dashed arrow with an open arrowhead from the importing package to the imported
package. A keyword is shown near the dashed arrow to identify which kind of package import that is intended. The
predefined keywords are import for a public package import , and use for a private package import.
As an alternative to the dashed arrow, it is possible to show an element import by having a text that uniquely identifies the imported element within curly brackets either below or after the name of the namespace. The textual syntax is
then:
{import <qualifiedName>} or {use <qualifiedName>}
Examples
In Figure 1-50, examples of public and private package imports are shown. The elements defined within package
Types are imported to the package ShoppingCart. Since the package import is public, the imported elements will be
further imported to the package WebShop. The elements defined in the package AuxiliaryTypes, however, are pri-
81
PackageImport
vately imported to the package ShoppingCart and will not be available for use without qualification in package WebShop.
Types
AuxiliaryTypes
use
import
ShoppingCart
import
WebShop
Figure 1-50. Examples of public and private package imports
82
2 Foundation::PrimitiveTypes
2.1 PrimitiveTypes package
Chapter 2. Foundation::PrimitiveTypes
The PrimitiveTypes package of UML::Foundation contains a number of predefined types used when defining the
abstract syntax of metamodels.
Core
PrimitiveTypes
import
Foundation
PrimitiveTypes
Figure 2-51. The PrimitiveTypes package is owned by the Foundation package.

The package Foundation::PrimitiveType simply imports the package Core::PrimitiveTypes, and does not modify
its contents in any way.
2.1. PrimitiveTypes package

The PrimitiveTypes subpackage within the Core package defines the different types of primitive values that are used
to define the Core metamodel. It is also intended that every metamodel based on Core will reuse the following primitive types.
In Core and the UML metamodel, these primitive types are predefined and available to the Core and UML extensions at all time. These predefined value types are independent of any object model and part of the definition of the
Core.
Integer
Boolean
String
Figure 2-52. The classes defined in the PrimitiveTypes package.

The abstract syntax of Foundation::PrimitiveTypes is shown in Figure 2-52, and the types are described in the .
Foundation-PrimitiveTypes.fm Version 2 beta R1September 9, 2002 11:33 am
83
2 Foundation::PrimitiveTypes
Foundation-PrimitiveTypes.fm Version 2 beta R1September 9, 2002 11:33 am
2.1 PrimitiveTypes package
84
3 Foundation::Profiles
Chapter 3. Foundation::Profiles
The Profiles package of the Foundation contains mechanisms that allow metaclasses from existing metamodels to be
extended to adapt them for different purposes. This includes the ability to extend the UML metamodel in order to tailor the language for different platforms (such as J2EE or .NET) or domains (such as real-time or business process
modeling). The profiles mechanism is consistent with the OMG Meta Object Facility (MOF).
As is shown in Figure 3-53, the package Foundation::Profiles imports the package InfrastructureLibrary::Profiles.
InfrastructureLibrary
Profiles
import
Foundation
Profiles
Figure 3-53. The Profiles package is owned by the InfrastructureLibrary package.
Foundation-Profiles.fm Version 2 beta R1 September 9, 2002 11:33 am
85
3 Foundation::Profiles
3.1 Profiles package
3.1. Profiles package

The classes of the Profiles package are depicted in Figure 3-54, and are specified in the Profiles on page 6-125 of
.the UML 2.0: Infrastructure.
Pac k age
P ac k ageImport
Clas s
Aggregation
(fro m P a c ka g es)
(fro m P a cka ge s)
(fro m Cla sse s)
(f ro m A g g re g at io n s)
+aggregateEnd
[end]
+appliedProfile
ProfileApplic ation
[pack ageImport]
Pac kage
1
Clas s
+metac las s
+ ex te ns io n
/
A s s oc iationEnd
(fro m A sso ci atio ns)
0..1
+partEnd
[ par tEnd]
E x tens ion
Ex tensionE nd
+ / is Required : Boolean
*
1
*
+importedProfile
[importedPack age]
Profile
1
+ownedStereoty pe
[ownedM ember]
1
*
+metac las s Referenc e
[elem entImport]
Stereoty pe
+t ype
[ty pe]
1
Elem entImport
(f rom P ac ka g es)
0..1
*
+metam odelReference
[pac k ageImport]
0..1
Pac k ageIm port

(f rom P ac ka g es)
Figure 3-54. The classes defined in the Profiles package.
Foundation-Profiles.fm Version 2 beta R1 September 9, 2002 11:33 am
86
Part I. UML::Basic
This part describes the package structure and contents of the UML::Basic package, which defines the basic constructs
used to specify Classes, Interactions and Use Cases. The Basic package is one of the top-level packages that defines
the UML. The relationship of the Basic package to the other top-level packages is shown in Figure 3-55.
UML
Complete
import
Common
import
Basic
import
Foundation
Figure 3-55. The Basic package is owned by the UML package.
Part-Basic.fm Version 2 beta R1
87
3 UML::Basic
The Basic package, which imports the Foundation package, consists of the subpackages shown in Figure 3-56.
Kerne l
(from Foundation)
Dependencies
Interfaces
CommonBehaviors
InternalStructures
UseCases
Act ion s
In teract ion s
Figure 3-56. The contents of the Basic package.

The function and contents of these packages are described in separate chapters, corresponding to each package.
Part-Basic.fm Version 2 beta R1
88
Chapter 4. Basic::Actions
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 values that are the inputs to an action may be obtained from the results of other actions
or they may be described by instance specifications. 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.
Kernel
(from Foundation)
Common
Behavior
Actions
Figure 4-57. Dependencies of the Basic::Actions package
Actions are contained in procedures, which provide their context. An action execution corresponds to the individual execution of a particular action within a procedure. Similarly, a procedure execution is the individual execution of a procedure, ultimately including the executions of actions within it. Each action in a procedure may execute
zero, one, or more times for each procedure execution. Execution is not instantaneous, but takes place over a period
of time. The UML does not provide for the specification of time, but only describes sequences of occurrences. Procedures and other groupings of actions must be executed in a number of steps, including control of the execution of
nested actions.
At the minimum, actions need access to data, they need to transform and test data, and actions may require
sequencing. This specification 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. However, the fact that the UML 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 sequentiallyso long as the behavior of the implementation is the same as the
specification.
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. This
mapping need not be one-to-one: an implementation need not even use object-orientation, 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.
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, primitive actions are defined so that they either carry out a
computation or access object memory, and never both. This approach enables clean mappings to a physical model,
Actions.fm Version 2 alpha R4
2-89
4 Basic::Actions
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 higherlevel, composite constructs to offer the modeler both power and convenience.
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. Modelers can work in terms of higher-level constructs as provided by their chosen
surface language or notation.
The semantic primitives are defined to enable the construction of different 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 couldby designbe 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 modelers assertion is true.
The actions defined in this package perform operation calls and signal sends (including both transmissions to
specific targets and broadcasts to the available universe). Operations are specified in the model and can be dynamically selected only through polymorphism. Signals are specified by a signal object, whose type represents the kind of
message transmitted between objects, and can be dynamically created.
2-90
4.1. Class Descriptions

Pin
(from CommonBehaviors)
Action
ValueSpecificat ion
(from Kernel)
* +input
{ordered} [ ownedElement]
[ownedElement]
+action
Action
isReadOnly : Boolean
+predec essor
+output
InputPin
Output Pin
{ordered} *
+action
+inputPin
[input]
1
ControlFlow
0..1
*
+successor
PrimitiveA ct ion
Figure 4-58. The framework for defining actions.
Parameter
Parameter
0..1
InputPin
+argument
DataFlow
+destination
OutputPin
+source
Figure 4-59. Data flow between actions and from input parameters.
ValueSpecification
(from Kernel)
+argument
[input]
OutputPin
*
{ordered}
+argum ent
[input]
(from Kernel)
+argument
[input]
0..1
0..1
1
+operation
Operation
(from Kernel)
+target
[input]
+ targe t
[input]
ValueSpecification
(f ro m Ke rne l)
+signal
+target [in put]
SendObjectAction
+signal
Signal
*
{ordered}
BroadcastSignal
Action
isAsynchronous : Boolean
+result
[output]
ValueSpecification
*
{ordered}
SendSignalAction
Ca llOperat io nActi on
{ordered}
PrimitiveAction
ValueSp ecifi ca tion

(from Kernel)
+request
[input]
ValueSpecification
(f rom K ern el)
Figure 4-60. The messaging actions.
Action (extended)
2-91
4 Basic::Actions
Action (extended)
Description
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.
A control flow indicates an ordering constraint between a predecessor action and a successor action. 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 ordering of the execution actions that require such constraints. The
successor action of the control flow may not execute until the predecessor action has completed execution.
Note: Most programming languages have implicit control flows between each statement, thus overspecifying 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 is available at the source value denotation. Control sequencing is implicit between actions
connected by data flows; it is unnecessary to include explicit control flows between such actions.
Actions connected by data and control flows form an acyclic directed graph as an action cannot be both a predecessor and successor of another action.
Attributes
isReadOnly : Boolean
If true, 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
inputPin : InputPin [*]
The ordered set of input pins owned by the action. (Specializes Action.input.)
output : OutputPin [*]
The ordered set of output pins owned by the action, through which the action will
supply result values to other consumers.
predecessor : Action
The set of actions whose execution must be completed before this action can execute.
successor : Action
The set of actions that cannot begin execution until this action completes its execution.
Operations
[1] 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.destination.action
>union((self.successor>union(self.group.successor))
>collect(a : Action | a.subactions()>including(a)))>asSet()
[2] 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-92
Constraints
[1] There must be no cycles in the graph of actions, where a cycle is defined as a path that begins and ends at the
same action and a path is constructed from the control flow and data flow associations between actions, with control flows traversed from predecessor action to successor action and data flows traversed from the action via its
source output pin to a destination input pin of the target action.
not self.allSuccessors()>includes(self)
Semantics
An action execution represents the general run-time behavior of executing an action within a specific context. As
Action is an abstract class, all action executions will be executions of specific kinds of actions. No restriction is
placed on the relative execution order of two or more actions, unless they are explicitly constrained by flow relationships. Hence every action within a procedure may execute at once, though a specific execution engine may choose to
perform the executions sequentially or in parallel.
[1] An action execution is created with its pins uninitialized. The action has the same procedural context as the action
execution that created it. All action executions within a procedural execution share the same procedural context,
that is, they share access to the same data that is visible in the procedural context.
[2] An action execution becomes enabled when all its data flow and control flow prerequisites have been satisfied.
The data flow prerequisite is satisfied when all the input pins of the action hold a value. The control flow prerequisite is satisfied when all the predecessor action executions have completed.
[3] An enabled action execution may begin its execution. An action need not begin executing immediately upon
being enabled.
[4] An action continues executing until it has completed. The detailed semantic of executing an action depends on
the particular kind of action.
When completed, an action execution produces values on all its output pins and terminates. The action execution satisfies the control flow or data flow prerequisites for any other action execution that depends on it or on one of the values it produces. After an action execution has terminated and its output values have been transferred either to input
pins of other actions connected through dataflows or have been returned as the result of a procedure invocation, the
values held in the pins of an action become inaccessible. A terminated action execution cannot be restarted or affect
any further computation in any way.
Notation
None.
Examples
None.
Rationale
Not applicable.
Changes from UML 1.x
This metaclass has been refined from 1.x.
2-93
4 Basic::Actions
BroadcastSignalAction
BroadcastSignalAction
Description
Creates a request signal instance, a copy of which is transmitted to all the potential target objects in the system, which
may cause the firing of a state machine transitions or the execution of associated procedures of a target object. The
argument values are available to the execution of associated behaviors. The requestor continues execution immediately. Any reply messages are ignored and are not transmitted to the requestor.
The determination of the set of broadcast target objects is a semantic variation point. Attributes
None
Associations
argument: InputPin [0..*]
A list of values that represent the data to be communicated by the signal to the
target objects of the broadcast in the system.The arguments must correspond to
the attributes of the specified signal type.
signal: Signal [1]
The specification of signal object transmitted to the target objects.
Constraints
[1] The number of argument pins and the number of attributes in the signal must be equal.
[2] The type, ordering, and multiplicity of an argument pin is derived from the corresponding attribute of the signal.
Semantics
[1] When all the control and data flow prerequisites of the action execution are satisfied, a signal object is generated
from the argument values according to signal and this signal object is transmitted concurrently to each of the
implicit broadcast target objects in the system. The manner of identifying the set of objects that are broadcast targets is a semantic variation point and may be limited to some subset of all the objects that exist. The target
objects may be local or remote. The manner of transmitting the signal object, the amount of time required to
transmit it, the order in which the transmissions reach the various target objects, and the path for reaching the target objects are undefined.
[2] When a transmission arrives at a target object, it may invoke behavior in the target object. The effect of receiving
a signal object is specified in Chapter 15, Common::CommonBehaviors; normally it involves the firing of a
state machine transition or the execution of an associated procedure. Copies of the argument values (the
attributes of the signal object) are available to the invoked behavior.
[3] A broadcast signal action receives no reply from the invoked behavior; any attempted reply is simply ignored,
and no transmission is performed to the requestor.
Semantic Variation Point
The determination of the set of broadcast target objects of a broadcast is unspecified in the general model.
Notation
None
Examples
None
Rationale
Sends a signal to a set of system defined target objects.
2-94

These features did not exist in UML 1.4 but were added in the Action Semantics specification.
CallOperationAction
Description
Transmits an operation call request to the target object, where it may cause the invocation of associated behavior. The
argument values of the action are available to the execution of the invoked behavior. The execution of the call operation action waits until the execution of the invoked behavior completes and a reply transmission is returned to the
caller. Any values returned as part of the reply transmission are copied into the result output pins of the call operation
action. Upon receipt of the reply transmission, execution of the call operation action is complete.
Attributes
isSynchronous: Boolean
If true, the call is synchronous and the caller waits for completion of the invoked
behavior and the receipt of a reply transmission from the invoked behavior. If
false, the call is asynchronous and the caller proceeds immediately and does not
expect a reply; any reply is ignored and no transmission is performed.
Associations
A list of values that are the arguments to be communicated to the recipient of the
request.
operation: Operation [1]
The operation to be invoked by the action execution
result: OutputPin [0..*]
A list of output pins that receive the output values generated by the invoked
behavior (including return parameters, out parameters, and in-out parameters).
target: InputPin [1]
The target object to which the request is sent. The classifier of the target object is
used to dynamically determine a behavior to invoke. This object constitutes the
context of the execution of the operation.
Constraints
[1] The number of argument pins and the number of formal parameters of the operation of type in and in-out must be
equal.
[2] The number of result pins and the number of formal parameters of the operation of type return, out, and in-out
must be equal.
[3] The type, ordering, and multiplicity of an argument or result pin is derived from the corresponding formal parameter of the operation.
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 representing and transmitting the call information, the
amount of time required to transmit it, and the path for reaching the target object are undefined.
[2] If the call is asynchronous, the caller proceeds immediately and the execution of the call operation action is complete. If the call is synchronous, the caller is blocked from further execution until it receives a reply from the
invoked behavior.
2-95
4 Basic::Actions
InputPin
[3] When a transmission arrives at a target object, it may invoke a behavior in the target object. The effect of receiving such transmission is specified in Chapter 15, Common::CommonBehaviors; normally it involves the firing
of a state machine transition or the execution of an associated procedure. Copies of the argument values are
available to the invoked behavior.If the call is synchronous, when the execution of the invoked behavior completes, its return results are transmitted back as a reply to the calling action execution. The manner of transmitting the reply, the time required for transmission, the representation of the reply transmission, and the
transmission path are unspecified. If the execution of the invoked behavior yields an exception, the exception is
transmitted to the caller where it is reraised as an exception in the execution of the calling action. Possible exception types may be specified by attaching them to the called Operation as raisedException associations.
[4] When the reply transmission arrives at the invoking action execution, copies of the return result values are placed
on the result pins of the call operation action, and the execution of the action is complete.
The mechanism for determining the method to be invoked as a result of a call operation is unspecified.
Notation
None
Examples
None
Rationale
Calls an operation on a specified target object.
This class replaces CallAction from UML 1.4. but provides essentially the same features, except for the recurrence
information inherited from Action. IsAsynchronous was replaced by IsSynchronous with the obvious reversal of
polarity. This action was refined in the Action Semantics specification.
InputPin
Description
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 pin of the data flow. Thus, inputs pins are single
assignment data holdersonce they receive a value, this value does not change. In other words, data flow allows
fan out, but not fan in.
A data flow association from a value denotation to an input pin indicates that a value (such as the output value of
an action) is used as an input value of another action. Data flows carry values from the source value denotation to a
destination action without having to store them temporarily. When a value is generated on the source value denotation, it is copied to the destination pin. A single output pin can be connected to zero or more input pins.
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 value denotation 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. The types and multiplicities of the input pins of an action are also constrained by the particular action. For example, an action that
writes to an attribute has an input pin with the type and multiplicity of that attribute.
2-96
Associations
source : OutputPin [1]
The output pin that provides the data carried by a data flow to this input pin.
Attributes
None.
Constraints
[1] The type of the source pin must be the same type as the input pin or a descendant of the source type.
if (self.source.oclType = OutputPin) self.source.type = self.destination.type or self.destination.type.allParents()
>includes(self.source.type))
[2] 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)
Semantics
An input pin may hold a value during the execution of the action owning this pin. When the action execution is
created, all input pins are initially empty, that is, they hold no value. When the source value denotation holds a
value, this value is copied into the input pin.
Notation
None.
Examples
None.
Rationale
Not applicable.
This metaclass did not exist in 1.x.
OutputPin
Description
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.
The types and multiplicities of the output pins of an action are constrained by the particular action. For example,
an action that reads a certain attribute has an output pin with the type and multiplicity of that attribute.
Associations
action : Action [0..1]
The action that owns the pin as an output.
Attributes
None.
2-97
4 Basic::Actions
Parameter (extended)
Constraints
None.
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. Output values are
assigned at the completion of execution of their action.
Notation
None.
Examples
None.
Rationale
Not applicable.
Description
Parameters may be associated with the specification of the computation to which the values corresponding to these
parameters will be delivered at run-time.
Associations
argument: InputPin
References an input pin and specifies the action to which the values passed to the
behavior upon invocation will be provided.
Attributes
None.
Constraints
[1] The same parameter may not have both a result and an argument.
[2] Only parameters with the direction attribute set to in or inout may be associated with an input pin.
Semantics
See Procedure (extended).
Notation
None.
Examples
None.
2-98
Rationale
Not applicable.
PrimitiveAction
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.
Description
A primitive action is one that does not contain any nested actions.
Associations
None.
Attributes
None.
Constraints
None.
Semantics
PrimitiveAction is an abstract metaclass.
Notation
None.
Examples
None.
Rationale
Not applicable.
Procedure (extended)
Description
The arguments supply values to the contained actions as specified by its parameters, and each parameter may be connected to zero or more inputs of its contained actions. Similarly, output pins of the contained actions may be connected to result parameters of the procedure. Each parameter must be connected to at most one output of the
2-99
4 Basic::Actions
action.The types of the actual arguments to a procedure may be descendants of the types of the formal parameters.
The types of the actual results of a procedure may be descendants of the types of the return results.
The pins on the actions contained in the procedure must match the types and multiplicities of the corresponding
parameters of the procedure to which they are connected.
Attributes
Associations
Constraints
Semantics
A procedure execution resutls from the invocation of the procedure by a call, the firing of a state machine transition,
etc. A procedure in a user model may correspond to many procedure executions over time or at the same time. Each
procedure execution is independent of any other execution of the same procedure.
A procedure execution maintains the context for all action executions within the procedure execution.
[1] When a procedure is invoked, a procedure execution is created. Then the values passed upon procedure invocation are made available and copied to the input pins of any contained action that are connected to these parameters as arguments. For each argument parameter of the procedure where no value was passed upon invocation,
values corresponding to the default of the parameter are created if a default was defined and these values are similarly passed to any connected input pin. There are no values corresponding to any other input parameters.
[2] After a procedure execution has been initialized, for each action owned by the procedure an action execution is
created and begins its execution.
[3] When its nested actions have completed their execution, all their output pins hold values. Values for such output
pins that are connected to return parameters of the procedure are made available as the output values of the procedure execution corresponding to these return parameters.
[4] Once the output values of the procedure execution are made available to their respective consumers, the procedure execution is complete.
A procedure execution acts as a context for all action executions nested directly or indirectly within it. This contextual information includes information about the context instance of the action execution.
A procedure may execute as the result of the invocation of a method or an event occurrence triggering a transition. The context of the execution is the instance that owns the invoked method or the state machine for the transition.
The context instance remains the same throughout the execution. (There is no context instance for procedures associated with a method with classifier scope.)
Notation
None.
Examples
None.
Rationale
Not applicable.
2-100

SendObjectAction
Transmits a copy of a signal object to the target object, where it may cause the firing of state machine transitions or
the execution of a procedure. The value of the request object is available to the execution of invoked behaviors.The
requestor continues execution immediately. Any reply message is ignored and is not transmitted to the requestor.
Attributes
None
Associations
request: InputPin [1]
The signal request object, a copy of which is transmitted to the target object as a
signal.
The target object to which the signal is sent.
Constraints
None.
Semantics
[1] When all the control and data flow prerequisites of the action execution are satisfied, a copy of the signal object
on the input pin is transmitted to the target object. The target object may be local or remote. The manner of transmitting the signal object, the amount of time required to transmit it, and the path for reaching the target object are
undefined, and programs should not depend on any particular set of choices.
state machine transition or the execution of an associated procedure. Thevalue of the signal object is available to
the invoked behavior.
[3] A send object action receives no reply from the invoked behavior; any attempted reply is simply ignored, and no
transmission is performed to the requestor.
Notation
None
Examples
None
Rationale
Sends a signal to a specified target object.
This metaclass has been added.
2-101
4 Basic::Actions
SendSignalAction
SendSignalAction
Creates a request signal instance which is transmitted to the target object, where it may cause the firing of a state
machine transition or the execution of a procedure. The argument values are available to the execution of associated
behaviors. The requestor continues execution immediately. Any reply message is ignored and is not transmitted to the
requestor. Attributes
None
Associations
A list of values that are the arguments of a signal to be communicated to the target object. The arguments must correspond to the attributes of the specified signal type.
signal: Signal [1]
The type of signal transmitted to the target object.
The target object to which the signal is sent.
Constraints
None.
Semantics
[1] When all the control and data flow prerequisites of the action execution are satisfied, a signal instance of the type
specified by signal is generated from the argument values and a copy of this signal instance is transmitted to the
identified target object. The target object may be local or remote. The manner of transmitting the signal instance,
the amount of time required to transmit it, and the path for reaching the target objects are undefined, and programs should not depend on any particular set of choices.
state machine transition or the execution of an associated procedure. Copies of the argument values are available
to the invoked behavior.
[3] A send signal action receives no reply from the invoked behavior; any attempted reply is simply ignored, and no
transmission is performed to the requestor.
Notation
None
Examples
None
Rationale
Sends a signal to a specified target object.
Replaces the SendAction form UML 1.4, but provides essentially the same features as refined in the Action Semantics specification.
2-102
Chapter 5. Basic::Common Behaviors

The CommonBehaviors package is the most fundamental of the subpackages that specify behavioral constructs. It
specifies the core concepts required for dynamic elements and provides the infrastructure to support more detailed
definitions of behavior.
Kernel
(from Foundation)
Com m on
Behaviors
Figure 5-61. Dependencies of the Basic::CommonBehaviors package
CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am
2-103
5 Basic::Common Behaviors
5.1 Class Description
5.1. Class Description

Classifier
(from Kernel)
+ownedBehavior
[ownedMember]
BehavioredClass ifier +context

0..1
*
+classifierBehavior
[ ownedBehavior]
0..1
BehavioralFeature
is Abs tract : Boolean
Behavior
+redefinedBehavior
[redefinedElement]
0..1
+specification
0.. 1
+method
0..1
{ordered}
Param eter
*
+formalP aramet er
*
0..1
{ordered}
+returnResult
[ paramet er, ownedMember]
+nes tedBehavior
[ ownedMember]
BehavioralFeat ure
(from Kernel)
+parameter
[member]
0..1
*
0..1
0..1
{ordered}
ReturnResult
(from Kernel)
*
+ownedAttribute
Attribute
(from Kernel)
*
Figure 5-62. Common Behavior.
BehaviorInvocation
0..1
+behavior
*
Behavior
0..1
* {ordered}
+result
+argument
Pin
+type
0..1
0..1
{ordered} *
Clas sifier
(from Kernel)
+multiplicity
0..1
0..1
Multiplicity
(from Kernel)
Figure 5-63. Invocation of a behavior.
2-104
Behavior
Expression
(from Kernel)
Procedure
Parameter
(from Kernel)
body : String [0..1]

language : String [0..1]
+formalParameter
[formalParameter]
Expression
+value
[result, default]
Parameter
ValueSpecification
(from Kernel)
0..1

0..1
+result
1
+returnResult
[returnResult]
Element
(from Kernel)
ReturnResult
(from Kernel)
Figure 5-64. Procedure.
Element
(from Kernel)
Procedure
[ownedElement]
+action
Ac tion
0..1
Figure 5-65. Action.
+prec ondition
[ownedConstraint ]
+pos tcondition
[ownedConstraint]
Behavior
Constraint
(from Kernel)
Figure 5-66. Specifying a behavior through constraints.
Action
Description
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
2-105
Behavior
action must have a fixed effect on the system state, or be performing some effect external to the system. Actions may
access or modify accessible, mutable objects, where the object to be read or written to is an input of the action or is
visible in the context of the action, including parameters and local variables of procedures.
Attributes
Associations
input: ValueSpecification [*]
The ordered set of value specifications which act as suppliers of values consumed
by the action.
Operations
No additional operations.
Constraints
Semantics
Action is an abstract metaclass. See its concrete subtypes for the definition of its behavior.
Notation
None.
Examples
None.
Rationale
Not applicable.
This metaclass has been refined from 1.x.
Behavior
Description
A behavior is the realization or implementation of a behavioral feature (such as an operation or a reception). It specifies the computation that generates the effects of the behavioral feature. There may be at most one behavior for a particular pairing of a classifier (as owner of the behavior) and a behavioral feature (as specification of the behavior).
The description of a behavior can take a number of forms: interaction, statemachine, activity, or procedure (a set
of actions). Behavior is an abstract metaclass.
As a classifier, a behavior can be specialized in subtypes. The instantiation of a behavior is referred to as invocation. When a behavior is invoked, its attributes and parameters (if any) are created and appropriately initialized.
Upon invocation, data may be passed to a behavior via its parameters.
A behavior may be invoked indirectly through invokation of the behavioral feature that specifies this behavior. It
may also be invoked directly.
2-106
Attributes
None.
Associations
specification : BehavioralFeature [ 0..1 ]

Designates a behavioral feature that the behavior implements. The behavioral feature
must be owned by the classifier that owns the behavior or be inherited by it. The parameters of the behavioral feature and the implementing behavior must match. If a behavior
does not have a specification, it is directly associated with a classifier (i.e., it is the
behavior of the classifier as a whole).
context : BehavioredClassifier [ 0..1 ]

The classifier owning the behavior. The features of the context classifier as well
as the elements visible to the context classifier are made available to the behavior. (Specializes Namespace.ownedMember.)
parameter : Parameter
References a list of parameters to the behavior which describes the order and type of
arguments that can be given when the behavior is invoked or of the values which will be
returned when the behavior completes its execution. (Specializes Namespace.member.)
formalParameter : Parameter
References a list of parameters to the behavior which describes the order and type of
arguments that can be given when the behavior is invoked. (Specializes
Namespace.ownedMember and Behavior.parameter.)
returnedResult : ReturnResult
References a sequence of parameters to the behavior which describes the order and
type of values that will be returned when the behavior terminates. (Specializes
Namespace.ownedMember and Behavior.parameter.)
ownedAttribute : Attribute
References the attributes owned by the behavior. (Specializes Classifier.feature

and Namespace.ownedMember.) An attribute allows representation of data local
to a behavior.
redefinedBehavior : Behavior References a behavior that this behavior redefines. A subtype of behavior may
redefine any other subtype of behavior. If the behavior implements a behavioral
feature, it replaces the redefined behavior. If the behavior is the behavior of a
classifier, it extends the redefined behavior.
precondition: Constraint
An optional set of Constraints specifying what must be fulfilled when the behavior is invoked. (Specializes Namespace.ownedConstraint and Constraint.context.)
postcondition: Constraint
An optional set of Constraints specifying what is fulfilled when performance of

the behavior is completed, if its precondition was fulfilled before its invocation.
(Specializes Namespace.ownedConstraint and Constraint.context.)
Constraints
[1] If the realized behavioral feature is a query, then so is the behavior that implements the behavioral feature.
[2] The parameters of the behavior must match the parameters of the realized behavioral feature.
[3] The visibility of the behavior should be the same as for the realized behavioral feature.
[4] The realized behavioral feature must be a feature (possibly inherited) of the same classifier as the behavior.
[5] If the realized behavioral feature has been overridden in the ancestors of the owner of the behavior, then the
behavior must realize the latest overriding behavioral feature (that is, all other behavioral features with the same
signature must be owned by ancestors of the owner of the realized behavioral feature).
[6] There may be at most one behavior for a given pairing of classifier (as owner of the behavior) and behavioral feature (as specification of the behavior).
2-107
BehavioralFeature (extended)
Semantics
The detailed semantics of behavior is determined by its subtypes. The features of the context classifier and elements
that are visible to the context classifier are made available to the behavior, provided that is allowed by the visibility
rules.
How the parameters of a behavior match the parameters of a behavioral feature is a semantic variation point. Different languages and methods rely on exact match (i.e., the type of the parameters must be the same), co-variant match
(the type of a parameter of the behavior may be a subtype of the type of the parameter of the behavioral feature), contra-variant match (the type of a parameter of the behavior may be a supertype of the type of the parameter of the
behavioral feature), or a combination thereof.
Notation
None.
Rationale
Allows the variuos ways of implementing behavior (as expressed by the subtypes of Behavior) to be used interchangeably.
This metaclass has been added. It abstracts the commonalities between the various ways that behavior can be implemented in the UML.
Description
A behavioral feature is implemented (realized) by a behavior. A behavioral feature specifies that a classifier will
respond to a designated request by invoking its implementing method.
Attributes
isAbstract : Boolean
If true, then the behavioral feature does not have an implementation, and one must be
supplied by a descendant. If false, the behavioral feature must have an implementation
in the classifier or one must be inherited from an ancestor.
Associations
method: Behavior
A behavioral description that implements the behavioral feature.
Constraints
None.
The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.
2-108
BehaviorInvocation
Description
BehaviorInvocation is an abstract metaclass factoring out the common features of all behavior invocations.
Attributes
Associations
behavior: Behavior [1]
The behavior that is invoked.
argument: Pin
References an ordered set of pins representing the data passed to the behavior in
this invocation.
result: Pin
References an ordered set of pins representing the data returned from the behavior upon its completion.
Constraints
Semantics
A BehaviorInvocation is an abstract metaclass. It relates a behavior with the representation of the data pass in and out
of the behavior upon invocation and upon completion of the execution of the behavior, respectively. The precise
semantics is specified by its concrete subclasses.
Notation
This metaclass was not present.
BehavioredClassifier
Description
A classifier can have behavior specifications defined in its namespace. One of these may specify the behavior of the
classifier as a whole.
Attributes
Associations
ownedBehavior : Behavior
References behavior specifications as part of the namespace of a classifier. (Specializes Namespace.ownedMember.) Any invoked behavior may, in turn, invoke
other behaviors owned by its context classifier.
classifierBehavior : Behavior [ 0..1 ]

A behavior specification that specifies the behavior of the classifier as a whole.
(Specializes BehavioredClassifier.ownedBehavior.)
2-109
Expression (extended)
Constraints
[1] If a behavior is the behavior of a classifier, it does not have a specification.
Semantics
The behavior specifications owned by a classifier are defined in the context of the classifier. Consequentially, the
behavior specifications may reference features of the classifier.
Notation
See Classifier in Chapter 1, Foundation::Kernel.
In 1.4, there was no separate metaclass for classifiers with behavior.
Expression (extended)
Description
Provides a mechanism for precisely defining the behavior of an expression. An expression is a procedure restricted to
return exactly one return result.
Attributes
body: String [0..1]
A textual representation of the computation in the named surface language.
Specifies the language in which the body of the procedure is stated. The interpretation of the expression body depends on the language. If the language is unspecified, it might be implicit from the expression body or the context.
Associations
formalParameter: Parameter [0]An expression does not have any formal parameters and thus cannot be passed
data upon invocation. It accesses its input data through elements of its behavioral
description. (Specializes Procedure.formalParameter.)
returnedResult: ReturnResult [1] Restricts an expression to return exactly on return result. When the invocation of
the expression completes, a single set of values is returned to its owner. (Specializes Procedure.returnResult.)
Semantics
An expression is invoked by its owner. Upon completion of its execution, a single value or set of values is returned to
its owner.
Description
Parameter may have default values. In addition, they may describe the result of invoking its owning behavior by referencing an element representing that value.
2-110
Associations
result: Element [0..1]
References a description of the value that is returned in this parameter when the
execution of the associated behavior completes.
value: ValueSpecification
References a ValueSpecification whose evaluation yields a value to be used when no

argument is supplied for the Parameter, or as return result of the Parameter. (Specializes
Parameter.default and Parameter.result.)
Semantics
When a behavior completes its execution, a value or set of values is returned corresponding to each out or result
parameter. If a parameter has a result element associated, this element describes the value that will be returned corresponding to this parameter. Where no such value is indicated, values corresponding to the default of the parameter are
created if a default was defined. Otherwise, there will be no values returned corresponding to this parameter. (Note
the preceding applies only to parameters of a behavior, not to parameters of a behavioral feature.)
Pin
Description
A pin represents the data values passed into a behavior upon its invocation as well as the data values returned from a
behavior upon completion of its execution.
Attributes
Associations
type: Classifier [0..1]
References a classifier specifying the values that are passed as arguments or

return results. This association is derived as specified in concrete subclasses of
pin.
multiplicity: Multiplicty [0..1] A specification of the number of values that are passed as value or return results
and their ordering . This association is derived as specified in concrete subclasses
of pin.
Constraints
Semantics
Pin is an abstract metaclass. The precise semantics is specified by concrete subclasses of pin. A pin receives values
during execution of its owner. At a specific point in a computation, there may be a collection of instance values
associated with a pin, consistent with the multiplicity of the corresponding pin.
Notation
2-111
Procedure
Procedure
A procedure is a (usually) textual specification of behavior. The behavior may, but need not, return a value or a set of
values. The behavior of the procedure is specified in detail by a set of actions. Actions may be nested at various levels. A procedure is a set of actions that may be attached as a unit to other parts of a model, for example, as the body of
a method. Conceptually a procedure, when executed, takes a set of values as arguments and produces a set of values
as results, as specified by the parameters of the procedure.
Description
A procedure contains a language-specific text string used to describe a computation, and an optional specification of
the language. One predefined language for specifying expressions is OCL. Natural language or programming languages may also be used.
When a procedure is invoked, a procedure execution receives a set of input values from the caller; during its execution it produces a set of output values which are returned to the caller as the result.
Attributes
body: String [0..1]
A textual representation of the computation in the named surface language.
Specifies the language in which the body of the procedure is stated. The interpretation of the expression body depends on the language. If the language is unspecified, it might be implicit from the expression body or the context.
Associations
action : Action
The actions that provide the behavioral specification of the procedure.
Constraints
Semantics
The interpretation of the procedure body depends on the specified language. If formal parameters are specified, these
provide values to the computation during its execution. The result parameters specify the values to be returned by the
computation.
Notation
See Expression in Chapter 1, Foundation::Kernel.
In 1.4, the Procedure metaclass was subsumed by Expression.
2-112
6 Basic::Dependencies
Chapter 6. Basic::Dependencies
The Dependencies subpackage of the Basic UML package specifies directed relationships from clients to suppliers
stating that the client is dependent on the supplier. The kinds of dependencies include Abstraction, Binding, Permission Usage, and Realization, as well as their variants.
Kernel
(from Foundation)
Dependencies
Figure 6-67. Dependencies of the Basic::Dependencies package.
Dependencies.fm Version 2 beta R1
113
6.1 Class Descriptions

NamedElement
(from Kernel)
AutonomousElement
(from Kernel)
Relationship
(from Kernel)
Dependency
+supplier
NamedElement
+supplierDependency
1..*
+client
+clientDependency
1..*
Expression
(from Kernel)
0..1
Abstraction
Usage
Permission
+mapping
[ownedElement]
Realization
Classifier
(from Kernel)
+contract
[supplier, target]
Substitut ion
Classifier
1
+substitutingClassifier
[client,source]
+substit ution
[ownedElement, client Dependenc y]
Figure 6-68. The classes declared in the Dependencies package.
Abstraction
Description
An abstraction is a 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.
Attributes
Associations
mapping: mappingExpression An aggregation of 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
114
Classifier (extended)
and bidirectional. The mapping expression is optional and may be omitted if the
precise relationship between the elements is not specified.
Constraints
Semantics
Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional. Abstraction has the following predefined stereotypes:
derive
(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.
refine
(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 suchchanges.
trace
(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 thedependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and isusually informal.
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.
Notation
An abstraction relationship is shown as a dependency with an <<abstraction>> keyword attached to it or the specific
predefined stereotype name.
Description
Associations
substitution : Substitution
(Specializes Element.ownedElement and NamedElement.clientDependency.)
115
Dependency
Dependency
Description
A dependency is a relationship that signifies that a single or a set of model elements requires other model elements
for their specification or implementation. This means that the complete semantics of the depending elements is either
semantically or structurally dependent on the definition of the supplier element(s).
Attributes
Associations
client: NamedElement [1..*]
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: NamedElement [1..*] 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.
Constraints
Semantics
A dependency signifies a supplier/client relationship between model elements where the modification of the supplier
may impact the client model elements. A dependency implies the semantics of the client is not complete without the
provider. The presence of dependency relationships in a model does not have any runtime semantics implications, it is
all given in terms of the model-elements that participate in the relationship, not in terms of their instances.
Notation
A dependency is shown as a dashed arrow between two model elements. The model element at the tail of the
arrow (the client) depends on the model element at the arrowhead (the supplier). The arrow may be labeled with an
optional stereotype and an optional individual name. It is possible to have a set of elements for the client or supplier.
In this case, one or more arrows with their tails on the clients are connected the tails of one or more arrows with their
116
NamedElement (extended)
heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be
attached at the junction point.
Dependencies
Interfaces
Figure 6-69. Notation example for a dependency between two elements
NamedElement (extended)
Description
Associations
supplierDependency: Dependency
clientDependency: Dependency
Permission
Description
A Permission signifies granting of access rights from the supplier model element to a client model element. The supplier element gives the client permission to access some or all of its constituents elements.
Attributes
Constraints
[1] The supplier must be a namespace
Notation
A permission dependency is shown as a dependency with a permission keyword attached to it.
117
Realization
Realization
Description
Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to
model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.
Attributes
Associations
Constraints
Semantics
A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the
specification. The meaning of implementation is not strictly defined, but rather implies a more refined or elaborate
form in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable. The Implementation relationship is a specialized form
of Realization between an interface and a classifier, defined at the interfaces package.
Notation
A Realization dependency is shown as a dependency with the keyword realize attached to it.
Substitution
Description
Associations
contract: Classifier [1]
(Specializes Dependency.target.)
substitutingClassifier: Classifier [1]

(Specializes Dependency.client.)
Attributes
None.
Constraints
Semantics
Notation
None.
118
Usage
Examples
None.
Rationale
Not applicable.
These metaclasses did not exist in 1.x.
Usage
Description
A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. In the metamodel, a Usage is a Dependency in which the client requires the presence of the supplier.
Attributes
Associations
Constraints
Semantics
The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by
of the definition or implementation of the client. The nature of the usage might be defined using Usage stereotypes.
the usage
Notation
A usage dependency is shown as a dependency with a usage keyword attached to it.
Examples
None.
Rationale
Not applicable.
119
Usage
120
7 Basic::Interfaces
Chapter 7. Basic::Interfaces
The Interfaces subpackage of the Basic UML package define interfaces, where an interface specifies a kind of contract that must be fulfilled by any instance of a classifier that realizes the interface. The kinds of interfaces include
provided and required interfaces.
Dependencies
Interfaces
Figure 7-70. Dependencies of the Basic::Interfaces package.
Interfaces.fm Version 2 beta R1
121
7 Basic::Interfaces

Classifier
(from Dependencies)
* {ordered}
Attribute
(from Kernel)
Operation
(from Kernel)
Interface
+ownedAttribute
0..1
0.. 1
{ordered} [redefinitionContext]
+ownedOperation
* {ordered}
0..1
+nestedInterface [ownedMember]
+contract
[ supplier, target]
Class
(from Kernel)
[ownedElement, clientDependency]
+implementation
1
+implementatingClassifier
[client,source]
+redefinedInterface
[redefinedElement]
*
Implementat ion
Realizat ion
(from Dependencies)
Figure 7-71. The classes declared in the Interface package.
Class (extended)
Description
Associations
implementation: Implementation
(Specializes Element.ownedElement and Realization.clientDependency.)
Interface
Description
An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. In
a sense, an interface specifies a kind of contract which must be fulfilled by any instance of a classifier that realizes the
interface. The obligations that may be associated with an interface are in the form of various kinds of constraints
122
7 Basic::Interfaces
Interface
(such as pre- and post-conditions) or protocol specifications, which may impose ordering restrictions on interactions
through the interface.
Since interfaces are declarations, they are not directly instantiable. Instead, an interface specification is realized
by an instance of a classifier, such as a class, which means that it presents a public facade that conforms to the interface specification. Note that a given classifier may realize more than one interface and that an interface may be realized by a number of different classifiers.
Attributes
Associations
ownedAttribute: Attribute
References the attributes owned by the Interface. (Specializes

Namespace.ownedMember and Classifier.feature.)
ownedOperation: Operation
References the operations owned by the Interface. (Specializes

nestedInterface: Interface
(Specializes Namespace.ownedMember.)
redefinedInterface: Interface
(Specializes Element.redefinedElement.)
Constraints
[1] The visibility of all features owned by an interface must be public.
self.feature->forAll(f | f.visibility = #public)
Semantics
An interface declares a set of public features and obligations that constitute a coherent service offered by a classifier.
Interfaces provide a way to partition and characterize groups of properties that realizing classifier instances must possess. An interface does not specify how it is to be implemented, but merely what needs to be supported by realizing
instances. That is, such instances must provide a a public facade (attributes, operations, externally observable behavior) that conforms to the interface. Thus, if an interface declares an attribute, this does not necessarily mean that the
realizing instance will necessarily have such an attribute in its implementation, only that it will appear so to external
observers.
Because an interface is merely a declaration it is not an instantiable model element; that is, there are no instances
of interfaces at run time.
The set of interfaces realized by a classifier are its provided interfaces, which represent the obligations that
instances of that classifier have to their clients. They describe the services that the instances of that classifier offer to
their clients. Interfaces may also be used to specify required interfaces, which are specified by a usage dependency
between the classifier and the corresponding interfaces. Required interfaces specify services that a classifier needs in
order to perform its function and fulfill its own obligations to its clients.
Attributes owned by interfaces are abstract and imply that the conforming instance should maintain information
corresponding to the type and multiplicity of the attribute and facilitate retrieval and modification of that information.
There will not necessarily be an attribute in the implementing classifier corresponding to the attribute of the interface.
Interfaces may also own constraints which impose constraints on the features of the implementing classifier.
An association between two interfaces specifies that a link exists at run time between any instances of classifiers
that implement these interfaces. Similarly, an association between a classifier and an interface specifies that a link
exists at run time between an instance of the classifier and an instance of the classifier implementing this interface.
An interface cannot be directly instantiated. Instantiable classifiers, such as classes, must implement an interface
(see Implementation).
123
7 Basic::Interfaces
Interface
Notation
As a classifier, an interface may be shown using a rectangle symbol with the keyword interface preceding the
name.
The implementation dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labelled with the name of the interface, attached by a solid line to the classifier that implements this interface (see Figure 7-72).
ProximitySensor
ISensor
Figure 7-72. Isensor is the provided interface of ProximitySensor.
The usage dependency from a classifer to an interface is shown by representing the interface by a half-circle or
socket, labeled with the name of the interface, attached by a solid line to the classifier that implements this interface
(see Figure 7-73).
TheftAlarm
ISensor
Figure 7-73. Isensor is the required interface of TheftAlarm.
Where two classifiers provide and require the same interface, respectively, these two notations may be combined as
shown in Figure 7-74. The ball-and-socket notation hints at that the interface in question serves to mediate interactions between the two classifiers.
ProximitySensor
TheftAlarm
ISensor
Figure 7-74. Isensor is the required interface of TheftAlarm as well as the provided interface of ProximitySensor.
Presentation Option
Alternatively, if an interface is shown using the rectangle symbol, their implementation and usage dependencies to
provided and required interfaces, respectively, may be shown using dependency arrows (see Figure 7-75). The classifier at the tail of the arrow implements the interface at the head of the arrow or uses that interface, respectively.
ProximitySensor
TheftAlarm
ISensor
activate()
read()
Figure 7-75. Alternative notation for the situation depict in Figure 7-74.
124
7 Basic::Interfaces
Implementation
A set of interfaces constituting a protocol are depicted as interfaces with association between them (see Figure 7-76).
<<Interface>>
Isensor
+ activate()
1
+ read()
<<Interface>> +theAlarm
IAlarm
+ notify()
1
+t heS ensor
Figure 7-76. IAlarm is the required interface for any classifier implementing Isensor; conversely, Isensor is the required interface
for any classifier implementing IAlarm.
Examples
The following example shows a set of associated interfaces that specify an alarm system. (These interfaces may be defined independently or as part of a collaboration.) Figure 7-77 shows the specification of three interfaces, IAlarm, ISensor, and
IBuzzer. IAlarm and Isensor are shown as engaged in a bidirectional protocol; IBuzzer describes the required interface
for instances of classifiers implementing IAlarm, as depicted by their respective associations.
<<Interface>>
ISensor
Activate()
<<Interface>>
+theAlarm
IAlarm
+theSensor
<<Interface >>
IBuzzer
+theBuzzer
Detect()
Vo lum e
Start()
Reset()
Figure 7-77. A set of collaborating interfaces.

Three classes: DoorSensor, DoorAlarm, and DoorBell, implement the above interfaces (see Figure 7-78 below). These classifiers
are completely decoupled. Nevertheless, instances of these classifiers are able to interact by virtue of the links declared by the
associations between the interfaces that they realize.
ISensor
DoorSensor
IAlarm
DoorAlarm
IBuzzer
DoorBell
Figure 7-78. Classifiers implementing the above interfaces.
Implementation
Description
An Implementation is a specialized Realization relationship between a Classifier and an Interface. The implementation relationship signifies that the realizing classifier conforms to the contract specified by the interface.
Attributes
125
7 Basic::Interfaces
Implementation
Associations
contract: Interface [1]
References the Interface specifying the conformance contract. (Specializes

Dependency.supplier and Relationship.target)
implementingClassifier: Classifier [1]

References the operations owned by the Interface. (Specializes Dependency.client and Relationship.source)
Constraints
Semantics
A classifier that implements an interface specifies instances that are conforming to the interface and to any of its
ancestors. A classifier may implement a number of interfaces. The set of interfaces implemented by the classifier are
its provided interfaces and signify the set of services the classifier offers to its clients. A classifier implementing an
interface supports the set of features owned by the interface. In addition to supporting the features, a classifier must
comply with the constraints owned by the interface.
An implementation relationship between a classifier and an interface implies that the classifier supports the set of
features owned by the interface, and any of its parent interfaces. For behavioral features, the implementing classifier
will have an operations or reception for every operation or reception, respectively, owned by the interface. For
attributes, the implementing classifier will provide functionality that maintains the state represented by the attribute.
While such may be done by direct mapping to an attribute of the implementing classifier, it may also be supported by
the state machine of the classifier or by a pair of operations that support the retrieval of the state information and an
operation that changes the state information.
Notation
See Interface.
Rationale
Not applicable.
UML 1.x interfaces were a narrower concept similar to interfaces in programming languages such a Java. The UML
2.0 interface concept allows to specify all behavioral characteristics and attributes of instances, rather than merely the
set of operations they provide. UML 2.0 interfaces subsume the UML 1.x concepts of classifier role and the standard
stereotype type. Both represented behavioral compliance characteristics for instances. As interfaces can now be
associated, it is no longer necessary to include classifiers as specifications to association ends. It is possible to navigate from interfaces along an association.
126
7 Basic::Interfaces
Implementation
127
7 Basic::Interfaces
Implementation
128
Chapter 8. Basic::Interactions
The Interaction package describes the concepts needed to express Interactions. Interactions come in different
forms and are depicted by Sequence Diagrams, Timing Diagrams, Sequence Activity Diagrams and Collaboration
Diagrams.
Interactions are used in a number of different situations. They are used to get a better grip of an interaction situation for an individual designer or for a group that need to achieve a common understanding of the situation. Interactions are also used during the more detailed design phase where the precise inter-process communication must be set
up according to formal protocols. When testing is performed, the traces of the system can be described as interactions
and compared with those of the earlier phases.
Interactions seem to have the ability to be understood and produced by professionals of computer systems design
as well as potential end-users and stakeholders of the (future) systems.
Typically when interactions are produced by designers or by running systems, the case is that the interactions do
not tell the complete story. There are normally other legal and possible traces that are not contained within the
described interactions. Some project do, however, request that all possible traces of a system shall be documented
through interactions in the form of e.g. sequence diagrams or similar notations.
The most visible aspects of an Interaction are the messages between the lifelines. The sequence of the messages
is considered important for the understanding of the situation. The data that the messages convey and the lifelines
store may also be very important, but the Interactions do not focus on the manipulation of data even though data can
be used to decorate the diagrams.
.
Common
Behaviors
Internal
Structures
Actions
Interactions
Figure 8-79. Dependencies of the Basic::Interactions package
Interactions.fm Version 2 beta R1
129
8 Basic::Interactions
NamedElement
(from Kernel)
+fragment
[ownedMember]
{ordered}
InteractionFragment
1. .*
+enclo si ngO perand

[namespace]
0. .1
InteractionOperand
+operand
[ownedMember]
CombinedFragment
I nterac ti onO ccurrence
Executi onOccurrence
EventOccurrence
StateInvariant
0..1 interactionOperator : InteractionOperator
1. .*
0..1
Interaction
Behavior
+invariant
(from CommonBehavior)
0..1
[ownedElement]
+guard
InteractionConstraint
Constraint
(fr om K ern el )
+m in int
0..1
0..1
Expressi on
(f rom Kernel)
+maxi nt
Constraint
(f rom Kernel)
<<en umerat ion>>

InteractionOperator
alt
opt
par
loop
region
neg
assert
strict
seq
filter
Figure 8-80. Interaction.
130
InteractionFragment
BehaviorInvocation
+coveredBy
InputPin
+argum ent
[argument]
InteractionOcc urrence
EventOcc urrence
+refersTo Interaction
(from Actions)
+events *
{ordered}
+interaction
[namespace]
+lifeline
[ownedMember] *
StateInvariant
*
+covered
+lifeline
[covered]
0.. 1
Lifeline
PartDecomposition
+stateInvariant
*
1 +lifeline
[covered]
NamedElement
(from Kernel)
*
+decomposedAs
*
0..1
+discriminator
0..1 [ownedElement]
+represents
1
ConnectableElement
Expression
(f rom Int ernal Structu res)
(from Kernel)
Figure 8-81. Interaction Occurrence.
MessageEnd
+actualGate
[ownedMember]
InteractionOccurrence
0..1
CombinedFragment
0..1
Gate
+expressionGat e
[ ownedMember]
*
0..1
Interaction
+formalGate
[ownedMember]*
Figure 8-82. Gates.
131
ActionOccurrence
NamedEl ement
InteractionFragment
(from Kernel)
1
I nteraction
1
+i nteractio n
[namespace]
+interaction
[namespace]
NamedElement
(from Kernel)
+message
[ownedMember]
*
+argument
[ ownedMember]
ValueSpecification
( from Kernel)
*
0..1
Message
messageString : String
messageKind : MessageKind
messageSort : MessageSort
+event
+sendEvent
+sendMessage
M essageEnd
0..1
0..1
+recei veMessage +receiveEvent
0..1
EventOccurrence
++
++
Gate
+connector
0. .1
+signature
NamedElement
(from InternalStructures)
( from Dependenc ies)
+finish
* +finishExec
0..1
Connector
+toAft er
*
*
+toBefore
1
+after
0..1
*
<<enumeration>>
MessageKind
compl ete
l ost
found
unknown
+before
0..1
GeneralO rdering
+start
* +startExec
Executi onOccurrence
+containing
<<enumeration>>
MessageSort
synchCall
synchS ignal
asynchCall
asynchS ignal
ActionOccurrence
+action
ProcedureO ccurrence
+procedure 1
Action
Procedure
Figure 8-83. Message.
ActionOccurrence
An ActionOccurrence is an instantiation of an Action.
Description
An ActionOccurrence is an ExecutionOccurrence that refers to an Action.
Associations
action : Action[1]
References the Action
containing:ExecutionOccurrence[0..1]References the ExecutionOccurrence that invokes this ActionOccurrence
Semantics
The semantics of an ActionOccurrence is the semantics of the associated Action (when eventual arguments have
been applied)
Notation
See ExecutionOccurrence on page 138.
CombinedFragment
A combined fragment defines an expression of interaction fragments. A combined fragment is defined by an interaction operator and corresponding interaction operands.
132
Description
CombinedFragment is a specialization of InteractionFragment.
A combinedFragment contains InteractionOperands and Gates.
Attributes
interactionOperator : InteractionOperator Specifies the operator of the combination.
Associations
expressiongate : Gate[*]
Expression Gates are contained in CombinedFragment
operand: InteractionOperand[1..*]The set of operands of the combined fragment.
Semantics
The semantics of a CombinedFragment is dependent upon the interactionOperator as explained below.
Alternatives
The interactionOperator alt designates that the CombinedFragment represents a choice of behavior. At most one of
the operands will execute. The operand that executes must have a guard expression that evaluates to true at this point
in the interaction. The operand may have no guard and in that case there is an implicit true guard.
The set of traces that defines a choice is the union of the (guarded) traces of the operands.
An operand guarded by else designates a guard that is the negation of the conjunction of all other guards in the
enclosing CombinedFragment.
Option
The interactionOperator opt designates that the CombinedFragment represents a choice of behavior where either the
(sole) operand happens or nothing happens. An option is a shorthand for a choice where there is only one operand and
the second operand is empty.
Parallel
The interactionOperator par designates that the CombinedFragment represents a parallel merge between the behaviors of the operands. The eventoccurrences of the different operands can be interleaved in any way as long as the
ordering imposed by each operand as such is preserved.
The set of traces that defines a parallel merge is a set of traces that describes all the ways that eventoccurrences
of the operands may be interleaved without obstructing the order of the eventoccurrences within the operand.
A notational shorthand for parallel combined fragments are available for the common situation where the order
of event occurrences (or other nested fragments) on one Lifeline is insignificant. This means that in a given coregion area of a Lifeline all the directly contained fragments are considered separate operands of a parallel combined
fragment.
Seq
The interactionOperator seq designates that the CombinedFragment represents a weak sequencing between the
behaviors of the operands.
Weak sequencing is defined by:
The ordering of eventoccurrences within each of the operands are maintained in the result
Eventoccurrences on different participants (lifelines) from different operands may come in any order.
133
CombinedFragment
Eventoccurrences on the same participant from different operands are ordered such that the eventoccurrence of
the left operand comes before that of the right operand.
Thus weak sequencing reduces to a parallel merge (see below) when the operands are on disjunct sets of participants.
Weak sequencing reduces to strict sequencing when the operands work on only one participant.
Strict
The interactionOperator strict designates that the CombinedFragment represents a strict sequencing between the
behaviors of the operands. This means that the vertical coordinate of the contained fragments is significant throughout the whole scope of the CombinedFragment and not only on one Lifeline.
The vertical position of an EventOccurrence is given by the vertical position of the corresponding point. The vertical position of other InteractionFragments is given by the topmost vertical position of its bounding rectangle.
Note that the semantics of the strict operation defines a strict ordering of the constituents on the first level within
the CombinedInteraction with operator strict. Eventoccurrences within contained CombinedInteractions will not
directly be compared with other Eventoccurrences of the enclosing CombinedInteraction.
Negative
The interactionOperator neg designates that the CombinedFragment represents traces that are defined to be impossible.
The set of traces that defined a negative CombinedFragment is equal to the set of traces given by its (sole) operand, only that this set is second in the pair of sets of traces that together make up the semantics. All InteractionFragments that are different from Negative are considered positive meaning that they describe traces that should be
possible.
Critical Region
The interactionOperator region designates that the CombinedFragment represents a critical region. A critical region
means that the traces of the region cannot be interleaved by other Eventoccurrences (on those Lifelines covered by
the region). Even though enclosing CombinedFragments may imply that some Eventoccurrences may interleave into
the region, such as e.g. with par-operator, this is prevented by defining a region.
Thus the set of traces of enclosing constructs are restricted by critical regions.
Filter
The interactionOperator filter designates that there are some message types that are not shown within this combined
fragment. These message types can be considered insignificant. The filter message types can be given positively by a
list of those messages that should only be considered, or negatively by which messages should be considered insignificant and which will not occur in the fragment.
The semantics of the filter operation is that those message types that are considered insignificant may occur at
any time orthogonal to the specified traces.
Notation: filter { <not>? <message name>{,<message name>}* }
Examples: filter {m, s}: showing that only m and s messages are considered significant
filter {not q,r}: showing that q and r messages are considered insignificant
Filter operations are typically combined with other operations such as assert filter {m, s}
See example in Figure 36-158.
Assertion
The interactionOperator assert designates that the CombinedFragment represents an assertion. Intuitively an assertion operator should be such that, the subsequences described by the assertion operand must happen.
134
Loop
The interactionOperator loop designates that the CombinedFragment represents a loop. The loop operand will be
repeated a number of times and the Guard will be evaluated for each iteration.
The Guard may include a specific number of iterations of the loop.
The semantics is such that a loop will iterate minimum the minint number of times (given by the iteration
expression in the guard) and at most the maxint number of times. After the minimum number of iterations have executed, and the boolean expression is false the loop will terminate.
The Semantics of Gates (see also Gate on page 8-139)
The gates of a CombinedFragment represent the syntactic interface between the CombinedFragment and its surroundings, which means the interface towards other InteractionFragments.
The only purpose of gates is to define the source and the target of Messages or General Order relations.
Notation
A CombinedFragment is defined in a Sequence Diagram by a frame where the operand and the associated guard are
described in the upper left corner of the operand.
The operands are separated by a dashed horizontal line.
Presentation Option
The head of the Lifeline may occur on top of the Interaction. It may also appear at the end of a create Message.
135
EventOccurrence
Examples
interactionOperator for Choice
Gate
operand separator
sd example
ob1:C1
ob3:C3
opti()
alt
ob4:C4
[x>0]
ob2:C2
create()
foo(x)()
doit(z)()
doit(z)()
foo(x)()
[else]
bar(x)()
doit(w)()
doit(w)()
bar(x)()
more()
call Message
more()
opti()
suspension area
method activation
destroy Lifeline
create Message
reply Message
Figure 8-84. CombinedFragment
Rationale
Not applicable.
This concept was not included in UML 1.x.
EventOccurrence
An EventOccurrence is the basic semantic unit of Interactions. We will refer to EventOccurrences as Eventoccurrences when there is no confusion between the occurrence and the corresponding type. The sequences of Eventoccurrences are the meanings of Interactions. Eventoccurrences may either trigger actions (such as in StateMachines) or
they may represent an activation of an Action such as a sendAction or a callAction. Informally we refer to such Eventoccurrences as send Eventoccurrences and call Eventoccurrences.
136
Description
EventOccurrence is a specialization of InteractionFragment and of MessageEnd.
In the metamodel, an EventOccurrence is associated closely with a Lifeline. EventOccurrences are ordered along
a Lifeline. An EventOccurrence has associated a Message that defines its content. That message has information
about the sender and receiver of the Message. EventOccurrences may also be associated with an ExecutionOccurrence representing the start or the end of that.
The namespace of an EventOccurrence is the Interaction in which it is contained.
Associations
startExec: ExecutionOccurrence[0..1]References the ExecutionOccurrence of start (of action)
finishExec:ExecutionOccurrence[0..1]References the ExecutionOccurrence of finish (of action)
lifeline: Lifeline[0..1]
toBefore:GeneralOrdering[*] Refers to GeneralOrdering that is also connected to an Eventoccurrence that

should come before this Eventoccurrence
toAfter: GeneralOrdering[*]
References the Lifeline on which the Eventoccurrence appears
Refers to GeneralOrdering that is also connected to an Eventoccurrence that

should come after this Eventoccurrence
Semantics
The semantics of an EventOccurrence is just the trace of that single EventOccurrence.
The understanding and deeper meaning of the Eventoccurrence is dependent upon the associated Message and
the information that it conveys.
Notation
Eventoccurrences are merely syntactic points at the ends of Messages or at the beginning/end of an ActionOccurrence.
137
ExecutionOccurrence
Examples
(formal)
Gate
sd AtomicFragment
part
send EventOccurrence
msg
Message
Figure 8-85. Atomic Fragment.
ExecutionOccurrence
An ExecutionOccurrence is an instantiation of a unit of behavior within the Lifeline. Since the ExecutionOccurrence
will have some duration, it is represented by two Eventoccurrences, the start EventOccurrence and the finish EventOccurrence.
Description
An ExecutionOccurrence is an InteractionFragment as it associates with two Eventoccurrences, the start Eventoccurrence and the finish Eventoccurrence.
Associations
start : Eventoccurrence[1]
References the Eventoccurrence that designates the start of the Action
finish: Eventoccurrence[1]
References the Eventoccurrence that designates the finish of the Action.
Constraints
[1] The startEvent and the finishEvent must be on the same Lifeline
self.Metaclass1->forAll->(...)
Semantics
The trace semantics of Interactions merely see an ActionOccurrence as the trace <startEvent, stopEvent>. There
may be Eventoccurrences between these. Typically the start Eventoccurrence and the finish Eventoccurrence will
refer to Eventoccurrences such as a receive Eventoccurrence (of a Message) and the send Eventoccurrence (of a
reply Message).
Notation
We represent an ExecutionOccurrence as Actions are represented in Activity diagrams or as activations on Lifelines (see Lifeline on page 145).
138
Gate
A Gate is a point that represents the conceptual interface between InteractionFragments. Gates are connected by
Messages.
Description
Gate is a specialization of MessageEnd.
Gates are connected through Messages. A Gate is actually a representative of an EventOccurrence that are not in
the same scope as the Gate.
Gates play different roles: we have formal gates on Interactions, actual gates on InteractionOccurrences, expression gates on CombinedFragments.
Attributes
name : String
Specifies the name of the Gate. This may be implicit or explicit
Semantics
The gates are named either explicitly or implicitly.
We interpret the gates in the simplest possible fashion:
1. The gates and the connectors between gates have one purpose, namely to establish the concrete sender and
receiver for every message.
2. The sender and receiver must be known in order to establish event occurrences corresponding to a message
3. Two event occurrences are considered to correspond to each other (and thus to correspond to the same message) if they share the sender and receiver and the message.
Notation
Gates are just points on the frame, the ends of the messages. They may have an explicit name.
If they do not have an explicit name, they take an implicit name. The implicit name is formed by combining the
direction of the message and the message type.
The same gate may appear several times in the same or different diagrams.
GeneralOrdering
A GeneralOrdering represents a binary relation between two Eventoccurrences, to describe that one Eventoccurrence
must occur before the other. This mechansim gives the opportunity to define partial orders of Eventoccurrences.
Description
A GeneralOrdering is a specialization of NamedElement.
A GeneralOrdering may appear anywhere in an Interaction, but only between simple Eventoccurrences.
Associations
before: Eventoccurrence[1]
The Eventoccurrence referred comes before the Eventoccurrence referred by

+after
after:Eventoccurrence[1]
The Eventoccurrence referred comes after the Eventoccurrence referred by

+before
139
Interaction
Semantics
A GeneralOrdering is introduced to restrict the set of possible sequences. A partial order of Eventoccurrences is
defined by a set of GeneralOrdering.
Notation
A GeneralOrdering is shown by a dotted line connected the two Eventoccurrences. The direction of the relation is
given by an arrowhead placed somewhere in the middle of the dotted line (i.e. not at the endpoint).
Interaction
An interaction is a unit of behavior that focuses on the observable exchange of information between parts.
Description
An Interaction is a specialization of InteractionOperand and of Behavior.
An Interaction occurs in the context of a Classifier. Typically generic Interactions are contained in Collaborations
while concrete Interactions are contained in Classes.
An Interaction in the form of a Sequence Diagram will contain Interaction Fragments, formal Gates and Lifelines.
An Interaction in the form of an Interaction Overview Diagram will contain nodes of InteractionOccurrence and
Interaction in an Activity Diagram framework.
An Interaction in the form of a Communication Diagram will contain Lifelines as well as Messages. The
sequencing information is given through a sequence number associated with either the Message or the InteractionOccurrence (or other invocation of a CombinedFragment).
Associations
formalGate: Gate[*]
Formal Gates are contained in Interactions
lifeline: LifeLine[0..*]
An Interaction may include a number of Lifelines
event:MessageEnd[*]
EventOccurrences and Gates owned by this Interaction
message:Message[*]
The contained Messages.
Semantics
Interactions are pieces of behavior that describes their enclosing Classifier. Interactions focus on the passing of
Information with Messages between the Parts of the Classifier.
The semantics of an Interaction is given as a pair of sets of traces. A trace is a sequence of Eventoccurrences. The
semantics of Interactions are compositional in the sense that the semantics of an Interaction is mechanically built
from the semantics of its constituent InteractionFragments.
The two trace sets represent possible traces and impossible traces. The union of these two sets need not cover the
whole universe of traces. The traces that are not included are not described by this Interaction at all, and we cannot
know whether they are possible or impossible.
In this informal part of the specification we shall concentrate on the set of possible traces since the set of impossible traces are less tractable.
140
Notation
An Interaction is shown by a framed diagram with a name in a small compartment in its upper left corner. The notation within this frame comes in several forms: Sequence Diagrams, Collaboration Diagrams, Activity Diagrams and
Timing Diagrams.
Please refer to Chapter 36, Interaction Diagrams to see examples of notation for Interactions.
Examples
Name of Interaction
sd User_accepted
Lifeline
AC System
User
Code
Message
OK
C
o
ard
ut
Unlock
Figure 8-86. An example of an Interaction in the form of a Sequence Diagram
Rationale
Not applicable.
Interactions are now contained within Classifiers and not only Collaborations. Their active objects are Lifelines and
not ClassifierRoles. This helps unifying a number of related concepts.
An InteractionConstraint is a Constraint with a Boolean expression. Only scenarios guarded by expressions that evaluate to true at this point in the interaction will be considered within the trace set that defines the semantics. (See
description in Chapter 19, Common::StateMachines.)
Description
InteractionConstraint is a specialization of Constraint.
Furthermore the InteractionConstraint contains two expressions designating the minimum and maximum number
of times a loop CombinedFragment should execute.
141
InteractionFragment
Associations
minint: Expression[0..1]
The minimum number of iterations of a loop
maxint: Expression[0..1]
The maximum number of iterations of a loop
Constraints
[1] The dynamic variables that take part in the constraint must be owned by the Part corresponding to the covered
Lifeline.
TBD
[2] The constraint may contain references to global data or write-once data.
Notation
Guards are put in square brackets at the very top of an Interaction or of an InteractionOperand on the Lifeline that
covers the first Eventoccurrence that will occur.
interactionconstraint ::= [<iteration expression>] [[ Boolean Expression ]]
iteration expression ::= minint [.. maxint] | *
minint ::= integer
maxint ::= integer
When the Boolean Expression is omitted, true is assumed.
Iteration expressions are applicable only for loop combinedfragments. When iteration expression is omitted then
* is assumed.
When maxint is omitted then <minint..minint> is assumed.
InteractionFragment
An interaction fragment is a piece of an interaction. Each interaction fragment is conceptually like an interaction by
itself, but it appears only as constituent of an enclosing interaction.
Description
InteractionFragment is a specialization of NamedElement.
An InteractionFragment is contained in either a CombinedFragment (which is a specialization of InteractionFragment) or an Interaction. InteractionFragments are either EventOccurrence, CombinedFragment, InteractionOperand,
ExecutionOccurrence or InteractionOccurrence.
Associations
enclosingOperand: InteractionOperand[0..1]The enclosing operand enclosing this InteractionFragment (they

may nest recursively)
covered : Lifeline
References the Lifelines that the InteractionFragment covers
Semantics
The semantics of an InteractionFragment is a set of traces just like for an Interaction. The semantics of an InteractionFragment is built from the semantics of its constituent InteractionFragments.
Notation
An InteractionFragment appears in different ways depending on which specialization of InteractionFragment is used.
InteractionFragment is a semantic concept rather than a specific notation-oriented concept.
142
Rationale
Not applicable.
This concept did not appear in UML 1.x.
An InteractionOccurrence refers to an Interaction definition. The meaning of an InteractionOccurrence is that the
meaning of the interaction definition that it refers is substituted for the InteractionOccurrence.
This is practical in order to reuse Interaction definitions.
Description
InteractionOccurrence is a specialization of InteractionFragment and of BehavioralInvocation.
In the metamodel the InteractionOccurrence has actual gates that must match the formal gates of the Interaction
that it refers. The Interaction is given by the ident of the InteractionOccurrence matching the name of the Interaction.
Associations
refers to: Interaction
Refers to the Interaction that defines its meaning
argument:InputPin
The actual arguments of the Interaction
Constraints
[1] Actual Gates of the InteractionOccurrence must match Formal Gates of the referred Interaction. Gates match
when their names are equal.
TBD
[2] The InteractionOccurrence must cover all Lifelines of the enclosing Interaction which appear within the referred
Interaction.
[3] The arguments of the InteractionOccurrence must correspond to those of the referred Interaction
[4] The arguments must only be constants, parameters of the enclosing Interaction or attributes of the classifier owning the enclosing Interaction.
Semantics
The semantics of the InteractionOccurrence is the set of traces of the semantics of the referred Interaction where
the gates have been resolved as well as all generic parts having been bound such as the arguments substituting the
parameters.
Notation
The InteractionOccurrence is shown as a CombinedFragment symbol where the operator is called ref. The complete
syntax of the name (situated in the InteractionOccurrence area) is:
name ::= [collaborationoccurrenceident .] interactionname[(arguments)]
The collaboration occurence ident is an identification of a collaboration occurrence that binds lifelines of a collaboration. The interaction name is in that case within that collaboration.
143
InteractionOperand
Examples
sd UserAccess
User
ref
ACSystem
EstablishAccess("Illegal PIN")
Card Out()
opt
Msg("Please Enter")()
ref
Open Door
Figure 8-87. InteractionOccurrence.

Rationale
Not applicable.
InteractionOccurrence was not a concept in UML 1.x
InteractionOperand
InteractionOperand is a specialization of InteractionFragment.
An InteractionOperand is contained in a CombinedFragment. An InteractionOperand represent one operand of the
expression given by the enclosing CombinedFragment.
An InteractionOperand may be guarded by a Guard. Only InteractionOperands with a guard that eveluates to true
at this point in the interaction will be considered for the production of the traces for the enclosing CombinedFragment.
Description
In the metamodel, an InteractionOperand is an InteractionFragment with an optional guard expression.
InteractionOperand contains an ordered set of InteractionFractions. These InteractionFractions are just fractions
that are placed within the operand and they are ordered according to their geometrical position vertically. The geometrical position of the InteractionFragment is given by the topmost vertical coordinate of its contained eventoccurrences or symbols.
144
Associations
fragment: InteractionFragment[1..*]The fragments of the operand. They are ordered by weak sequencing.
guard: InteractionConstraint[0..1]Constraint of the operand
Semantics
Only InteractionOperands with true operands are included in the calculation of the semantics. If no guard is
present, this is taken to mean a true guard. The guard is placed directly prior to the eventoccurrence that must
become the first eventoccurrence within this InteractionOperand.
The semantics of an InteractionOperand is given by its constituent InteractionFragments combined by the implicit
seq operation. The seq operator is described in CombinedFragment on page 132
Notation
InteractionOperands are separated by a dashed horizontal line. The InteractionOperands together make up the framed
CombinedFragment.
Within an InteractionOperand of a Sequence Diagram the order of the InteractionFragments are given simply by
the topmost vertical position.
For a Collaboration Diagram the order of the InteractionFragments are given by the sequence numbers. The
sendEvent must come before the corresponding receiveEvent.
Lifeline
A lifeline represents an individual participant in the Interaction. While Parts and structural features may have multiplicity greater than 1, Lifelines represent only one interacting entity.
The order of Eventoccurrences along a Lifeline is significant denoting the order in which these Eventoccurrence
will occur. The absolute distances between the Eventoccurrences on the Lifeline are, however, irrelevant for the
semantics.
Description
Lifeline is a specialization of NamedElement.
In the metamodel, Lifelines are contained in Interactions, and InteractionOccurrences cover Lifelines. Each Lifeline
is associated with a sequence of Eventoccurrences representing the order of the Eventoccurrences on this Lifeline. A
Lifeline is also associated with the Part which it represents.
If the referenced Part is multivalued (i.e. has a multiplicity > 1), then the Lifeline should have an expression that
specifies which particular part is represented by this Lifeline.
Associations
selector : Expression[0..1]
If the referenced Part is multivalued, then this specifies the specific individual
part within that set.
interaction: Interaction[1]
References the Interaction enclosing this Lifeline.
events : Eventoccurrence[*]
References the ordered sequence of Eventoccurrences of the Lifeline
stateInvariant : StateInvariant[*]References the StateInvariants on the Lifeline
represents: ConnectableElement[1]References the ConnectableElement within the Internal Structure that it represents
decomposedAs : PartDecompositionReferences the Interaction that represents the decomposition.
145
Message
coveredBy: InteractionFragment[*]References the InteractionFragments that cover this Lifeline
Constraints
[1] If two (or more) InteractionOccurrences refer to Interactions with common Lifelines, those Lifelines must also
appear in the Interaction with the InteractionOccurrences.
TBD
[2] The selector for a Lifeline must only be specified if the referenced Part is multivalued.
(self.index->isEmpty implies not self.represents.isMultivalued) or
(not self.index->isEmpty implies self.represents.isMultivalued)
Semantics
The semantics of Lifelines may be expressed as the trace of its associated Eventoccurrences.
Normally this is not so very practical as a Lifeline is also covered by InteractionOccurrence and of CombinedFragments. Another way to formulate this would be that the semantics of the Lifeline (within an Interaction) is the
semantics of the Interaction where only Eventoccurrences of the Lifeline in question is selected.
Notation
A Lifeline is given by a Lifeline symbol consisting of a head at the top with the name of the Lifeline followed by a
vertical line (that may be dashed) whereupon the Eventoccurrences are placed.
The Lifeline head has a shape which is based on the classifier for the part that this lifeline represents. Often the
head is a white rectangle containing the name.
The grammar for the name of the Lifeline is given by:
lifelineident ::= partname [[ selector ]] [: class of Part] [decomposition] | self
selector ::= expression
decomposition ::= ref interactionident
The optional selector is used when only some instances of a set of Parts are represented in the Interaction as some
Lifelines. If the name is the keywork self, then the lifeline represents the object of the classifier that encloses the
Interaction that owns the Lifeline. Ports of the encloser may be shown separately even when self is included.
To depict method activations we apply a grey rectangle that covers the Lifeline line.
To depict suspension areas we apply a rectangle that is filled white and where the periphery is dotted.
Examples
See Figure 8-86 where the Lifelines are pointed to.
See Figure 8-84 to see method activations and suspension areas.
Rationale
Not applicable.
Lifelines are basically the same concept as before in UML 1.x.
Message
A Message defines a particular communication between Parts of an Interaction.
146
Description
A Message is a NamedElement that defines one specific kind of communication in an Interaction. A communication can be e.g. raising a signal, invoking an Operation, creating or destroying an Instance. The Message specifies not
only the kind of communication given by the dispatching ExecutionOccurrence, but also the sender and the receiver.
A Message associates normally two EventOccurrences - one sending EventOccurrence and one receiving EventOccurrence.
Attributes
messageString: String
Optionally specifies the meaning of the Message informally
messageKind:MessageKind
The kind of the Message (complete, lost, found or unknown)
messageSort:MessageSort
The sort of communication reflected by the Message (synchCall, synchSignal,

asynchCall, asynchSignal)
Associations
interaction:Interaction[1]
The enclosing Interaction owning the Message
sendEvent : MessageEnd
References the Sending Eventoccurrence of the Message.
receiveEvent: MessageEnd
References the Receive Eventoccurrence of the Message
connector: Connector[0..1]
The Connector on which this Message is sent.
argument:ValueSpecification[*]The arguments of the Message
signature:NamedElement[0..1] The definition of the type or signature of the Message (depending on its kind)
Constraints
[1] If the sendEvent and the receiveEvent of the same Message is on the same Lifeline, the sendEvent must appear
before the receiveEvent.
[2] The signature must either refer an Operation (in which case messageSort is either synchCall or asynchCall) or a
Signal (in which case messageSort is either synchSignal or asynchSignal). The name of the NamedElement referenced by signature must be the same as that of the Message.
[3] In the case when the Message signature is an Operation, the arguments of the Message must correspond to the
parameters of the Operation.
[4] In the case when the Message signature is a Signal, the arguements of the Message must correspond to the
attributes of the Signal.
[5] Relations +sendEvent and +receiveEvent are mutually exclusive.
[6] Arguments of a Message must only be:
i) attributes of the sending lifeline
ii) constants
iii) symbolic values (which are wildcard values representing any legal value)
iv) explicit parameters of the enclosing Interaction
v) attributes of the class owning the Interaction
Semantics
The semantics of a complete Message is simply the trace <sendEvent, receiveEvent>.
147
MessageEnd
A Lost message is a message where the sending event occurrence is known, but there is no receiving event occurrence. We interpret this to be because the message never reached its destination. The semantics is simply the trace
<sendEvent>.
A Found message is a message where the receiving event occurrence is known, but there is no (known) sending
event occurrence. We interpert this to be because the origin of the message is outside the scope of the description.
This may for example be noise or other activity that we do not want to describe in detail. The semantics is simply the
trace <receiveEvent>.
A Message reflects either an Operation call and execution or a sending and reception of a Signal.
When a Message represents an Operation the arguments of the Message are the arguments of the CallAction and
the arguments of the CallEvent on the receiving Lifeline.
When a Message represents a Signal, the arguments of the Message are the arguments of the SendAction and on
the receiving Lifeline the arguments are available in the SignalEvent.
If the Message represents a CallAction, there will normally be a reply Message before the sending Lifeline will
proceed.
Notation
A Message can come in a few different shapes:
Asynchronous Messages have an open arrow head.
Synchronous Messages representing typically method calls have a filled arrow head. The reply from a method
has a dashed line.
Object creation Message has a dashed line with an open arrow.
On Communication Diagrams, the Messages are decorated with the direction of the Message.
Examples
In Figure 8-86 we see only asynchronous Messages. Such Messages may overtake each other.
In Figure 8-84 we see method calls that are synchronous accompanied by replies. We also see a Message that
represents the creation of an object.
In Figure 36-160 we see how Messages are denoted in Communication Diagrams.
Rationale
Not applicable.
We notice that Messages have Eventoccurrences at both ends.
MessageEnd
A MessageEnd is an abstract class to represent the two ends of a Message.
Description
A MessageEnd is a NamedElement that represents what can occur at the end of a Message. MessageEnds are
either EventOccurrences or Gates.
148
Attributes
messageString: String
Optionally specifies the meaning of the Message informally
Associations
sendMessage : Message[0..1] References the Message that contains the information of a sendEvent
receiveMessage : Message[0..1]References the Message that contains the information of a receiveEven
interaction:Interaction[1]
The enclosing Interaction owning the MessageEnd
Semantics
The semantics of a MessageEnd is given by the semantics of either Gate or EventOccurrence.
PartDecomposition
PartDecomposition is a description of the internal interactions of one Lifeline relative to an Interaction.
A Lifeline has a class associated as the type of the Part that the Lifeline represents. That class has an internal
structure and the PartDecomposition is an Interaction that describes the behavior of that internal structure relative to
the Interaction where the decomposition is referenced.
Description
A PartDecomosition is a specialization of InteractionOccurrence. It associates with the Part that it decomposes.
Associations
encloser: Lifeline[1]
References Lifeline that is decomposed in the PartDecomposition
Constraints
[1] PartDecompositions apply only to Parts that are Parts of Internal Structures not to Parts of Collaborations.
[2] Assume that within Interaction X, Lifeline L is of class C and decomposed to D. Within X there is a sequence of
constructs along L (such constructs are CombinedFragments, InteractionOccurrence and (plain) Eventoccurrences). Then a corresponding sequence of constructs must appear within D, matched one-to-one.
[3] Assume that within Interaction X, Lifeline L is of class C and decomposed to D. Assume also that there is within
X an InteractionOccurrence (say) U that covers L. According to the constraint above U will have a counterpart
CU within D. Within the Interaction referenced by U, L should also be decomposed, and the decomposition
should reference CU. (This rule is called commutativity of decomposition)
Semantics
Decomposition of a lifeline of one Interaction by the Interaction of its internal Parts, is interpreted exactly as an
Interaction Reference. The messages that go into (or go out from) the decomposed lifeline are interpreted as gates.
Since the decomposition is an InteractionOccurrence, the semantics of a PartDecomposition is the semantics of
the Interaction referenced by the decomposition where the gates and other generics have been matched.
Notation
PartDecomposition is designated by a referencing clause in the head of the Lifeline as can be seen in Lifeline on
page 8-145
149
PartDecomposition
Style Guidelines
The name of an Interaction that are involved in decomposition would benefit from including in the name, the name of
the type of the Part being decomposed and the name of the Interaction originating the decomposition.
Examples
sd UserAccess
Part decomposition
User
ref
____ACSystem____
ref AC_UserAccess
EstablishAccess("Illegal PIN")
Card Out()
opt
ref
[ pin ok]
Open Door
Figure 8-88. Part Decomposition - the decomposed part.

In Figure 8-88 we see how ACSystem within UserAccess is to be decomposed to AC_UserAccess which is an Interaction owned by class ACSystem.
150
Port
sd AC_UserAccess
AccessPoint
p1
ref
extra global
interaction group
Authorizer
Console
p2
AC_EstablishAccess("Illegal PIN")
Card Out()
opt
ref
[ pin ok]
AC_OpenDoor
Figure 8-89. Part Decomposition - the decomposition.

In Figure 8-89 we see that AC_UserAccess has global constructs that match the constructs of UserAccess covering
ACSystem.
In particular we notice the extra global interaction group that goes beyond the frame of the Interaction. This
construct corresponds to a CombinedFragment of UserAccess. However, we want to indicate that the operands of
extra global interaction groups are combined one-to-one with similar extra global interaction groups of other decompositions of the same original CombinedFragment.
Furthermore we see that Ports can be depicted directly as separate Lifelines. Since Ports are also Parts, we need
not introduce new concepts in order to have such Port Lifelines.
Furthermore regular Parts that are contained within the top level Parts can be represented by separate Lifelines in
diagrams on the level of their encloser(s). This notation then represents implicit decomposition of the Parts.
Rationale
Not applicable.
PartDecomposition did not appear in UML 1.x.
ProcedureOccurrence
A ProcedureOccurrence is an instantiation of a Procedure.
151
StateInvariant
Description
A ProcedureOccurrence is an ExecutionOccurrence that refers to a Procedure.
Associations
procedure: Procedure[1]
References the Procedure
Semantics
The semantics of a ProcedureOccurrence is the semantics of the associated Procedure (when eventual arguments
have been applied)
Notation
See ExecutionOccurrence on page 138.
StateInvariant
A StateInvariant is a constraint on the state of a Lifeline. In this case we mean by state also the values of eventual
attributes of the Lifeline.
Description
A StateInvariant is an InteractionFragment and it is placed on a Lifeline.
Associations
invariant: Constraint[0..1]
A Constraint that should hold at runtime for this StateInvariant
lifeline: Lifeline[0..1]
References the Lifeline on which the StateInvariant appears
Semantics
The Constraint is assumed to be evaluated during runtime. The Constraint is evaluated immediately prior to the
execution of the next EventOccurrence such that all actions that are not explicitly shown in the diagrams have been
executed. If the Constraint is true the trace is positive; if the Constraint is false the trace is negative/fail. In other
words all traces that has a StateInvariant with a false Constraint is considered undesirable or failing traces.
Notation
The possible associated Constraint is shown as text in curly brackets on the lifeline. Optional notation is in a
Note associated with an EventOccurrence.
State symbols may also be used to describe a Constraint. The State symbol represents the equivalent of a constraint that checks the state of the classifierBehavior of the enclosing Classifier. Since States may be hierarchical and
orthogonal, the following syntax can be used for the state name:
<state-info>::= <region} {,<region> }*
<region>::= <trivial region> | <region-name> {::<state>}?
<trivial region>::= <state>
<state>::= <state-name> {::<region-list>}?
<region-list>::= <region> | ( <state-info> )
The regions represent the orthogonal regions of states. The identifier need only define the state partially. The
value of the constraint is true if the specified state information is true.
See example in Figure 36-158.
152
8.2. Semantic Model

The semantics of an Interaction is given by a pair [P, I] where P is the set of possible traces and I is the set of impossible traces. P I needs not be the whole universe.
A trace is a sequence of event occurrences.
An event occurrence is the actual incident of an Eventoccurrence happening.
Each construct of Interactions (such as CombinedFragments of different kinds) are expressed in terms of an operation on pairs of sets of traces.
153
8.2 Semantic Model
154
9 Basic::InternalStructures
Chapter 9. Basic::InternalStructures
The InternalStructure package provides mechanisms for specifying sets of instances connected by links that are created within an instance of a containing classifier. The structure specified by parts (describing objects to come) and
connectors (describing links to come) is referred to as the internal structure of its containing classifier.
Kernel
(from Foundation)
Dependencies
Internal
Structures
Figure 9-90. Dependencies of the Basic::InternalStructure package
Classifier
(from Kernel)
StructuredClassifier
NamedElement
(from Dependencies)
+role
[feature]
ConnectableElement
*
0..1
+ownedPart
[role, ownedMember]
[ redefinitionContex t]
0.. 1
Part
*
+ownedConnector
[redefinitionCont ext]
StructuralFeature
(from Kernel)
{ visibilit y = prot ected }

+redefinedPart
[redefinedElement]
Connector
{ visibilit y = prot ected }
+redefinedConnector
[redefinedElement]
Figure 9-91. Structured classifier
InternalStructures.fm Version 2 beta R1
155
ConnectableElement
Element
(from Kernel)
AssociationEnd
(from Kernel)
1
Feature
(from Kernel)
+definingEnd
/
ConnectableElement +part
+end
0..1
ConnectorEnd
2.. *
{ordered}
+end
[ownedElement]
Connector
kind : ConnectorKind [0..1]
0..1
/
ConnectorKind
assembly
delegation
0..1
+multiplicity
[ownedElement]
Multiplicity
(from Kernel)
+type
Association
(from Kernel)
Figure 9-92. Connectors
ConnectableElement
Description
ConnectableElement is an abstract metaclass representing model elements which may be linked via connectors.
Attributes
Associations
end : ConnectorEnd
Denotes a connector that attaches to this connectable element.
Constraints
Semantics
The semantics of ConnectableElement is given by its concrete subtypes.
Notation
None.
Examples
None.
Rationale
This metaclass supports factoring out the ability of a model element to be linked by a connector.
156
Connector
Connector
Specifies a link (an instance of an association) that enables communication between two or more instances. The link
may be realized by something as simple as a pointer or by something as complex as a network connection. In contrast
to associations, connectors specify links between instances playing the connected parts only.
Description
Each connector may be attached to two or more connectable elements, each representing a set of instances. The individual attachments are distinct in the sense that they play distinct roles in the communication realized over a connector. The communication realized over a connector may be constrained by the attached classifier.
Attributes
kind: ConnectorKind [0..1]
Constrains the connector to be an assembly connector or delegation connector.

See ConnectorKind.
Associations
end: ConnectorEnd [ 2..* ]
A connector consists of at least two connector ends, each of which represents a

connection of the connector to a connectable element. The set of connector ends
is ordered.
type: Association
Narrows the inherited association TypedElement.type to allow only associations

as the type of a connector. This association is derived.
redefinedConnector: ConnectorA connector may be redefined when its containing classifier is specialized. The
redefining connector may have a type that specializes the type of the redefined
connector. The types of the connector ends of the redefining conector may specialize the types of the connector ends of the redefined connector. The properties
of the connector ends of the redefining connector may be replaced. (Specializes
Element.redefinedElement.)
Constraints
[1] The types of the parts that the ends of a connector are attached to must be the same type as, or a subtype of, the
types of the association ends of the association that types the connector.
[2] Every connector is contained in exactly one classifier.
[3] The multiplicities on connectors must be consistent with the multiplicities of the connected parts.
Semantics
If a connector between two or more parts of a classifier is a feature of an instantiable classifier, it declares that a link
may exist within an instance of the containing classifier. This link will connect instances corresponding to the parts
joined by the connector. The links and the connected instances are part of the same containing classifier instance. The
links are specified by the association that types the connector or by an association that realizes a collaboration specifying the interaction between two connected classifiers (as in the case of a protocol).
Links corresponding to connectors may be created upon the creation of the instance of the containing classifier,
depending on the multiplicities of the attached parts (see Part) and the connector itself (unless otherwise determined by the manner of creation of the containing instance). The multiplicity on the connector may indicate that less
links are created than indicated by the connected parts alone. This set of links is a subset of the total set of links specified by the association typing the connector. Links need not be created when the containing classifier instance is created, but may also be created at some later time. All links are destroyed when the containing classifier instance is
destroyed.
157
Connector
A connector may connect several connectable elements when their required and provided interfaces are the same,
or the provided interface is a subtype of the required interface.
If the type of the connector is omitted, the type is inferred based on the connector, as follows: If a part realizes an
interface that has an association to another interface which is realized by another part (or a subtype of that interface is
realized by another part), then that association is the type of the connector between the two parts. If the connector
realizes a collaboration, then the type of the onnector is an anonymously named association with association ends
corresponding to each connector end. The type of each association end is the classifier that realizes the parts connected to the matching connector in the collaboration. Any adornments on the connector ends (either the original connector or the connector in the collaboration) specify adornments of the ends of the inferred association. Otherwise,
the type of the connector is an anonymously named a ssociation with association ends corresponding to each connector end. The type of each association end is the type of the part that each corresponding connector end is attached to.
Any adornments on the connector ends specify adornments of the ends of the inferred association. Any inferred associations are always bidirectionally navigable.
Notation
A connector is drawn using the notation for association (see Chapter 1, Foundation::Kernel). The name string of the
connector obeys the following syntax:
{{ [ name ] : classname } | name }
where name is the name of the connector, and classname is the name of the association that is its type. A stereotype
keyword within guillemets may be placed above or in front of the connector name. A property string may be placed
after or below the connector name.
A path drawn between a part symbol and the symbol representing the containing classifier denotes a connector
between the part and a part representing the whole.
Presentation Option
If there are a number of connectors from or two a single element, the connectors may be drawn as a tree by merging
the connector end into a single path segment. This requires that any adornements on the merged path segment are
consistent.
:BackOrder
Person
OrderEntry
Person
:Order
OrderEntry
:Customer
Person
:Organization
Figure 9-93. As a presentation option, multiple connectors can be visually grouped together.
Examples
Further examples are shown in section StructuredClassifier.
Rationale
Not applicable.
158
ConnectorEnd

Connector has been added in UML 2.0. The UML 1.4 concept of association roles is subsumed by connectors.
ConnectorEnd
Description
A connector end is an endpoint of a connector, which attaches the connector to a connectable element. Each connector end is part of one connector. The connector ends of each connector are ordered.
Attributes
Associations
part: ConnectableElement [ 0..1 ]

The connectable element attached at this connector end. When an instance of the
containing classifier is created, a link may (depending on the multiplicities) be
created to an instance of the classifier that types this connectable element. Note
that links will be created only if the connector was owned by an instantiable classifier.
definingEnd: AssociationEnd [1]

A derived association referencing the corresponding association end on the association which types the connector owing this connector end. This association is
derived by selecting the association end at the same place in the ordering of association ends as this connector end.
multiplicity: Multiplicity [0..1] Indicates the number of instances that may be connected to each instance of the
part on the other end.
Constraints
Semantics
A connector end describes which connectable element is attached to the connector owning that end.
Notation
Adornments may be shown on the connector end corresponding to adornments on association ends (see Chapter 1,
Foundation::Kernel). These adornments specify properties of the association typing the connector.
Rationale
Not applicable.
Connector end has been added in UML 2.0. The UML 1.4 concept of association end roles is subsumed by connector
ends.
159
ConnectorKind
ConnectorKind
Description
ConnectorKind is an enumeration of the following literal values:
assembly
delegation
A connector with kind = assembly is referred to as assembly connector; a delegation connector has kind = delegation.
Constraints
[1] If an assembly connector links two ports, it must only be defined from a required port to a provided port.
[2] If a delegation connector links two ports, it must only be defined between ports of the same kind, i.e. between
two provided ports or between two required ports.
[3] If a delegation connector is defined from a provided port on a classifier to a provided port on one of its parts, then
the classifier typing that part must implement the provided interfaces of the port on the classifier, or subtypes
thereof.
[4] If a delegation connector is defined from a required port port on one of the parts of a classifier to a required port
of this classifier, then the provided interfaces of the classifier must be the same or subtypes of the provided interface of the classifier typing that part.
Semantics
A connector with kind = assembly defines that one element provides the services that the other element requires.
The services are expressed by interfaces that are associated with the ports on the connected elements. An assembly
connector is a uni-directional connector between two parts. If the connector links ports, it is from a port with a
required interface to a port with a provided interface.A connector with kind = delegation links a port of a classifier to
the internal realization of the behavior promised by the contract expressed via that port by a part of the classifier. It
represents the forwarding of communication between an external port of the classifier and one of its parts. An operation or signal that arrives at a port that has a delegation connector to another port will be passed on to that target for
handling.
Notation
See Connector.
Presentation Option
Assembly connectors may also be shown by combining the icons for the required and provided interfaces of the connected classifiers in the ball-and-socket notation (see also Chapter 7, Basic::Interfaces).
160
Part
OrderEntry
Order
:Order
OrderableItem
OrderableItem
Product
OrderableItem
:Product
Figure 9-94. An assembly connector links a required port of a classifier to a provided port of another classifier.

Connector has been added in UML 2.0.
Part
Description
A part represents a set of instances that are owned by a containing classifier instance. Parts may be joined by attached
connectors and specify configurations of linked instances to be created within an instance of the containing classifier.
Attributes
Associations
redefinedPart: Part
A part may be redefined when its containing classifier is specialized. The redefining part may have a type that specializes the type of the redefined part. (Specializes Element.redefinedElement.)
Constraints
Semantics
A part of a classifier declares that an instance of this classifier may contain a strongly aggregated set of instances.
When an instance of the containing classifier is created, a set of instances corresponding to these parts may be created
either immediately or at some later time, depending on the multiplicity. These instances are instances of the classifier
typing the part. A part specifies that a set of instances may exist; this set of instances is a subset of the total set of
instances specified by the classifier typing the part.
Notation
A part is shown by graphical nesting of a box symbol representing the part within the symbol representing the whole
in a separate compartment. The contained box symbol has only a name compartment, which contains a string according to the following syntax:
{ name : [ classname ] } [ [ multiplicity ] ]
161
where name is the name of the part, and classname is the name of its type. Either the name of the part or the name of
its type may be omitted. The optional multiplicity is shown in brackets. The multiplicity of a part is 1, if not specified
explicitly as part of the name string.
The multiplicity for a part may also be shown as a multiplicity mark in the top right corner of the part box.
Rationale
Not applicable.
Part has been added in UML 2.0.
Description
A structured classifier is an abstract metaclass representing any classifier the behavior of which can be described by
the collaboration of contained instances. The initialization of the internal structure of a classifier can be shown by
describing the instances (objects and links) that are created when an instance of the containing classifier is created.
Attributes
Associations
role: ConnectableElement
References the roles that instances may play in this classifier. (Abstract; specializes Classifier.feature.)
ownedPart: Part
References the parts owned by the classifier. (Specializes StructuredClassifier.role and Namespace.ownedMember)
ownedConnector: Connector
References the connectors owned by the classifier. (Specializes Classifier.feature

and Namespace.ownedMember)
Constraints
Semantics
The multiplicities on the parts and connectors or connector ends? indicate the number of instances that may be created when an instance of the containing classifier is created. The lower bound of the multiplicity range indicates the
number of instances that is created (unless indicated differently by an associated instance specification or a constructor function); the upper bound of the multiplicity range indicates the maximul number of instances that may be created.
When an instance specification is used to specify the initial instance to be created for a classifiers, multiplicities
shown determine the number of initial instances that will be created within that classifier. Initially, there will be as
many instances held in slots as indicated by the corresponding multiplicity. Multiplicity ranges on such instance specifications may not contain upper bounds.
162
For each instance connected to a link end which was derived from a connector, there will initially be as many
connectors as indicated by the multiplicity of the part connected to the other end, unless the number of links is
restricted by the multiplicity on the connector representing the link itself.
Notation
The namestring of a part in an instance specification obeys the following syntax:
{{ [ name [/ partname]] : classifiername [{, classifiername}*]} | name [/ partname]}[= expression]
The name of the instance specification may be followed by the name of the part which the instance plays. The name
of the part may only be present if the instance plays a role.
Examples
If no multiplicity is given on a connector (see Figure 9-95 i), the initial configuration that will be created when an
instance of the containing classifier is created consists of the set of instances corresponding to the parts, as specified
by the multiplicities on the parts fully connected by links (see the resultant instance, Figure 9-95 ii).
(i)
a:
b:
/ a:
/ b:
/ a:
/ b:
(ii)
Figure 9-95. Star connector pattern.

Multiplicities on connectors (see Figure 9-96 i) serve to restrict the number of initial links created. Links will be created between instances playing the connected parts according to their ordering until the connector multiplicity is
163
reached (see the resultant instance, Figure 9-96 ii). In this example, only two links are created, resulting in an array
pattern.
(i)
a:
b:
/ a:
/ b:
/ a:
/ b:
(ii)
Figure 9-96. Array connector pattern.
164
10 Basic::UseCases
Chapter 10. Basic::UseCases

The UseCases package specifies the concepts used for defining the functionality required to be performed by a system (hereafter referred to as the subject), without reference to its internal structure or implementation. The key concepts in this package are UseCase and Actor. An Actor represents an external entity that interacts with the subject
to realize a use case. A UseCase describes the behaviors that accomplish some required system functionality.
Kernel
(from Foundation)
Common
Behaviors
UseCases
Figure 10-97. Dependencies of the Basic::UseCases package.
UseCases.fm Version 0.69
10-165
10 Basic::UseCases

Classifier
(from Kernel)
+subject
*
Feature
Classifier
(from Kernel)
0..1
+ownedUseCase
[ownedElement]
+extensionPoint
[feature, ownedElement]
Ext ensionPoint
*
1..*
{ordered}
1
+extension
[source]
+extensionLocation
+useCase
UseCase
1
+base
[target]
Actor
+base
[source]
Extend
+addition
[target]
Include
*
0..1
0..1
Constraint
(f rom Ke rn el)
Rela tionship
+condition
[ownedElement]
(from Kernel)
Figure 10-98. The classes defined in the UseCase package.
Actor
An Actor models a type of entity that interacts with the subject (e.g., by exchanging events or data), but which is itself
external to the subject. Actors can be human users, external hardware, or other subjects. An actor does not necessarily
represent a specific physical entity. For instance, a single physical entity may play the role of several different
actors and, conversely, a given actor may be played by multiple physical entities.
Description
Actor is a kind of classifier that can be directly associated with one or more UseCases.
Attributes
Associations
10-166
10 Basic::UseCases
Constraints
[1] An actor can only have associations to use cases, subsystems, components and classes, and these associations must be binary.
[2] Actors cannot contain any classifiers.
[3] An actor must have a name.
self.name->size >= 1
Semantics
Actors model entities external to the subject. Each actor represents a coherent set of roles that users of the subject can
play when interacting with it. When an external entity interacts with the subject, it plays the role of a specific actor.
The role name can be defined as the name of the association end. It can also be formalized as the name of a part in
a use case collaboration.
Notation
An actor is represented by stick man icon with the name of the actor in the vicinity (usually above or below) the
icon. (See Figure 10-101.)
An actor may also be shown as a class rectangle with the keyword actor, with the usual notation for all compartments. Other icons that convey the kind of actor may also be used to denote an actor, such as using a separate icon for
non-human actors.
Style Guidelines
Actor names should follow the capitalization and punctuation guidelines used for types and classes in the model. The
names of abstract actors should be shown in italics.
Rationale
Not applicable.
There are no changes to the Actor concept except for the addition of a constraint that requires that all actors must have
names.
Description
Extends a classifier with the capability to own use cases. Although the owning classifier typically represents the subject to which the owned use cases apply, this is not necessarily the case. In principle, the same use case can be applied
to multiple subjects, as identified by the subject association role of a UseCase (see UseCase).
Attributes
No additional attributes
Associations
ownedUseCase: UseCase [0..1]References the use cases owned by this classifier. (Specializes Element.ownedElement.)
10-167
10 Basic::UseCases
Extend
Constraints
Semantics
See UseCase.
Notation
The nesting of a use case within a classifier is represented using the standard notation for nested classifiers (see Chapter 13, Common::Classes).
Examples
See UseCase
Rationale
This extension to the Classifier concept was added to allow classifiers to own use cases.
UML 1.x did not specifically allow a Classifier to own use cases.
Extend
This relationship specifies that the behavior of a use case may be augmented by an additional use case. The
extension takes place at one or more specific extension points defined in the extended use case. Note, however,
that the extended use case is defined independently of the extending use case. Use case extension is intended to
be used when there is some additional behavior that should be added, conditionally, to the behavior defined in
another use case (which is meaningful independently of the extending use case).
Description
Extend is a kind of Relationship, such that the source is the extending use case and the destination is the extended use
case. The extend relationship itself is owned by the extending use case.
Attributes
No additional attributes defined.
Associations
base : UseCase [ 1 ]
References the use case that is being extended. (Specializes Relationship.target.)
extension : UseCase [ 1 ]
References the use case that represents the extension and owns the extend relationship. (Specializes Relationship.source.)
condition : Constraint [ 0..1 ] References the condition that must hold when the first extension point is reached
for the extension to take place. If no constraint is associated with the extend relationship, the extension is unconditional. (Specializes Element.ownedElement.)
extensionLocation: ExtensionPoint [ 1..* ]

An ordered set of extension points in a use case, specifying where the extensions
are to be inserted. The order in which the elements of the extending use case are
to be inserted is determined by the ordering of the extension points.
10-168
10 Basic::UseCases
Extend
Constraints
[1] The extension points referenced by the extends relationship must belong to the use case that is being extended.
Semantics
The behavior specified by the extending use case is embedded in the behavior of the extended use case at the
appropriate extension points, provided that the condition of the extension is true at the time the first extension
point is reached. The net result is a single use case comprising the merged behavior of the two use cases.
As classifiers, use cases may have corresponding behaviors specified. If two use cases are associated with the
same subject, where one extends the other, than any behavior of the base use case is part of the behavior of the combination of both use cases. Every part of the extension use case identified by an extension point is included into the
definition of the base use case after the portion in the base use case identified by the corresponding extension point. A
corresponding extension point is an extension point with the same name.
Exactly how the behaviors are extended may differ according to the kind of Behavior.
The specifics of how the merging of behaviors between the extended and extending use case is done are left as a
semantic variation point.
Notation
An extend relationship between use cases is shown by a dashed arrow with an open arrowhead from the use case
providing the extension to the base use case. The arrow is labeled with the keyword extend. The condition of the
relationship as well as the references to the extension points are optionally shown in a Note attached to the corresponding extend relationship.(See Figure 10-99.)
Examples
The use case Perform ATM Transaction has an extension point Selection. This use case is extended via that
extension point by the use case On-Line Help whenever the customer selects the HELP key. Note that the Perform
ATM Transaction use case is defined independently of the On-Line Help use case.
Condition: {customer selected HELP}

extension point: Selection
extension points
Selection
extend
Perform ATM Transaction
On-Line Help
Figure 10-99. Example of an Extend relationship between use cases

Rationale
This relationship is intended to be used when there is some additional behavior that should be added, conditionally, to
the behavior defined in another use case (which is meaningful independently of the extending use case).
There are no changes to the 1.x definition of Extend, although some additional clarifications of the semantics have
been provided. The notation for conditions has been changed such that the condition may now be included in a Note
attached to the extend relationship, instead of merely being a textual comment that is located in the vicinity of the
relationship.
10-169
10 Basic::UseCases
ExtensionPoint
ExtensionPoint
Description
An ExtensionPoint is a feature of a use case that identifies a point where the behavior of a use case can be augmented
with elements of another (extending) use case.
Attributes
Associations
Constraints
[1] An ExtensionPoint must have a name.
self.name -> size = 1
Semantics
An extension point is a reference to a location within a use case at which parts of the behavior of other use cases may
be inserted. Each extension point has a unique name within a use case.
The specific manner in which the location of an extension point is defined is left as a semantic variation point.
Notation
Extension points are indicated by a text string within in the Use Case oval symbol or use case rectangle according
to the syntax below:
<extension point> ::= <name> [: <explanation>]
The name follows the normal rules for identifiers, while explanation, which is optional, may be any informal text
or a more precise definition of the location of the extension point definition.
Examples
See Figure 10-99 and Figure 10-104.
Rationale
ExtensionPoint support the use case extension mechanism (see Extend).
In 1.x, ExtensionPoint was modeled as a kind of ModelElement, which due to a multiplicity constraint, was always
associated with a specific use case. This relationship is now modeled as an owned feature of a use case. Semantically,
this is equivalent and the change will not be visible to users.
In UML 1.x, an ExtensionPoint could either represent a single extension point or a collection of extension points.
In UML 2.0, an ExtensionPoint represents only one extension point. Hence, ExtensionPoints from 1.x models that
represented collections need to be converted into individual ExtensionPoints.
ExtensionPoints in 1.x had an attribute called location, which was a kind of LocationReference. Since the latter
had no specific semantics it was relegated to a semantic variation point. When converting to UML 2.0, models in
10-170
10 Basic::UseCases
Include
which ExtensionPoints had a location attribute defined, the contents of the attribute should be included in a note
attached to the ExtensionPoint.
Include
An include relationship defines that a use case contains the behavior defined in another use case.
Description
Include is a directed relationship between two use cases, implying that the behavior of the included use case is
inserted into the behavior of the base use case. The base use case may only depend on the externally observable
behavior of the included use case. The use case that is included is always required in order for the base use case
to execute.
Attributes
Associations
addition : UseCase [ 1 ]
References the use case that is to be included. (Specializes Relationship.target.)
base : UseCase [ 1 ]
References the use case which will include the addition and owns the include
relationship. (Specializes Relationship.source.)
Constraints
Semantics
An include relationship between two use cases means that the behavior defined in the target use case is included in
the behavior of the base use case. The include relationship is intended to be used when there are common parts of the
behavior of two or more use cases. This common part is then extracted to a separate use case, to be included by all the
base use cases having this part in common. Since the primary use of the include relationship is for reuse of common
parts, what is left in a base use case is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base use case depends on the addition
but not vice versa.
More precisely, if a base use case includes an addition use case, then the behavior of the addition use case is
included as part of the base use case.
The precise semantics of the inclusion mechanism are left as a semantic variation point.
Notation
An include relationship between use cases is shown by a dashed arrow with an open arrow-head from the base use
case to the included use case. The arrow is labeled with the keyword include. (See Figure 10-100.)
10-171
10 Basic::UseCases
UseCase
Examples
A use case Card Identification includes in it an independently defined use case Withdrawl.
Card
Identification
include
Withdrawl
Figure 10-100. Example of the Include relationship

Rationale
The Includes relationship allows hierarchical composition of use cases as well as reuse of use cases.
There are no changes to the semantics or notation of the Include relationship relative to UML 1.x.
UseCase
A UseCase specifies that a certain behavior which yields an observable result for one or more actors can be performed by the subject. Use cases define the behavior of the subject without revealing its internal structure. Each use
case specifies some behavior, including variants, that the subject can perform in collaboration with one or more
actors.
Description
A UseCase is a kind of behaviored classifier that represents a declaration of a required behavior. Although it is a kind
of classifier, a use case is not directly instantiable; In the case that a use case is owned by a classifier, it specifies the
behaviors that must be supported by any instance of a classifier that owns the use case. These behaviors include
changes to the state of the subject and communications with its environment.
The set of use cases associated with a subject could be a physical system or any other element that may have
behavior, such as a component, subsystem or class. Each use case specifies a service that the subject provides to its
users, i.e., a specific way of interacting with the subject. A service, which is initiated by a user, must be complete. A
service is complete if after its performance the subject will be in a state in which the service could be initiated again.
A use case describes the interactions between the users and the subject as well as the responses performed by the subject, in the manner that these responses are perceived from outside the subject. A use case can include possible variations of its basic behavior, such as exceptional behavior or error handling.
Use cases can be used both for specification of the (external) requirements on a subject and for the specification
of the functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject
poses on its environment by defining how they should interact with the subject so that it will be able to perform its
services.
The behavior of a use case can be described by a specification that is some kind of Behavior (through its ownedBehavior relationship) or by pre-conditions and post-conditions as well as by natural language text where appropriate. The description of the behavior of a use case are strictly from the point of view of an external observer and do not
prescribe the internal structure or workings of the subject. Which of these techniques to use depends on the nature of
the use case behavior as well as on the intended reader. These descriptions can be combined.
The realization of a use case may be specified through associated Behaviors, e.g. a set of Interactions involving
the Classifiers that are defined as parts of the system. These may be associated with a Use Case directly (as an ownedBehavior, or via a Realization dependency), or indirectly through a Collaboration that uses the use case and its actors
as the classifiers that type its parts.
10-172
10 Basic::UseCases
UseCase
Attributes
Associations
subject : Classifier [ 0..* ]

References the subjects to which this use case applies. The subject or its parts
realize all the use cases that apply to this subject. Use cases need not be attached
to any specific subject, however. The subject may, but need not, own the use
cases that apply to it.
includes : Include [*]
References the Include relationships owned by this use case. (Specializes the
association between Element and Relationship that identifies the source end of a
Relationship.)
extends : Extend [*]
References the Extend relationships owned by this use case. (Specializes the
association between Element and Relationship that identifies the source end of a
Relationship.)
extensionPoint: ExtensionPoint [*]

References the ExtensionPoints owned by the use case. (Specializes Classifier.feature.)
Constraints
[1] A UseCase must have a name.
self.name -> size = 1
[2] UseCases can only be involved in binary Associations.

[3] UseCases can not have Associations to UseCases specifying the same entity.
Semantics
A use case is not directly instantiable if it is owned or realized by an instantiable classifier. In that case, a use
case specifies a set of behaviors that must be performed by the instances of the classifier realizing a use case. A
use case may, however, have associated instances if it is not owned by a classifier.
Every instance of a classifier realizing a use case must interact with its environment in the manner described
by the interaction between the use case and its associated actors.
Use cases may have associated actors, which describes that an instance of the classifier realizing the use case and
a user playing one of the roles of the actor interact. Two use cases specifying the same subject cannot be associated
since each of them individually describes a complete usage of the subject. It is not possible to state anything about the
behavior of the actor apart from its communications with the subject.
When an actor is associated with a use case and the multiplicity at the end attached to the use case is greater than
one, this implies that the instance playing the role of the actor interacts with several independent instances of classifiers realizing a use case concurrently.
Notation
A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case
placed below the ellipse. An optional stereotype keyword may be placed above the name and a list of properties
included below the name. If a subject (or system boundary) is displayed, the use case ellipse is visually located inside
the system boundary rectangle. Note that this does not necessarily mean that the subject classifier owns the contained
use cases, but merely that apply to that classifier. For example, the use cases shown in Figure 10-101 apply to the
ATMsystem classifier but are owned by various packages as shown in Figure 10-102.
10-173
10 Basic::UseCases
UseCase
ATMsystem
0..1
Card Identification
1
1
0..1
On-Line Help
Custom er
0..*
0..1
Perform ATM Transac tion
1
1
Bank
0.. *
0..1
1
Register ATM at Bank

1
Administrator
0..1
Read Log
Figure 10-101. Example of the use cases and actors for an ATM system.
10-174
10 Basic::UseCases
UseCase
Transaction Use Cases

condition: {customer selected HELP}
<<extend>>
Card Identification
On-Line Help
<<include>>
<<include>>
<<import>>
ATM Services
W ithdrawl
Deposit Funds
Transfer Funds
Administration
Read Log
Figure 10-102. Example of use cases owned by various packages

Extension points may be listed in a compartment of the use case with the heading extension points. The description of the locations of the extension point is given in a suitable form, usually as ordinary text, but can also be given
in other forms, such as the name of a state in a state machine, an activity in an activity graph, a precondition, or a
postcondition.
Use cases may have associations to general associations and dependencies to other classifiers, e.g. to denote
input/output, events and behaviors.
The detailed behavior defined by a use case is notated according to the chosen description technique, in a separate diagram or textual document. Operations and attributes are shown in a compartment within the use case.
Use cases and actors may be depicted in a Collaboration diagram. In that case, the system boundary may be displayed
explicitly.
ATMcollaboration1
:W ithdra wl
: Bank
:Customer
:Transfer Funds
Figure 10-103. Example of a use case collaboration diagram for withdrawal and transfer of funds.
10-175
10 Basic::UseCases
UseCase
A use case can also be shown using the standard class rectangle with an ellipse icon in the upper-right-hand corner of
the rectangle with optional separate list compartments for its features. This rendering is more suitable when there are
a large number of extension points.
OrderStationery : PlaceOrder
extension points
order created : in Created state
order processed : in Processed state
order cancelled : in Cancelled state
order rejected : in Rejected state
order completed : in Completed state
order destroyed : in Destroyed state
order delivered : in Delivered state
order obfuscated : in Obfuscated state
Figure 10-104. Example of the classifier based notation for a use case.
Examples
See Figure 10-99 through Figure 10-104.
Rationale
The purpose of use cases is to identify the required functionality of a system.
There was no explicit metamodel relationship between use cases and their corresponding subject in UML 1.x.
10-176
Part II. UML::Common

This part describes the package structure and contents of the UML::Common package, which defines the commonconstructs that are used to define the major diagram types. The Common package is one of the top-level packages that
defines the UML. The relationship of the Common package to the other top-level packages is shown in Figure 10-1.
UML
Complete
import
Common
import
Basic
import
Foundation
Figure 10-1. The Common package is owned by the UML package.
Part-Common.fm Version 2 beta R1
177
10 UML::Common
The Common package, which imports the Basic package, consists of the subpackages shown in Figure 10-2.
Kernel
(from Foundation)
Ports
Deployments
Collaborations
Basic
(from UML)
Components
CommonBehaviors
Actions
IndirectComponents
StateMachines
Activities
Figure 10-2. The contents of the Common package.

The function and contents of these packages are described in separate chapters, corresponding to each package.
178
179
10 UML::Common
180
181
10 UML::Common
182
Chapter 11. Common::Actions

When an action violates aspects of static UML modeling that constrain runtime behavior, the semantics is left undefined. For example, attempting 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. The modeler must determine when minimum multiplicity should be
enforced..
Actions
(from Basic)
Internal
Structures
(from Basic)
CommonBehaviors
(from Common)
Actions
Figure 11-1. Dependencies of the Common::Actions package

Composite Actions
Composite actions are recursive structures that permit complex actions to be composed from simpler actions. In
additino, composite actions provide for control structures beyond explicit data flows and control flows.
There are three kinds of composite action. 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. Loop actions permit the repeated execution of a subaction depending on the value of executing a test action.
Groupings may be nested, and may have control flow dependencies. Data flows are routed to the subactions involved.
A conditional action comprises a group of clauses that execute concurrently, subject to an optional ordering constraints among their executions. 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 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.
Some iterations require sequential execution and can be represented by a loop action. A loop action comprises a
single clause that, in turn, consists of 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 Chapter 20, Complete::Actions.)
Read Write Actions
Objects, attributes, links, and variables have values that are available to actions. Objects can be created and
destroyed; attributes and variables have values; links can be created and destroyed, and can reference values through
their ends; all of which are available to actions. Read actions get values, while write actions modify values and create
1-183
11 Common::Actions
and destroy objects and links. Read and write actions share the structures for identifying the attributes, links, and variables they access. Note that this chapter refers to qualifiers to simplify the presentation. Qualifiers are optional and
can be ignored in this chapter (but are relevant for Chapter 20, Complete::Actions). Read actions do not modify the
values they access, while write actions have only limited effect.
Object actions create and destroy objects (see Figure 11-3). Attribute actions support the reading and writing of
attributes(see Figure 11-4). 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 semantics for static attributes is undefined. Association actions operate on associations and links. The metaclasses shown in Figure 11-5 identify links used by the association actions in Figure 11-6 and Figure 11-7. In the
description of these actions, the termassociations does not include those modeled with association classes,
unless specifically indicated. Similarly, a link is not a link object unless specifically indicated. The semantics of
actions that read and write associations that have a static end is undefined. Variable actions support the reading and
writing of variables. 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.
Computation Actions
Computation actions transform a set of input values to a set of output values by invoking a behavior. Primitive functions represent functions from a set of input values to a set of output values. The execution of a primitive function
depends only on the input values and has no other effect than to compute output values. A primitive function does not
read or write attribute or link values, nor otherwise interact with object memory or other objects. Its behavior is completely self-contained. Specific primitive functions are not defined in the UML, but would be defined in domain-specific extensions. Typical primitive functions would include arithmetic, Boolean, and string functions.
Jump Actions
All flow of control for a procedure could use fully nested flow-of-control constructs, but this style can be awkward
and obscure when dealing with unusual or exceptional conditions in the execution of a procedure. Programming languages often include constructs such as break, continue, and exceptions for dealing with these situations. When a
unusual 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.
Albeit jump handling does not provide additional expressive power, experience with programming languages has
shown that a purely linear flow-of-control program organization obscures its fundamental structure and makes
change difficult. Jump handling permits separation of concerns between normal control flow and unusual situations
that require special handling.
1-184

+subaction
[ownedElement]
0..*
+test
Action
Element
(from Actions)
(f rom Ke rne l)
0..*
+test
0..*
+body
0..*
+predecessorClause
+body
0..1
Compos iteAction
*
Clause
0..1
Namespace
1..*
(from Kernel)
GroupAction
+clause
[ownedElement]
+testOutput
0..1
0..1
+successorClause
1
LoopAction
isTestedFirst : Boolean
ConditionalAction
isDet erminate : Boolean
ValueDenotation
(f rom Common Beha vio r)
+groupAction
+scope
+variable
[ownedMember]
+t estOutput
ConnectableElement
Variable
(from InternalStructure)
If an output pin, owned by

a subordinate action. Must
be Boolean.
TypedElement
(from Kernel)
Figure 11-2. The metaclasses declared in the Composite Actions package.
PrimitiveAction
(from Action Foundati......
InputPin
(from Action Foundation)
+input
[input]
0..1
CreateObjectAction
1
+classifier
Classifier
(from Class ifiers)
DestroyObjectAction
0..1
+result
[output]
OutputPin
Figure 11-3. common object actions
1-185
11 Common::Actions
PrimitiveAction
(from Acti ons )
Attribute
(from Kernel)
* Attrib uteAction
0..1
+attribute
1
+object
[input]
0..1
Input Pin
(from Acti ons)
W riteAttrib uteAction
ClearAttributeAction
AddAttributeValueAction
isReplaceAll : Boolean [1..1] = false
RemoveAtt ri buteValue Act ion
ReadAtt ri buteActi on
0.. 1
+result
[output]
OutputPin
(from Actions)
+value
[input]
0..1
0..1
InputPin
+insertAt
[input]
(from Actions)
Figure 11-4. Attribute actions
PrimitiveAction
(from ActionFoundation)
0..1
Link Act ion

1
+input
[input]
1..*
Input Pin
(from ActionFoundation)
2..*
0..1
0..1
+value
+endData
[ownedElement]
+e nd
LinkEndDat a
*
AssociationEnd
(from Kernel)
Figure 11-5. Link identification
1-186
PrimitiveAction
(from Actio ns)
2.. *
Link Action
LinkEndData
+endData
[ownedElement]
0..1
ReadLinkAction
Out putPi n
(from Actions)
+result
[out put]
Figure 11-6. Read link action

Prim itiv eAc tion
(from Actions)
ClearAs s ociationAction
Link Action
0..1
2..*
0..1
+endData
[ownedElem ent]
+o bje ct
[inp ut]
LinkEndData
Wri teLink A ction
InputP in
(f rom Actions)
+a s so ciatio n 1
As s oci ati on
(f rom Ke rnel)
LinkEndCreationData
2..*
CreateLinkAction
Des tr oyLi nkAction
is ReplaceAll : Boolean = fals e +[endData]

0..1
0..1
+ins ertAt
InputPin
(f rom Actions)
Figure 11-7. Write link actions
1-187
11 Common::Actions
PrimitiveAction
(from Acti ons)
Variab leAction
*
0..1
ReadVariableAction
Variable
+variable
ClearVariableAction
W riteVariableAction
0..1
[ outpu t]
+result
AddVari ableValueActi on
OutputPin
RemoveVari ableValueAction
isReplaceAll : Boolean = false
(from Actions)
+value
[input]
1
InputPin
0.. 1
0.. 1
+insertAt
[input]
(from Acti ons)
Figure 11-8. Variable actions
InputPin
PrimitiveAction
(from Acti ons)
(from Acti ons)
+first
[ input]
1 +second
[input]
0..1
0..1
TestIdentityAction
ReadSelfAction
0..1
0..1
+result
[output]
OutputPin
+resul t
[output]
OutputPin
(from Acti ons)
(from Acti ons)
Figure 11-9. Other actions.
1-188
B ehavior
P rim itiveA ction
(fro m Co mmo n B e h a vio r)
(fro m A ctio n s)
Prim i ti veFunc tion

body : St ri ng
lan guage : S t ri ng [0..1]
1
+function
ApplyFuncti onA ction
+ resul t
[output]
{ordered} *
Outp utPi n
(f ro m A c ti o ns)
+argum e nt
[input]
*
InputPin
(fro m A ctio n s)
Figure 11-10. Computation action
BehaviorI nvocat ion

(from Com monBehaviors)
PrimitiveAction
CallBehaviorAction
isSynchronous : Boolean...` rue
+argument
[input, argument]
ValueSpecif ic ation
(from Kern...
+result
[output, result]
OutputPin
Figure 11-11. Invoking behavior.
1-189
11 Common::Actions
Action (extended)
Si gnal
(f rom Co mmo nB ehavio r)
+j um pT yp e
Hand l erAction
+body
+j um pHandl er
1
0 .. 1
0..1
0..1
+ ju mp Handler
* {ordered}
OutputPi n
Jum pHandl er
1..*
+h andlerOut put
+body
[suba cti on]
+protectedAction
(from Actions)
Acti on
(f romA ctions)
+j um pVal ue
[ou tpu t]
Action
(from Actions)
Pri miti veActi on

(from Actions)
InputPin
(from Actions)
+jum pVal ue
[i nput]
0..1
Jum pAction
Figure 11-12. Jump actions and supporting classes
Action (extended)
Associations
jumpHandler: JumpHandler [0..*]Designates a set of JumpHandlers whose jump types apply to the action.
Constraints
[1] The number of externally-accessible output pins of the handler action associated with the jump handler and those
of the owning action must be equal.
Operations
[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
Procedure
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
1-190
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
Semantics
If a jump occurs during the execution of an action, the execution of the action is abandoned and no output is generated by this action. If a jump handler whose jump type is the same or an ancestor of the type of the jump object is
associated with this action, the body action of the jump handler is invoked (see JumpHandler). Otherwise the jump
propagates to the enclosing action. Actions concurrent to the current action must be complete before the jump is propagated.
Rationale
The attachment of handlers to a scope within a program and the execution of non-standard flow of control if an
exceptional situation occurs is supported in many modern programming languages. Some languages even permit execution to be suspended and then resumed after the execution of a handler, but this semantics tends to be fraught with
dependencies. A simpler model of execution is adopted, which does not allow the restart of a compution in which an
exceptional situation had occurred.
This feature did not exist in UML 1.4.
AddAttributeValueAction
AddAttributeValueAction is a write attribute action for adding values to an attribute.
Description
Attributes are potentially multi-valued and ordered, so the action supports specification of insertion points for new
values. It also supports the removal of existing values of the attribute before the new value is added.
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 values multiplicity is
1..1.
Attributes
isReplaceAll : Boolean [1..1] = falseSpecifies whether existing values of the attribute of the object should be
removed before adding the new value.
Associations
insertAt : InputPin [0..1]
(Specialized from Action:input) 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-191
11 Common::Actions
AddVariableValueAction
Constraints
[1] Actions adding a value to ordered attributes must have a single input pin for the insertion point with type ValueSpecification 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.isOrdered = #false
then insertAtPins->size() = 0
else let insertAtPin : InputPin = insertAts->asSequence()->first() in
insertAtPins->size() = 1
and insertAtPin.type = ValueSpecification
and insertAtPin.multiplicity.is(1,1))
endif
Semantics
If isReplaceAll is true, then the existing values of the attribute are removed before the new one added, except if the
new value already exists, then it is not removed under this option. If isReplaceAll is false, then adding an existing
value has no effect.
Values of an attribute may be ordered or unordered, even if the multiplicity maximum is 1.Adding values to ordered
attributes requires an insertion point for a new value using the insertAt input pin. The insertion point is a positive integer giving the position to insert the value, or an instance of LiteralNull, to insert at the end.. 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. An instance of LiteralNull 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 insertion point is required for ordered attributes and omitted for
unordered attributes. Reinserting an existing value at a new position moves the value to that position (this works
because attribute values are sets).
The semantics is undefined for adding a value that violates the upper multiplicity of the attribute. Removing a value
succeeds even when that violates the minimum multiplicitythe same as if the minimum were zero. The modeler
must determine when minimum multiplicity of attributes should be enforced.
The semantics is undefined for adding a new value for an attribute with changeability readOnly or removeOnly after
initialization of the owning object.
Notation
None.
Examples
None.
Rationale
AddAttributeValueAction is introduced to add attribute values. isReplaceAll is introduced to replace and add in a single action, with no intermediate states of the object where only some of the existing values are present.
Changes from previous UML
AddAttributeValueAction is new in UML 2.0.
AddVariableValueAction
AddVariableValueAction is a write variable action for adding values to a variable.
1-192
Description
Variables are potentially multi-valued and ordered, so the action supports specification of insertion points for new
values. It also supports the removal of existing values of the variable before the new value is added.
Attributes
isReplaceAll : Boolean [1..1] = falseSpecifies whether existing values of the variable should be removed before
adding the new value.
Associations
(Specialized from Action:input) Gives the position at which to insert a new value
or move an existing value in ordered variables. This pin is omitted for unordered
variables.
Constraints
[1] Actions adding values to ordered variables must have a single input pin for the insertion point with type ValueSpecification and multiplicity of 1..1, otherwise the action has no input pin for the insertion point.
if self.variable.ordering = #unordered
endif
Semantics
If isReplaceAll is true, then the existing values of the variable are removed before the new one added, except if the
new value already exists, then it is not removed under this option. If isReplaceAll is false, then adding an existing
value has no effect.
Values of an variable may be ordered or unordered, even if the multiplicity maximum is 1.Adding values to ordered
variables requires an insertion point for a new value using the insertAt input pin. The insertion point is a positive integer giving the position to insert the value, or an instance of LiteralNull, to insert at the end.. 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. An instance of LiteralNull 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 insertion point is required for ordered variables and omitted for
unordered variables. Reinserting an existing value at a new position moves the value to that position (this works
because variable values are sets).
The semantics is undefined for adding a value that violates the upper multiplicity of the variable. Removing a value
succeeds even when that violates the minimum multiplicitythe same as if the minimum were zero. The modeler
must determine when minimum multiplicity of variables should be enforced.
Notation
None.
Examples
None.
1-193
11 Common::Actions
ApplyFunctionAction
Rationale
AddVariableValueAction is introduced to add attribute values. isReplaceAll is introduced to replace and add in a single action, with no intermediate states of the variable where only some of the existing values are present.
AddVariableValueAction is new in UML 2.0.
ApplyFunctionAction
Description
Invokes a primitive predefined function that computes output values based only on the input values and the function.
The execution does not have access to object memory or to any objects. The execution of a primitive function has no
side effects on any other object.
Attributes
None.
Associations
argument : InputPin
The pins that provide inputs to the function. (Specializes Action.input.)
function : PrimitiveFunction [1]The primitive function to be invoked.
result : OutputPin
The pins on which the results of invokiug the function are returned. (Specializes
Action.output.)
Stereotypes
None.
Tagged Values
None.
Constraints
[1] The number and types of the input arguments and output result pins are derived from the parameters of the function.
self.argument->size( ) = self.function.formalParameter->size( )
and Sequence {1..self.argument->size( )}
-> forAll (i:Integer |
let argumenti = self.argument->at(i) in
let inparameteri = self.function.formalParameter->at(i) in
argumenti.type = inparameteri.type)
and self.result->size( ) = self.function.returnedResult->size( )
and Sequence {1..self.result->size( )}
-> forAll (i:Integer |
let resulti = self.result->at(i) in
let outparameteri = self.function.returnedResult>at(i) in
resulti.type = outparameteri.type)
1-194
Semantics
The result values are computed from the input values according to the given function. During the execution of the
computation, no communication or interaction with the rest of the system is possible. The amount of time to compute
the results is undefined.
The result values are placed on the output pins of the action execution and the execution of the apply function
action is complete. Primitive functions may raise exceptions for certain input values, in which case the computation is
abandoned (see JumpHandler).
Notation
None.
Presentation Option
None.
Examples
None.
Rationale
ApplyFunctionAction is introduced to invoke behaviors that are external to the modeled system.
This metaclass was not present in 1.x.
AttributeAction
AttributeAction is an abstract primitive action class for all attribute actions.
Description
This abstract action class statically specifies the attribute being accessed.
1..1.
Attributes
None.
Associations
attribute : Attribute [1..1]
Attribute to be read.
object : InputPin [1..1]
(Specialized from Action:input) 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.
Constraints
[1] The attribute must have not be static.
self.attribute.isStatic = #false
[2] The type of the input pin is the same as the classifier of the attribute.
1-195
11 Common::Actions
CallBehaviorAction
self.object.type = self.attribute.featuringClassifier
[3] The multiplicity of the input pin must be 1..1.

self.object.multiplicity.is(1,1)
[4] 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.featuringClassifier.type
or (self.attribute.visibility = #protected and host.allSupertypes
->includes(self.attribute.featuringClassifier.type)))
Semantics
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 for static attributes 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.
Notation
None.
Examples
None.
Rationale
AttributeAction is introduced for the abstract aspects of attribute actions.
AttributeAction is new in UML 2.0.
CallBehaviorAction
Description
Invokes a behavior directly rather than invoking a behavioral feature that, in turn, results in the invocation of that
behavior. The argument values of the action are available to the execution of the invoked behavior. The execution of
the call behavior action waits until the execution of the invoked behavior completes and a result is returned on its output pin.
Attributes
isSynchronous: Boolean
If true, the call is synchronous and the caller waits for completion of the invoked
behavior. If false, the call is asynchronous and the caller proceeds immediately
and does not expect a return values.
Associations
A list of values that are the arguments to be passed to the invoked behavior. (Specializes BehaviorInvocation.argument and Action.input.)
1-196
A list of output pins that receive the output values generated by the invoked
behavior (including return parameters, out parameters, and in-out parameters).
Constraints
[1] The number of argument pins and the number of formal parameters of the behavior of type in and in-out must be
equal.
[2] The number of result pins and the number of formal parameters of the behavior of type return, out, and in-out
must be equal.
[3] The type, ordering, and multiplicity of an argument or result pin is derived from the corresponding formal parameter of the behavior.
Semantics
[1] When all the control and data flow prerequisites of the action execution are satisfied, the designated behavior is
invoked. as specified in Chapter 15, Common::CommonBehaviors. Copies of the argument values are available to the invoked behavior.
[2] If the call is asynchronous, the caller proceeds immediately and the execution of the call behavior action is complete. If the call is synchronous, the caller is blocked from further execution until it receives the return values
from the invoked behavior.
[3] If the call is synchronous, when the execution of the invoked behavior completes, copies of the return result values are placed on the result pins of the call operation action, and the execution of the action is complete. If the
execution of the invoked behavior yields an exception, the exception is transmitted to the caller where it is
reraised as an exception in the execution of the calling action. Possible exception types may be specified by
attaching them to the called Operation as raisedException associations.
The mechanism for determining the method to be invoked as a result of a call operation is unspecified.
Notation
None
Examples
None
Rationale
Invokes a behavior without the interference of a behavioral feature.
This metaclass has been added in 2.0
Clause
Description
A clause is a part of a conditional action. A clause contains a test action and a set of body actions. The execution of
the body actions is contingent on the corresponding test action producing a true value. A clause designates a value
1-197
11 Common::Actions
Clause
denotation as the test output, which must have type Boolean; the body actions are only executed if the test output
denotes the value true. (Typically, the test output is an output pin of the test action.)
Associations
test : Action [0..*]
A set of actions whose Boolean result (designated by testOutput) must be true for
execution of the body action to proceed.
testOutput : ValueDenotation [1]

If this value denotation evaluates to true, the body actions may execute.
body : Action[0..*]
A set of actions whose execution is contingent on testOutput.
predecessorClause : Clause
The set of clauses that must fail before this clause can execute its test action.
successorClause : Clause
The set of clauses that cannot execute their test actions unless this clause fails.
Attributes
None.
Operations
[1] This operation returns the transitive closure of all successors of this clause.
allClauseSuccessors() : Set(Clause)
allClauseSuccessors() = self.successorClause>union(self.successorClause.allClauseSuccessors()>asSet())
Constraints
[1] 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)
[2] 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.predecessor->union(action.successor)->forAll(a : Action | a.isSubaction(self.test))
[3] None of the actions within the body actions of a clause (if any) may have control-flow connections with actions
outside the body actions.
self.body->allSubactions()->forAll(action : Action |
action.predecessor->union(action.successor)->forAll(a:Action | a.isSubaction(self.body))
[4] The test action of a clause may not participate in control flows.
self.test.predecessor>isEmpty() and self.test.successor>isEmpty()
[5] There cannot be any cycles in the predecessor/successor relationships among clauses.
self.allClauseSuccessors()>excludes(self)
[6] If the test output is an output pin, it must belong to the test action.
[7] The output pins of the test action must not be connected by data flow to input pins outside the clause.
[8] The output pins of the body actions must not be connected by data flow to input pins outside the clause nor to the
input pins of the test action.
Semantics
A clause does not have prerequisites, but it may have predecessor clauses, which must be clauses in the same conditional action. If a clause has one or more predecessor clauses, then it must wait for these to fail before it can execute.
1-198
If all the predecessor clauses of a clause fail, then the test action of the clause is executed (assuming all data-flow
prerequisites of the test action are satisfied). The clause succeeds if its test output is true; the clause fails, if its test
output is false.
If a predecessor clause succeeds, then a successor clause of it will execute neither its test nor its body.
If a clause succeeds, its body actions may be executed, if the clause is selected by the conditional action that
owns it. If at least one clause succeeds, then the body of exactly one clause of a conditional action will be executed.
Notation
None.
Examples
None.
Rationale
Not applicable.
ClearAttributeAction
ClearAttributeAction is an attribute action that removes all values of an attribute.
Description
This action removes all values of an attribute.
Attributes
None.
Associations
None.
Constraints
None.
Semantics
All values are removed even when that violates the minimum multiplicity of the attributethe same as if the minimum were zero. The semantics is undefined if the attribute changeability is addOnly, or the attribute changeability is
readOnly after initialization of the object owning the attribute, unless the attribute has no values. The action has no
effect if the attribute has no values.
Notation
None.
Examples
None.
1-199
11 Common::Actions
ClearAssociationAction
Rationale
ClearAttributeAction is introduced to remove all values from an attribute in a single action, with no intermediate
states where only some of the existing values are present.
ClearAttributeAction is new in UML 2.0.
ClearAssociationAction
ClearAssociationAction is a primitive action that destroys all links of an association in which a particular object participates.
Description
This action destroys all links of an association that have a particular object at one end.
Attributes
None.
Associations
association : Association [1..1]
Association to be cleared.
(Specialized from Action:input) Gives the input pin from which is obtained the
object whose participation in the association is to be cleared.
Constraints
[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(end.type = self.object.type)
[1] The multiplicity of the input pin is 1..1.

Semantics
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.
Notation
None.
Examples
None.
Rationale
ClearAttributeAction is introduced to remove all values from an attribute in a single action, with no intermediate
states where only some of the existing values are present.
1-200

ClearAttributeAction is new in UML 2.0.
ClearVariableAction
ClearAttributeAction is a variable action that removes all values of an variable.
Description
This action removes all values of an variable.
Attributes
None.
Associations
None.
Constraints
None.
Semantics
All values are removed even when that violates the minimum multiplicity of the variablethe same as if the minimum were zero.
Notation
None.
Examples
None.
Rationale
ClearVariableAction is introduced to remove all values from an variable in a single action, with no intermediate states
where only some of the existing values are present.
ClearVariableAction is new in UML 2.0.
CompositeAction
Description
A composite action composes a set of subordinate actions into a unit. The actions may form a sequence, a concurrent
set, or some combination thereof. A composite action does not own any pins of its own. Data flows are not connected
to a composite action, instead they may connect to input and output pins of actions within the composite action.
Composite actions can be predecessors and successors in control flows, and thus they provide the ability to synchronize the execution of sets of actions. A control flow whose destination is a composite action requires that the pre-
1-201
11 Common::Actions
ConditionalAction
decessor must complete before any of its subactions may begin execution. A control flow whose source is a
composite action requires that all the subactions must complete before the successor may begin execution.
Associations
None.
Attributes
None
Operations
None.
Constraints
None.
Semantics
See the concrete subtypes of CompositeAction for details.
If a jump is propagated from the execution of a subaction, the jump is considered raised in the execution of the composite action. If there are other active subactions, they must complete before jump handling can continue. Such concurrent executions cannot be terminated. However, action executions that have not yet started due to their control
flow prerequisites not being satisfied will not start, as their prerequisites will never be satisfied. When there are no
active subactions, the execution of the composite action is terminated and the jump is raised. If more than one subaction propagates a jump, it is indeterminate which jump will be propagated to the composite action execution.
Notation
None.
Examples
None.
Rationale
Not applicable.
ConditionalAction
A conditional action provides for the conditional execution of contained actions depending on the result of test
actions.
A conditional action consists of a number of clauses, each of which may have a test action and a set of body
actions. Each clause designates a value denotation as a test output. The test action of a clause, if present, may not execute unless all the predecessors of the clause not only have completed execution, but have also failed.
A conditional action has no explicit input pins of its own. 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). Test and body actions may or may not use the same input values.
1-202
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
clause suceeds, nevertheless the body actions of only one clause will be executed. The selection of the clause the
body actions of which will be executed is indeterminate. One may provide a default clause which always succeeds as
a successor of all other clauses. It may also be the case that no body actions execute (i.e., when all clauses fail).
When it is known that the clauses of a conditional action will be both exhaustive and mutually exclusive, the conditional action may be tagged as being determinate. In this case, exactly one clause must succeed.
Description
A conditional action consists of a set of one or more clauses, at most one of whose body actions are executed during
the execution of the conditional action. If more than one clause succeeds, exactly one of these clauses is selected and
its corresponding body actions are executed, but it is unspecified which one.
Associations
clause : Clause [1..*]
The set of clauses contained in the conditional action.
Attributes
isDeterminate : Boolean
If true, then whenever the conditional action is executed, exactly one clause
must succeed. If this assertion is violated by the action, the model is ill formed.
(Note that in general it may be difficult or impossible to verify automatically
whether this assertion is satisfied by a given model.)
Constraints
[1] 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] 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()))
Semantics
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 at most one clause with a
test output yielding true is executed.
[1] When the control and data flow prerequisites of a conditional action are satisfied, its clauses are enabled.
[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 all of its predecessor clauses have failed.
[3] If a clause succeeds, the body actions of that clause may be executed. If multiple clauses succeed, nevertheless
the body actions of only one clause will be executed, but the choice of which clause is selected is not specified.
[4] If the body actions of the selected clause have completed execution, then the conditional execution completes and
the control flow prerequisite is satisfied for any successor actions.
[5] If all clauses failed, then the conditional execution completes and the control flow prerequisite is satisfied on any
successor actions.
If a jump is not handled by the execution of the test action of a clause and no other clauses are executing, the jump
propagates to the conditional execution itself, and the execution of the conditional is terminated. If some clause suc-
1-203
11 Common::Actions
CreateLinkAction
ceeds, execution of its body may proceed in spite of a jump in the test action from another clause. If a jump is not
handled by the execution of a body action of a clause, the jump propagates to the conditional action itself.
Notation
None.
Examples
None.
Rationale
Not applicable.
CreateLinkAction
CreateLinkAction is a write link action for creating links.
Description
This action can be used to create links and link objects. There is no return value in either case. This is so that no
change of the action is required if the association is changed to an association class or vice versa. CreateLinkAction
uses a specialization of LinkEndData called LinkEndCreationData, to support ordered associations. 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 an instance of LiteralNull, to insert at the end. Reinserting an existing end at a new position moves the end to that position.
CreateLinkAction also uses LinkEndCreationData to support 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.
Attributes
None.
Associations
endData : LinkEndCreationData [2..*] (Specialized from LinkAction:endData) Specifies ends of association

and inputs.
Constraints
[1] The association cannot be an abstract classifier.
self.association().isAbstract = #false
Semantics
CreateLinkAction creates a link or link object for an association or association class. It 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.
1-204
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 readOnly or removeOnly
after initialization of the other end objects, unless the link being created already exists. Objects participating in the
association across from a addable end can have links created as long as the objects across from the readOnly or removeOnly ends are still being initialized. This means that objects participating in links with two or more readOnly or
removeOnly 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 ValueSpecification 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 that is an instance of LiteralNull 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.
Notation
None.
Examples
None.
Rationale
CreateLinkAction is introduced to create links.
CreateLinkAction is new in UML 2.0.
CreateObjectAction
CreateObjectAction is a primitive action that creates an object that conforms to a statically specified classifier and
puts it on an output pin at runtime.
Description
This action instantiates classifier. The semantics is undefined for creating objects from abstract classifiers or from
association classes.
Attributes
None.
1-205
11 Common::Actions
DestroyLinkAction
Associations
classifier : Classifier [1..1] Classifier to be instantiated.
result : OutputPin [1..1]
(Specialized from Action:output) Gives the output pin on which the result is put.
Constraints
[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 type 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)
Semantics
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.
Notation
None.
Examples
None.
Rationale
CreateObjectAction is introduced for creating new objects.
CreateObjectAction replaces CreateAction from UML 1.4.
DestroyLinkAction
DestroyLinkAction is a write link action that destroys links and link objects.
Description
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.
Attributes
None.
1-206
Associations
None.
Constraints
None.
Semantics
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 readOnly
after initialization of the other end objects, unless the link being destroyed does not exist. Objects participating in the
association across from a removable end can have links destroyed as long as the objects across from the readOnly
ends are still being initialized. This means that objects participating in links with 2 or more addOnly ends cannot have
links destroyed. Same for objects participating in 2 or more readOnly ends, unless all the linked objects are being initialized.
Notation
None.
Examples
None.
Rationale
DestroyLinkAction is introduced for destroying links.
DestroyLinkAction is new in UML 2.0.
DestroyObjectAction
DestroyObjectAction is a primitive action that destroys objects.
Description
This action destroys the object on its input pin at runtime. The object may be a link object, in which case the semantics of DestroyLinkAction also applies.
Attributes
None.
Associations
input : InputPin [1..1]
(Specialized from Action:input) The input pin providing the object to be

destroyed.
Constraints
self.input.multiplicity.is(1,1)
1-207
11 Common::Actions
GroupAction
[2] The input pin has no type.

self.input.type->size() = 0
Semantics
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.
Notation
None.
Examples
None.
Rationale
DestroyObjectAction is introduced for destroying objects.
DestroyObjectAction replaces DestroyAction from UML 1.4.
GroupAction
Description
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 be made from actions outside the group to pins owned by actions within the
group action. The group action may participate in control flows and actions within the group action and 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. Similarly, there is an implicit control flow from each action in the group action to the group
action. 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).
A set of local variables can be declared in association with a group action. The group action serves as the
namespace for these variables.
Associations
subaction : Action
The set of actions contained in this group action.
variable : Variable {ordered}
The set of variables declared with this group action as their scope.
Attributes
None.
Constraints
[1] A group action may not have data flow prerequisites.
Operations
[1] This operation returns all subactions of an action, nested to any depth.
1-208
allSubactions() : Set(Action)
allSubactions() = self.subactions()>union(self.subactions().allSubactions())
Semantics
A group action execution is enabled when the execution of all its prerequisite actions have completed. A control flow
from or to a group action is treated as a set of control flows from or to each subaction within the group action. The
subactions of a group action may not start executing until the group action execution as a whole is enabled. A subaction may have its own prerequisite data and control flows that must be satisfied before the subaction may execute.
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
from the group action itself will not be triggered until the group action execution is complete.
A group action may also act as the namespace for a set of local variables. The execution of the group action
therefore also maintains the state of those variables.
[1] A group action begins execution when all of its control flow prerequisites are satisfied. 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.
[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 become inaccessible. Any control flow prerequisites in which the group
action is a predecessor are satisfied.
Notation
None.
Examples
None.
Rationale
Not applicable.
HandlerAction
As in many programming languages, exceptions may occur implicitly during the execution of certain actions, and
exceptions may also be raised explicitly. The occurrence of an exception terminates the execution of the current
action and causes control to jump to an enclosing action which has an exception handler to catch the particular type of
exception.
An exception handler is modeled as a jump handler that catches an object of the given jump type. A jump object
mahy have attributes that represent the details of an exception. Through these attributes, information can be communicated to the jump handler about the circumstances that caused the exception which can be used by the exception
handler to handle the exceptional situation.
1-209
11 Common::Actions
HandlerAction
Note: The 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 the Exception
metaclass. It is those syntactic control constructs that are being addressed by jump handling.
Description
An action may have zero or more jump handlers associated. If a jump occurs during the execution of an action protected by a jump handler whose type is the same or an ancestor of the jump type, then the handler action is executed.
The handler action has one internal output pin which holds the jump object, making it available within the handler
action. A handler action also designates a list of output pins of its body actions that match in multiplicity, ordering,
and types the outputs of the protected action. If it does not have a list of output pins, it may still catch a jump, but it
must execute another jump rather than completing normally (otherwise the outputs of the protected action would not
be defined properly). The handler action executes its body action . The jump value is available to the body action via
the internal output pin.
Associations
body: Action [1]
The action that is triggered by the jump handler. The jump value 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 those designated as handlerOutput.
handlerOutput: OutputPin [0..1]A list of output pins owned by the body action but designated as output by the
handler. After completion of execution of the body action, the values on these
pins are copied to the output pins of the protected action, and the successor
actions of the protected action are enabled as if the protected action had completed normally.
jumpHandler: JumpHandler [1..*]

The jump handlers that map the handler action to the action or actions they protect and the jump type(s) that they handle.
jumpValue: OutputPin [1]
An internal output pin owned by the handler action. During the execution of the
handler action, the jump value generated by the jump action is available to the
body action on this pin.
Constraints
[1] If present, the type of each handler output pin is the same as the type of the corresponding output pin of the
actions protected by the associated jump handler. The multiplicity and ordering are the same as the corresponding multiplicities and orderings of the protected action.
[2] The jumpValue output pin must not be connected by data flow to pins outside of the handler action.
Semantics
See JumpHandler.
Notation
None.
1-210
Examples
None.
Rationale
A handler action provides the ability to encapsulate specification of unexpected and erroneous behavior that is
otherwise awkward to deal with by relying only on linear control flow. Programming language control constructs
such as break and continue may be modeled as the causing of explicit, predefined jump types. These propagate the
same as exceptions and are caught by jump handlers attached to enclosing control actions. Such break/continue jumps
would usually have no parameters.
This metaclasses did not exist in UML 1.4.
JumpAction
A jump is a condition that occurs synchronously during the execution of an action and causes the normal execution
sequence to be abandoned, resulting in an alternate execution sequence. This allows to predefine conditions (usually
exceptional or error situations), under which the execution of an action is aborted, causing execution to continue at a
different locale.
When a jump occurs, execution jumps to an enclosing level having a handler for the given type of jump. The
handler may perform actions to deal with the situation, allowing ordinary execution to resume following the actions
performed by the jump handler. A jump is typically used to deal with a situation that is inconvenient to handle using
linear flow of control. Jumps are often used to deal with unexpected inputs or situations regarded as errors, such as
exceptions or abnormal results, but they are not restricted to such use and they may be considered as merely another
control construct, albeit one that results in an execution sequence which might be difficult to trace. The break and
continue statements common in many programming languages are a typical use of jumps as a static control construct.
Exception handling mechanisms are a typical use of jumps as a dynamic control construct.
A jump type is a signal (a kind of classifier). The occurrence of a jump is manifested as an instancea jump
objectof the given jump type. The type of the object will be used to indicate what kind of situation caused the jump.
The jump object may have attributes which provide additional data.
Jumps may be explicitly caused by jump actions. Primitive actions may also cause jumps as part of their predefined behavior. The occurrence of a jump terminates the current action and attempts to transfer control to a jump
handler associated with the current action. If the current action lacks a jump handler for the given jump type, the jump
propagates to the enclosing action.
Description
An action whose execution causes the occurrence of a specified jump. The execution of a jump action causes a transfer of control to the handler action matching the type of the generated jump value.
Attributes
None.
Associations
jumpValue: InputPin [1]
The jump value produced by the jump action. When the jump action is executed,
a jump occurs and the jump value becomes the jump object. The execution of the
jump action is terminated and the normal process of jump handling occurs using
the given jump object. The type of the jump object is the type that will be used to
find a matching jump handler.
1-211
11 Common::Actions
JumpHandler
Constraints
[1] The type, ordering, and multiplicity of the jump value input pin is derived from the corresponding source value
denotation.
Semantics
A jump action begins execution when its control and data flow prerequisites are satisfied. The value on its input pin is
copied and becomes the jump object, and the jump action terminates.
The current action, i.e., the action containing the jump action, is examined for a jump handler whose jump type is
the same as or an ancestor of the type of the generated jump object. If one is found, the body action of the jump handler is invoked (see JumpHandler). Otherwise the jump propagates to the enclosing action. Propagation of a jump
causes termination of the current action and the execution of the jump action. Actions executing concurrently to the
current action must complete before the jump is propagated.
Notation
None.
Examples
None.
Rationale
This action iserves to represent raise, break, and continue statements from conventional programming languages.
JumpHandler
A jump handler maps an action and a jump type to the handler action that is invoked if a jump generating a matching
jump object occurs during the execution of the protected action.
Description
A jump handler may be attached to any action. A jump handler maps a jump type (a signal) to a handler action. If a
jump occurs during the execution of an action and the type of the generated jump object (see JumpAction) or one of
its ancestor types is associated with a jump handler attached to the action as its jump type, then the execution of the
action terminates and execution continues with thecorresponding handler action. The jump object is made available at
the jump value pin of the handler action, thus allowing data to be passed from the jump action to the handler action.
When the execution of a handler action is completed, the execution of the protected action is complete. The values of
the output pins designated as handlerOutput are copied to the output pins of the protected action. A handler action is
ill formed if it can possibly complete normally but the number of output pins on the handler does not match the number of output pins of the protected action.
Attributes
None.
Associations
body: HandlerAction [1]
The action executed if a jump occurs during an execution of the protected action,
and the jump type is the same or an ancestor of the type of the jump object.
1-212
jumpType: Signal [1]
The specification of the jump object handled by the jump handler.
protectedAction: Action
The action whose executions are protected by the jump handler. The same handler can protect multiple actions.
Constraints
[1] The number of handlerOutput pins of the associated handler action and the number of the output pins of the protected action must be equal.
self.body.outputPin.count = self.jumpHandler.protectedAction.outputPin.count
Semantics
If a jump generating a jump object of the given jump type or a descendant type occurs during the execution of the
protected action or is propagated to it from a nested execution, control of execution transfers to the body handler
action. The outputs of the handler action serve as the outputs for the protected action.If a jump occurs during the execution of a handler action, its handler action (if any) is executed. If there is no jump handler, the jump propagates
upward. If the propagated jump reaches the original handler action without being handled, the original jump is propagated to the action containing the protected action. The jump value generated by the handler action is lost.
Notation
None.
Examples
None.
Rationale
Not applicable.
LinkAction
LinkAction is an abstract primitive action class for all link actions that identify their links by the objects at the ends of
the links and by the qualifiers at ends of the links.
Description
A link action creates, destroys, or reads links, identifying a link by its end objects and qualifier values, if any.
Attributes
None.
Associations
endData : LinkEndData [2..*] Data identifying one end of a link by the objects on its ends and qualifiers.
input : InputPin [1..*]
(Specialized from Action:input) Pins taking end objects and qualifier values as
input.
1-213
11 Common::Actions
LinkEndCreationData
Constraints
[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 not be static.
self.endData->forall(end.oclisKindOf(NavigableEnd) implies end.isStatic = #false)
[3] The input pins of the action are the same as the pins of the link end data and insertion pins.
self.inputPin->asSet() =
let ledpins : Set = self.endData->collect(value) in
if self.oclIsKindOf(LinkEndCreationData)
then ledpins->union(self.endData.oclAsType(LinkEndCreationData).insertAt)
else ledpins
Additional operations:
[1] association operates on LinkAction. It returns the association of the action.
association();
association = self.endData->asSequence().first().end.association
Semantics
For actions that write links, 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 have exactly one object at its ends.
The behavior is undefined for links of associations that are static on any end.
For the semantics of link actions see the children of LinkAction.
Notation
None.
Examples
None.
Rationale
LinkAction is introduced to abstract aspects of link actions that identify links by the objects on their ends.
LinkAction is new in UML 2.0.
LinkEndCreationData
LinkEndCreationData is not an action. It is part of the model that identifies links. It identifies one end of a link to be
created by CreateLinkAction.
Description
This class is required when using CreateLinkAction, to specify insertion points for ordered ends and for replacing all
links at end. See CreateLinkAction.
1-214
Attributes
isReplaceAll : Boolean [1..1] = falseSpecifies whether the existing links emanating from the object on this end
should be destroyed before creating a new link.
Associations
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.
Constraints
[1] LinkEndCreationData can only be end data for CreateLinkAction or one of its specializations.
self.LinkAction.oclIsKindOf(CreateLinkAction)
[2] Link end creation data for ordered association ends must have a single input pin for the insertion point with type
ValueSpecification and multiplicity of 1..1, otherwise the action has no input pin for the insertion point..
if self.end.ordering = #unordered
endif
Semantics
See CreateLinkAction.
Notation
None.
Examples
None.
Rationale
LinkEndCreationData is introduced to indicate which inputs are for which link end objects and qualifiers.
LinkEndCreationData is new in UML 2.0.
LinkEndData
LinkEndData is not an action. It is part of the model that identifies links. It identifies one end of a link to be read or
written by the children of LinkAction. See LinkAction.
Description
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.
1-215
11 Common::Actions
LoopAction
Attributes
None.
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.
Constraints
[1] The type of the end object input pin is the same as the type of the association end.
self.value.type = self.end.type
[2] The multiplicity of the end object input pin must be 1..1.
self.value.multiplicity.is(1,1)
Additional operations:
[1] association operates on LinkAction. It returns the association of the action.
association();
association = self.endData->asSequence().first().end.association
Semantics
See LinkAction and its children.
Notation
None.
Examples
None.
Rationale
LinkEndData is introduced to indicate which inputs are for which link end objects and qualifiers.
LinkEndData is new in UML 2.0.
LoopAction
The loop action provides for repeated execution of a set of subactions A loop action may contain a set of test actions
and a set of body actions. The body actions are those subactions that are not a test action and are executed repeatedly
as long as the test output yields true.
During each iteration, the test action, if present, is executed. If the designated test output yields false, then the
execution of the loop is complete. If the test output is true, the body actions of the loop action are executed.
The test action may not execute for the first time unless all predecessors of the loop action have completed. It
may not execute for a subsequent time unless the previous execution of the body actions are complete.
During execution of a loop action, the test actions and the body actions 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 iterations of the
loop.
1-216
The output pins of the body actions may not be directly connected to input pins outside the loop action. The output pins of test action may not be connected to input pins outside the loop action.
Description
A loop action may contain a test action and a set of body actions which are executed repeatedly as long as the test output yields true.
Associations
body: Action [0..*]
A set of actions that are executed during each iteration of the loop.
test : Action [0..*]
A set of actions whose Boolean result (designate by testOutput) must be true for
execution of the body action to proceed.
testOutput : ValueDenotation [1]

If this value denotation evaluates to true, the body actions may execute.
Attributes
isTestedFirst: Boolean
If true, the initial loop test is executed before the initial execution of the body
actions (in this case, the loop action represents a conventional while loop). If
false, the initial loop test is omitted (in this case, the loop action represents a conventional do loop, and the loop body is executed at least once).
Operations
[1] This operation returns all subactions of an action, nested to any depth.
allSubactions() : Set(Action)
allSubactions() = self.subactions()>union(self.subactions().allSubactions())
Constraints
[1] 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).
[2] 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)
[3] None of the actions within the test action (if any) may have control-flow connections with actions outside the test
action.
self.test.allSubactions()->forAll(action : Action |
action.predecessor->union(action.successor)->forAll(a : Action | a.isSubaction(self.test))
[4] None of the actions within the body actions (if any) may have control-flow connections with actions outside the
body actions.
[5] The test action may not participate in control flows.
self.test.predecessor>isEmpty() and self.test.successor>isEmpty()
[6] If the test output is an output pin, it must belong to the test action.
Semantics
A loop action may have control-flow prerequisites. Once these prerequisites have been satisfied, the execution of the
loop begins. If isTestedFirst is true, the test action is executed, if present. If the test output is true, then the body
actions are executed, and the test action is executed again. If isTestedFirst is false, the body actions are executed
immediately, and the test action is executed. This continues until the test output yields false, whereupon the loop is
complete.
1-217
11 Common::Actions
Multiplicity (extended)
[1] When all control flow and data flow prerequisites of a loop action are satisfied, the execution of the loop begins.
[2] If isTestedFirst is true, the test subactions are executed.
[3] If isTestedFirst is false, its body subactions are executed. When the body action has completed execution, the test
subaction is executed.
[4] When the test subaction has completed execution or if there was no test subaction, if the test output yields a false
value, the loop execution is complete and the control flow prerequisite is satisfied for any successor actions.
[5] When the test subaction has completed execution or if there was no test subaction, if the test action yields a true
value, the body subactions are executed.
[6] When the body subactions have completed execution, the test subaction is executed again, and execution of the
loop action continues at step [4].
Notation
None.
Examples
None.
Rationale
Not applicable.
Multiplicity (extended)
Operations
[1] 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.includesCardinality(i) implies other.includesCardinality(i))
[2] The operation is determines if the upper and lower bound of the ranges are the ones given.
is(lowerbound : integer, upperbound : integer) : Boolean
is(lowerbound, upperbound) = (lowerbound = self.lowerbound and upperbound = self.upperbound)
PrimitiveFunction
Description
A PrimitiveFunction is the signature of a function that produces output values from input values. The behavior is
described using the body and language attributes. The specification of the detailed behavior is expressed in an external language and is not further specified within UML.
Attributes
body: String
A textual representation of the function in the named surface language.
1-218
Specifies the language in which the body of the primitive function is stated. The
interpretation of the body depends on the language. If the language is unspecified, it might be implicit from the body or the context.
Associations
None.
Constraints
None.
Semantics
The interpretation of the function body depends on the specified language. If formal parameters are specified, these
provide values to the function during its execution. The result parameters specify the values to be returned by the
function.
The execution of a primitive function has no effect on the execution environment other than the production of
output values that depend only on the supplied input values.
Notation
None.
Examples
None.
Rationale
PrimitiveFunction models external functions that only take inputs and product outputs and have no effect on the specified system.
This metaclass was not present in 1.x.
Operations
[1] 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
1-219
11 Common::Actions
ReadAttributeAction
endif
Semantics
If a jump is propagated from an immediate subaction of a procedure, execution of the procedure is terminated once
any concurrent action executions are complete. If the procedure was invoked synchronously, a reply transmission representing the jump object is returned to the caller of the procedure. When the caller execution receives the reply transmission, the jump is reraised in the context of the calling action, where it may be handled or may propagate further
within the execution scope of the caller.
If the invocation was asynchronous, no reply transmission is made and no further propagation occurs.
ReadAttributeAction
ReadAttributeAction is an attribute action that retreives the values of an attribute.
Description
This action reads the values of an attribute, in order if the attribute is ordered.
Attributes
None.
Associations
result: OutputPin [1..1]
Constraints
[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)
Semantics
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.
Notation
None.
Examples
None.
Rationale
ReadAttributeAction is introduced to retrieve the values of an attribute.
1-220

ReadAttributeAction is new in UML 2.0.
ReadLinkAction
ReadLinkAction is a link action tha navigates across associations to retreive objects on one end.
Description
This action navigates an association towards one end, which is the end 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 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.
Attributes
None.
Associations
result : OutputPin [0..*]
(Specialized from Action:output) The pin on which are put the objects participating in the association at the end not specified by the inputs.
Constraints
[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.
openend.multiplicity.compatibleWith(self.result.multiplicity)
[4] The open end must be navigable.

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
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))))
Semantics
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.
1-221
11 Common::Actions
ReadSelfAction
Figure 11-6 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.
Notation
None.
Examples
None.
Rationale
ReadLinkAction is introduced to navigate across links.
ReadLinkAction is new in UML 2.0.
ReadSelfAction
ReadSelfAction retrieves the host object of an action.
Description
Every action is ultimately a part of some procedure, which is in turn is optionally attached in some way to the specification of a classifierfor 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. This action produces this host instance,
if any, on its output pin. The type of the output pin is the classifier to which the procedure is statically associated.
Attributes
None.
Associations
(Specialized from Action:output) Gives the output pin on which the hosting
object is placed.
Constraints
[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 not be static.
let hostelement : Element = self.procedure().hostElement() in
not hostelement.oclIsKindOf(Method)
or hostelement.oclAsType(Method).specification.isStatic = #false
[3] The type of the result output pin is the host classifier.
self.result.type = self.procedure().hostClassifier()
1-222
[4] The multiplicity of the result output pin is 1..1.

Semantics
The semantics is undefined for procedures that have no context object.
Notation
None.
Examples
None.
Rationale
ReadSelfAction is introduced to provide access to the context object when it is not available as a parameter.
ReadSelfAction is new in UML 2.0.
ReadVariableAction
ReadVariableAction is a variable action that retreives the values of an variable.
Description
This action reads the values of a variables, in order if the variable is ordered.
Attributes
None.
Associations
Constraints
[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)
Semantics
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.
1-223
11 Common::Actions
RemoveAttributeValueAction
Notation
None.
Examples
None.
Rationale
ReadVariableAction is introduced to retrieve the values of a variables.
ReadVariableAction is new in UML 2.0.
RemoveAttributeValueAction
RemoveAttributeValueAction is a write variable attribute action that removes values from attributes.
Description
1..1.
Attributes
None.
Associations
None.
Constraints
None.
Semantics
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 readOnly after initialization of the owning object.
Notation
None.
Examples
None.
Rationale
RemoveAttributeValueAction is introduced to remove attribute values.
1-224

RemoveAttributeValueAction is new in UML 2.0.
RemoveVariableValueAction
RemoveAttributeValueAction is a write variable attribute action that removes values from variables.
Description
Attributes
None.
Associations
None.
Constraints
None.
Semantics
Variables 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.
Notation
None.
Examples
None.
Rationale
RemoveVariableValueAction is introduced to remove variable values.
RemoveVariableValueAction is new in UML 2.0.
StateVertex (extended)
Operations
[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
1-225
11 Common::Actions
TestIdentityAction
TestIdentityAction
Tests if two values are identical objects.
Description
This action returns true if the two input values are the same identity, false if they are not.
Attributes
None.
Associations
first: InputPin [1..1].
(Specialized from Action:input) Gives the pin on which an object is placed.
(Specialized from Action:output) Tells whether the two input objects are identical.
second: InputPin [1..1]
(Specialized from Action:input) Gives the pin on which an object is placed.
Constraints
[1] The input pins have no type.
self.first.type->size() = 0
and self.second.type->size() = 0
[2] The multiplicity of the input pins is 1..1.

self.first.multiplicity.is(1,1)
and self.second.multiplicity.is(1,1)
Semantics
When all 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 (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.
Notation
None.
Examples
None.
Rationale
TestIdentityAction is introduced to tell when two values refer to the same object.
TestIdentityAction is new in UML 2.0.
1-226
Variable
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 action 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 individual
actions, they must be sequenced by control flows, let race conditions may occur between actions to read or write the
same variable.
Description
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 effecting actions, similar to the actions to
write and read object attributes and associations. There are no sequencing constraints among actions that access the
same variable. Such actions must be explicitly coordinated by control flows or other constraints.
Any values contained by a variable must conform to the type of the variable and have cardinalities allowed by
the multiplicity of the variable.
Associations
None.
Attributes
scope : GroupAction [1]
The group action that owns the variable.
Constraints
None.
Semantics
A variable specifies a slot able to hold a value or a sequence of values, consistent with the multiplicity of the variable.
The values held in this slot may be accessed from any action contained directly or indirectly within the group action
that is the scope of the variable.
Notation
None.
Examples
None.
Rationale
Not applicable.
1-227
11 Common::Actions
VariableAction
VariableAction
Description
A variable action operates on a statically specified variable.
Attributes
None.
Associations
variable : Variable [1..1]
Variable to be read.
Constraints
[1] The action must be in the scope of the variable.
self.variable.isAccessibleBy(self)
Semantics
Variable action is an abstract metaclass. For semantics see its concrete subtypes.
Notation
None.
Examples
None.
Rationale
VariableAction is introduced for the abstract aspects of variable actions.
VariableAction is new in UML 2.0.
WriteAttributeAction
WriteAttributeAction is an abstract class for attribute actions that change attribute values.
Description
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.
Attributes
None.
Associations
(Specialized from Action:input) Value to be added or removed from the attribute.
Constraints
[1] The type input pin is the same as the classifier of the attribute.
1-228
self.value.type = self.attribute.featuringClassifier

Semantics
None.
Notation
None.
Examples
None.
Rationale
WriteAttributeAction is introduced to abstract aspects of attribute actions that change attribute values.
WriteAttributeAction is new in UML 2.0.
WriteLinkAction
WriteLinkAction is an abstract class for link actions that create and destroy links.
Description
A write link action takes a complete identification of a link and creates or destroys it.
Attributes
None.
Associations
None.
Constraints
[1] All end data must have exactly one input object pin.
self.endData.forall(value->size() = 1)
Semantics
See children of WriteLinkAction.
Notation
None.
Examples
None.
1-229
11 Common::Actions
WriteVariableAction
Rationale
WriteLinkAction is introduced to navigate across links.
WriteLinkAction is new in UML 2.0.
WriteVariableAction
WriteVariableAction is an abstract class for variable actions that change variable values.
Description
A write variable action operates on a variable 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 variable actions are inherited from VariableAction.
Attributes
None.
Associations
(Specialized from Action:input) Value to be added or removed from the variable.
Constraints
[1] The type input pin is the same as the type of the variable.
self.value.type = self.variable.type

Semantics
See children of WriteVariableAction.
Notation
None.
Examples
None.
Rationale
WriteVariableAction is introduced to abstract aspects of attribute actions that change variable values.
WriteVariableAction is new in UML 2.0.
1-230
12 Common::Activities
Chapter 12. Common::Activities

Activity modeling emphasizes the sequence and conditions for coordinating lower-level behaviors, rather than which
classifiers own those behaviors. These are commonly called control flow and object flow models. The behaviors
coordinated by activity models can be initiated because other behaviors finish executing, because objects and data
become available, or because events occur external to the flow. See the Activity metaclass for more introduction
and semantic framework..
Common
Behaviors
(from Common)
Kernel
(from Foundations)
Activities
Figure 12-1. Dependencies of the Common::Activities package
This chapter covers intermediate activity functionality. See Chapter 21, Complete::Activities for complete functionaliy.
Activities.fm Version 2 beta R1
231
Behavior
<<enumerat ion >>

Act ivityK ind
structured
flowChart
+activity
[behavior]
Behavior
Class
(from Kernel )
1 isReentrant : Boolean [1] = true
Activity
kind : ActivityKind [*]
isSingleCopy : Boolean [1] = false
+activity
[ owner]
+node
[ownedElement]
ActivityNode
InvocationNode
ControlNo de
Ob jectNode
Figure 12-2. Decompositions

+activity
[owner]
Activity
+node
+edge
[ ownedElement]
[ownedElement]
*
ActivityNode
+activity
[owner]
+source
1
+outgoing
*
*
ActivityEdge
*
+incoming
+target
0..1
1
ControlFlow
ObjectFlow
+guard
ValueSpecification
(from Kernel)
{ default is t rue }
Figure 12-3. Flows
232
TypedElement
(from Kernel)
TypedElement
isSet : Boolean [1] = false
ObjectNode
BehaviorI nvocat ion
Pin
(from CommonBehavi or)
(from Kernel)
ParameterUsageNode
[argument]
Parameter
SignalNode
CentralBufferNode
ActivityParameter
[parameter]
[result]
[type]
InvocationNode
Act ivity
Signal
(from Com m onBehavi or)
Figure 12-4. Object Nodes
ActivityNode
ControlNode
InitialNode
FinalNode
ForkNode
DecisionNode
*
+decisionInput
ActivityFinalNode
FlowFinalNode
JoinNode
0..1
Behavior
MergeNode
Figure 12-5. Controls
233
Element
(from Kernel)
+activity
[ownedElement]
+subgroup
Act ivity
1
[ ownedEl ement]
0..1
0..* +gro up
[owner]
0..*
Act ivit yG roup
+group
[ owner]
*
+group
*
+group
0..*
ActivityEdge
0..*
+edgeContents
ActivityNode
+nodeContents
Figure 12-6. Groups
ActivityGroup
NamedEl emen t
(from Kernel)
+subpartition
[ act ivit y]
Activity
1
+partition
[subgroup]
[group]
ActivityPartition
*
+represents
Element
isDimension : Boolean
(from Kernel)
0..1
+partition isExternal : Boolean
[ group]
*
*
+part it ion +partition
[ group]
[group]
0.. 1
ActivityEdge
*
[edgeContents]
ActivityNode
[nodeContents]
Figure 12-7. Partitions

Figure 12-8. Interruptible regions
234
Act ivit yG roup

ActivityNode
0..1
[group]
[ nodeContents]
St ructuredAc tivityGroup
[group]
0..1
<<enumeration>>
IterationActivityGroupKind
[ edgeContent s]
testAtBegin
testAtEnd
ActivityEdge
IterationActivityGroup
kind : IterationAct ivit yGroupKind [1..1] = testAt Begin
+test
ValueSpecification
(from Kernel)
1
0.. 1
Figure 12-9. Structured groups
Signal
(from Com m onBehavior)
TimeSignal
ChangeSignal
0..1
0..1
+timeSpec
+changeSpec
ValueSpecification
1
ValueSpecification
(f rom Kern el)
(from Kernel )
Figure 12-10. Signals
235
Activity
[order
rejected]
Fill
Order
Receive
Order
Ship
Order
Close
Order
[order
accepted]
Send
Invoice
Make
Payment
Accept
Payment
Invoice
Figure 12-11. An example activity diagram
Activity
Activities are a kind of behavior that specifies the sequence and conditions for the invocation of other behaviors.
Description
An activity specifies the coordination of invocations of lower-level behaviors, using a control and data flow model.
The specific behaviors coordinated by these models may be initiated because other behaviors in the model finish executing, because objects and data become available, or because events occur external to the flow. The flow is modeled
as activity nodes connected by activity edges. A node can be the invocation of a lower-level behavior, which may be
a call to an operation, for example, or another activity. That is, activities may form invocation hierarchies that have
embedded activities, ultimately resolving to primitive actions.
Activities may contain:
invocations of any sort of behavior, including activities.
object flows for objects and data input and output from invoked behaviors.
control flows for coordinating the end of one invocation and the beginning of anther.
control nodes to guide control and object flow. These are forks, joins, decisions, and merges to model decisions
and concurrent processes. These also include initial and final nodes for starting and ending flows.
object nodes to handle objects and data as they flow in and out of invoked behaviors, or to collect toeksn as they
wait to move downstream.
partitions to organize lower-level activities according to various criteria, such as the real-world organization
responsible for their performance.
See complete functionality at Activity in Complete::Activities.
Activities may be applied to organizational modeling for business process engineering and workflow. 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. Activities can also be used for information system modeling to specify system level processes.
236
Activity
Attributes
isSingleCopy : Boolean[1..1] = falseTells whether tokens interact between separate invocations of the activity.
kind : ActivityKind [0..*]
Indicates overall constraints that apply to the nodes and edges of the activity.
Associations
edge : ActivityEdge [0..*]
Edges expressing flow between nodes of the activity.
node : ActivityNode [0..*]
Nodes coordinated by the activity.
group : ActivityGroup [0..*]
Groups in the activity.
[parameter] : ActivityParameter [0..*]The parameters of the activity. Specialized from Behavior:parameter.
partition : ActivityPartition [0..*]Partitions in the activity.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] The parameters of an activity are all the activity parameter object nodes contained by the activity.
[2] Activities that are methods for behavioral features must have parameters compatible with the parameters of the
behavioral feature.
[3] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.
Semantics
The semantics of activities is based on token flow. The term token refers to a single object, datum, or control that is
flowing through the activity along the edges and through the nodes. See the end of this section for more about how
tokens are managed. Activities can have multiple tokens flowing in them at any one time, if required. Special nodes
called object nodes provide and accept objects and data as they flow in and out of invoked behaviors, and may act as
buffers, collecting tokens as they wait to move downstream. Each invocation of an activity can also be treated separately, if desired, by sending the tokens of each invocation through separate copies of the activity. In this case the
tokens introduced by multiple invocations have no effect on each other, and there is less likelihood of bottlenecks in
the flow.
Each time an activity is invoked, the isSingleCopy attribute indicates whether the same copy of the activity handles
tokens for all invocations, or a separate copy of the activity is created for each invocation. For example, an activity
that models a manufacturing plant might have a parameter for an order to fill. Each time the activity is invoked, a new
order enters the flow. Since there is only one plant, there is only one copy of the activity handling all orders. If a single copy of the activity is used for all invocations, the modeler must consider the interactions between the multiple
streams of tokens moving through the nodes and edges. Tokens may reach bottlenecks waiting for other tokens ahead
of them to move downstream, they may overtake each other due to variations in the execution time of invoked behaviors, and most importantly, may abort each other with constructs such as activity final.
If a separate copy of the activity is used for each invocation, tokens from the various invocations do not interact. For
example, an activity with a context classifier, but that is not a method, is invoked when the classifier is instantiated,
and the modeler will usually want a separate copy of the activity for each instance of the classifier. A new activity
copy for each invocation reduces token interaction, but might not eliminate it. For example, an activity may have a
loop creating tokens to be handled by the rest of the activity, or an unsynchronized flow that is aborted by an activity
237
Activity
final. In these cases, modelers must consider the same token interaction issues as using a single activity copy for all
invocations. Also see the isReentrant attribute of Behavior (in Activities).
Activities can be parameterized, which is a capability inherited from Behavior. The parameters of an activity are a
subset of the object nodes contained in the activity, specifically the activity parameter object nodes. See ActivityParameter. Functionality inherited from Behavior also supports the use of activities on classifiers and as methods for
behavioral features. The classifier, if any, is referred to as the context of the activity. At runtime, the activity has
access to the attributes and operations of its context object and any objects linked to the context object, transitively.
An activity that is also a method of a behavioral feature has access to the parameters of the behavioral feature. In
workflow terminology, the scope of information an activity uses is called the process-relevant data. Implementations
that have access to metadata can define parameters that accept entire activities or other parts of the user model.
An activity with a a classifier context, but that is not a method of a behavioral feature, is invoked when the classifier
is instantiated. An activity that is a method of a behavioral feature is invoked when the behavioral feature is invoked.
The Behavior metaclass also provides parameters, which must be compatible with the behavioral feature it is a
method of, if any. If a classifier is the context of an activity, without a behavioral feature, then the parameters are
effectively the parameters of a classifier constructor. Behavior also supports overriding of activities used as inherited
methods. See the Behavior metaclass for more information.
Activities can also be invoked by other activities directly rather than calling a behavioral feature that has an activity
as a method. This functional or monomorphic style of invocation is useful at the stage of development where focus is
on the activities to be completed and goals to be achieved. Classifiers responsible for each activity can be assigned at
a later stage by declaring behavioral features on classifiers and assigning activities as methods for these features. For
example, in business reengineering, an activity flow can be optimized independently of which departments or positions are later assigned to handle each step. This is why activities are autonomous when they are not assigned to a
classifier. See the UML behavior tutorial for more information on this, www.omg.org/cgi-bin/doc?omg/2001-03-03,
slides 121 and after, and www.kabira.com/bock/goal.html and goal2.html.
Regardless of whether an activity is invoked through a behavioral feature or directly, inputs to the invoked activity
are taken from an invocation node in the calling activity, which gets inputs from incoming edges. Likewise an activity
invoked from another activity produces outputs to an invocation node, which passes them along outgoing edges.
Activities can accept signal inputs and produce signal outputs that are not parameters. See semantics of SignalNode.
An activity can be used to model runtime executions that the activity specifies. Activities are classes and each
instance represents an execution of the activity. It can support operations for managing execution, such as starting,
stopping, aborting, and so on, attributes such as how long the process has been executing or how much it costs, and
links to objects such as the performer of the execution, who to report completion to, or resources being used, and
states of execution such as started, suspended, and so on. Used this way activity is the modeling basis for the WfProcess interface in the OMG Workflow Management Facility, www.omg.org/cgi-bin/doc?formal/00-05-02. It is
expected that profiles will include class libraries with standard classes that are used as root classes for activities in the
user model. Vendors may define their own libraries, or support user-defined features on activity classes.
The kind attribute of activity indicates constraints that apply to the nodes and edges of the activity as an overall
graph. The value structured requires forks and joins, decisions and merges, to be matched in a way that the subsections of the activity are well-nested. This is to facilitate compilation of activities into structured languages. The
value flowChart requires that the activity does not use forks, joins, object nodes, object flow edges, or interrupting
regions. It is for modeling traditional flow charts. An activity can be of more than one kind at the same time.
Nodes and edges have token management rules. Nodes control when tokens enter or leave them. Edges have rules
about when a token may be taken from the source node and moved to the target node. A token traverses an edge
when it satisfies the rules for target node, edge, and source node all at once. The rules at a target node obviously cannot be applied until it is known which tokens are under consideration to traverse the edge. This means the rules for
the edge must be applied first to determine the candidate tokens, which then must pass the rules at the target node
before traversing the edge. The edge rules likewise cannot be applied until it is known which tokens are allowed to
leave the source node. So the source rules must be applied first to nominate possible candidates for the edges. Since
a source node may also be a target for an upstream edge, the process recurs, bottoming out at nodes that have no
238
Activity
incoming edges. When a token passes all the tests, it is elected and taken from the source node it which it resided and
placed on the target node for which it was approved.
It may be that a particular token going through the above process satisfies the source and edge rules, but not the target
rules. The token remains at the source node at the same time it is a candidate for traversing an edge. Since the source
node rules nominate tokens for all outgoing edges to consider, there may be other edges from the source node applying their own rules to the nominated tokens. Rules for one of these other edges and its target node may be satisfied
first, and take an elected token that is being actively considered by other edges. In this case, the token will not be
available to the other edges, even if they decide to approve it for traversal. This underscores that token flow semantics
is highly distributed and subject to timing issues and race conditions, as is any distributed system. There is no specification of the order in which rules are applied on the various nodes and edges in an activity, except as required for the
election process above. It is the responsiblity of the modeler to ensure that timing issues do not affect system goals,
or that they are eliminated from the model.
Some nodes require incoming tokens to be immediately passed along outgoing edges. These are called the control
nodes. Their rules include the additional restriction that a token coming in must satisfy the rules of an outgoing edge
and its target, so that the token can be passed through. Tokens cannot rest at control nodes, waiting to moving
downstream. Control nodes act as traffic switches managing tokens as they make their way between object nodes and
invocations, which are the nodes where tokens can rest. The outgoing edge of a control node may target another control node, whereupon the rule recurs. For convenience, initial nodes are excepted from this rule.
A data token with no value in is called the null token. It can be passed along and used like any other token. For example, an invocation node can output a null token and a downstream decision point can test for it and branch accordingly. Null tokens satisfy the type of all object nodes.
The semantics of activities is specified in terms of these token rules, but only for the purpose of describing the
expected runtime behavior. Token semantics is not intended to dictate the way activities are implemented, despite the
use of the term invocation. They only define the sequence and conditions for behaviors to start and stop. Token
rules may be optimized in particular cases as long as the effect is the same. Start at ActivityEdge and ActivityNode to
see the token management rules.
See ActivityNode and ActivityEdge for more information on the way activities function. An activity with no
nodes and edges is well-formed, but unspecified. It may be used an alternative to the generic Behavior metaclass in
activity modeling. See ActivityPartition for more information on grouping mechanisms in activities.
None.
Notation
The notation for an activity is a combination of the notations of the nodes and edges it contains, plus a border and
name displayed in the upper left corner. Object nodes that are parameters of the activity are displayed on the border.
Invocation nodes that are contained by the activity are also depicted. Pre and postcondition constraints, inherited from
Behavior, are shown as with the keywords precondition and postcondition, respectively. See Figure 12-12 and
Behavior (in Activities). The kind of activity is also shown with keywords, structured and flowChart. The key-
239
Activity
word singleCopy is used for activities that execute is a single copy. Otherwise, each invocation executes in its own
copy. See the notation sections of the various kinds of nodes and edges for more information.
Activity name
Parameter name: type
precondition constraint
postcondition constraint
...
...
...
Figure 12-12. Activity notation.

The notation for classes can be used for diagramming the features of an activity as shown below, with the keyword
activity to indicate it is an activity class. Association and state machine notation can also be used as necessary.
activity
Activity Name
attribute : type
attribute : type
operation (parameters)
operation (parameters)
Figure 12-13. Activity class notation.

Presentation Option
The invocation of activities may also be shown in a tree format, such as a tree control typically found in graphical
user interfaces. Each branch in the tree shows the name of an activity and under that a list of the behaviors invoked by
that activity. These may be other activities that likewise have branches. The tree continues down to the leaves where
other behaviors are shown, or activities without nodes or edges. A possible tree display for the example in Figure 1216 is shown below. If leaf behaviors invoke operations or send signals that cause the invocation of other activities,
this branching can also be shown. However, in this case polymorphic operations and the reaction that objects have to
signals through their state machines may make it difficult to statically determine which other activities will be
invoked. A static model analyzer can at least determine some of the possible activities that could be invoked when an
240
Activity
operation is invoked or a signal sent. A tree presentation can use the output of the analyzer to display the possible
invocations.
Design Airplane
ID Part Requirement
Standard Part Search
Use Part
Provide Required Part
Figure 12-14. Example of tree presentation option for activities.

Style Guidelines
Examples
The definition of Process Order below uses the border notation to indicate that it is an activity. It has pre and post conditions on the order (see Behavior). It is structured, but not a flow chart, because it uses forks. All invocations of it
use the same copy.
Process Order
Requested Order: Order
precondition Order complete

postcondition Order closed
structured
singleCopy
[order
rejected]
Requested
Order
Fill
Order
Receive
Order
Ship
Order
Close
Order
[order
accepted]
Send
Invoice
Make
Payment
Accept
Payment
Invoice
Figure 12-15. Example of an activity with input parameter.

The diagram below is based on a standard part selection workflow within an airline design process in section 6.1.1.2
of the Workflow Process Definition RFP, bom/2000-12-11. Notice that the Standards Engineer insures that the substeps in Provide Required Part are performed in the order specified and under the conditions specified, but doesnt
necessarily perform the steps themselves. Some of them are performed by the Design Engineer even though the Standards Engineer is managing the process. The Expert Part Search behavior can result in a part found or not. When a
part is not found, it is assigned to the Assign Standards Engineer activity. Lastly, Specify Part Mod Workflow invocation produces entire activities and they are passed to subsequent invocations for scheduling and execution (i.e. Sched-
241
Activity
ule Pat Mod Workflow, Execute Part Mod Workflow, and Research Production Possibility). In other words, behaviors
can produce tokens that are activities that can in turn be executed; in short, runtime activity generation and execution.
Design Part
ID Part
Requirement
Design
Engineer
[part provided]
Provide
Required
Part
[else]
Design
Engineer
Standards
Engineer
Clarify
Requirements
[part
found]
[part not
found]
Use
Part
[part not
found]
Standards
Engineer
Expert
Part
Search
[part
found]
Standard
Part Search
[stream]
Assign
Standards
Engineer
[stream]
Specify
Part Mod
Workflow
Review
Requirements
Schedule
Part Mod
Workflow
Review
Schedule
[cancel]
[reschedule]
[OK]
[stream]
[stream]
Provide
addtl part
mod info
Execute
Part Mod
Workflow
[accept]
Research
Production
Possibility
[reject]
Figure 12-16. Workflow based on example from the Workflow Process Definition RFP
242
Activity
The diagram below is based on a trouble-ticket activity defined in section 6.1.1.3 of the Workflow Process Definition
RFP, bom/2000-12-11.
Trouble Ticket
[problem statement rectified]
[cannot
reproduce
problem]
[recorded]
Record
Problem
Correct
Problem
Reproduce
Problem
[else]
[not recorded]
[can
reproduce
problem]
[duplication
of another
problem]
[known
problem
and solution]
Communicate
ID Problem
and
Resolution
Verify
Resolution
Results
[else]
Audit and
Record
[problem not solved]
Figure 12-17. Workflow based on example from the Workflow Process Definition RFP.
Below is an example of using class notation to show the class features of an activity. Associations and state machines
can also be shown.
activity
Fill Order
costSoFar : USD
timeToComplete : Integer
suspend ()
resume ()
Figure 12-18. Activity class with attributes and operations.

Rationale
Activities are introduced to flow models that coordinate other behaviors, including other flow models. It supports
class features to model control and monitoring of executing processes, and relating them to other objects, for example
in an organization model.
Activity replaces ActivityGraph in UML 1.4. Activities are redesigned to use a Petri-like semantics instead of state
machines. Among other benefits, this widens the number of flows that can be modeled, especially those that have parallel flows.
243
ActivityEdge
ActivityEdge
An activity edge is a directed connection between two activity nodes.
Description
ActivityEdge is an abstract class for the connections along which tokens flow between activity nodes. It covers control and data flow edges.
Attributes
guard : ValueSpecification [1..1] = trueSpecification evaluated at runtime to determine if the edge can be traversed.
Associations
activity : Activity[1..1]
Activity containing the edge.
group : ActivityGroup[0..*]
Groups containing the edge. Mulitplicity specialized to [0..1] for StructuredActivityGroup.
partition : Partition [0..*]
Partitions containing the edge.
source ActivityNode [1..1]
Node from which tokens are taken when they traverse the edge.
target : ActivityNode [1..1]
Node to which tokens are put when they traverse the edge.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] The guard specification is true for edges outgoing from forks.
[2] The source and target of an edge must be in the same activity as the edge.
Semantics
Activity edges are directed connections, that is, they have a source and a target, along which tokens may flow. The
guard specification must evaluate to true for every token that passes along the edge at the time it leaves the source.
Guards do not apply to edges outgoing from forks, that is, the guard is always true. Use a flow final node instead.
Tokens in the intermediate version of activities can only pass along the edge individually at different times. The guard
must evaluate to true for each token. See additional functionality for guards at DecisionNode.
Other rules for when tokens may be passed along the edge depend the kind of edge and characteristics of its source
and target. See the children of ActivityEdge and ActivityNode. The rules may be optimized to a different algorithm as
long as the effect is the same.
See variations at children of ActivityEdge and ActivityNode.
244
ActivityEdge
Notation
An activity edge is notated by a stick-arrowhead line connecting two activity nodes. If the edge has a name it is
notated near the arrowhead.
name
Activity edge with name
Regular activity edge
Figure 12-19. Activity edge notation.

An activity edge can also be notated using a connector, which is a small circle with the name of the edge in it. The circles and lines involved map to a single activity edge in the model. Every connector with a given label must be paired
with exactly one other with the same label on the same activity diagram. One connector must have exactly one
incoming edge and the other exactly one outgoing edge, each with the same type of flow, object or control. This
assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to
model elements.
(where, n is connector name)
Figure 12-20. Activity edge connector notation.

Presentation Option
Style Guidelines
Examples
In the example illustrated below, the arrowed line connecting Fill Order to Ship Order is a control flow edge. This
means that when the Fill Order behavior is completed, control is passed to the Ship Order. Below it, the same control
flow is shown with an edge name. The one below that employs connectors, instead of a continuous line. On the upper
245
ActivityEdge
right, the arrowed lines starting from Send Invoice and ending at Make Payment (via the Invoice object node) are
object flow edges. This indicates that the flow of Invoice objects goes from Send Invoice to Make Payment.
Fill
Order
Ship
Order
Send
Invoice
Filled
Fill
Order
Fill
Order
Ship
Order
Invoice
Ship
Order
Make
Payment
Fill
Order
is equivalent to
Ship
Order
Figure 12-21. Activity edge examples.

In the example below, a connector is used to avoid drawing a long edge around one tine of a fork. If a problem is not
priority one, the token going to the connector is sent to the merge instead of the one that would arrive from Revise
Plan for priority one problems. This is equivalent to the activity shown in Figure 12-23, which is how Figure 12-22 is
stored in the model.
A
A
[else]
[priority=1]
Evaluate
Impact
Revise
Plan
Register
Problem
Release
Fix
Fix
Problem
Test
Fix
Figure 12-22. Connector example.
246
ActivityFinal
[else]
[priority=1]
Evaluate
Impact
Revise
Plan
Register
Problem
Release
Fix
Fix
Problem
Test
Fix
Figure 12-23. Equivalent model to Figure 12-22.

Rationale
Activity edges are introduced to provide a general class for connections between activity nodes.
ActivityEdge replaces the use of (state) Transition in UML 1.4 activity modeling.
ActivityFinal
An activity final node is final node that stops all flows in an activity.
Description
An activity may have more than one activity final node. The first one reached stops all flows in the activity.
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
None.
Semantics
A token reaching an activity final node aborts all flows in the containing activity, that is the activity is terminated,
and the token is destroyed. All candidate tokens on the incoming edges are accepted. Any object nodes declared as
247
ActivityFinal
outputs are passed out of the containing activity. If there is more than one final node in an activity, the first one
reached terminates the activity, including the flow going towards the other activity final.
If it is not desired to abort all flows in the activity, use flow final instead. For example, if the same copy of an activity
is being used for all its invocations, then multiple streams of tokens will be flowing through the same activity. In this
case, it is probably not desired to abort all tokens just because one reaches an activity final. Using a flow final will
simply consume the tokens reaching it without aborting other flows. Or arrange for separate invocations of the activity to use separate copies of the activity, so tokens from separate invocations will not affect each other.
None.
Notation
Activity final nodes are notated as a solid circle with a hollow circle, as indicated in the figure below. It can be
thought of as a goal notated as bulls eye, or target.
Figure 12-24. Activity final notation.

Presentation Option
Style Guidelines
Examples
The first example below depicts that when the Close Order behavior is completed, all tokens in the activity are terminated. This is indicated by passing control to an activity final node.
Close
Order
Figure 12-25. Activity final example.
The next figure is based on an example for an employee expense reimbursement process in section 6.1.1.1 of the
Workflow Process Definition RFP, bom/2000-12-11. It uses an activity diagram that illustrates two parallel flows rac-
248
ActivityFinal
ing to complete. The first one to reach the activity final aborts the others. The two flows appear in the same activity so
they can share data, for example who to notify in the case of no action.
[decision = reject]
Reject
[amount >= 200]
Notify
Reject
Submit for
Approval
[decision = accept]
[amount < 200]
Service
Approval
Auto
Approve
No action
timer
Notify
No Action
Cancel
Transaction
Cancel
Service
Figure 12-26. Activity final example based on example from the Workflow Process Definition RFP.
The last figure is based on the second example in section 6.1.1.4 of the Workflow Process Definition RFP, bom/200012-11. Here, two ways to reach an activity final exist; but it is result of exclusive or branching, not a race situation like the previous example. This example uses two activity final nodes, which has the same semantics as using
one with two edges targeting it. The Notify of Modification behavior must not take long or the activity finals might
kill it.
Notify of
Modification
[decision = modify]
Modify
Proposal
Review
Proposal
Publish
Proposal
[decision = accept]
[decision = reject]
Notify of
Rejection
Figure 12-27. Activity final example based on an example from the Workflow Process Definition RFP.
Rationale
Activity final nodes are introduced to model non-local termination of all flows in an activity.
ActivityFinal is new in UML 2.0.
249
ActivityGroup
ActivityGroup
An activity group defines sets of activity nodes and edges in an activity.
Description
Activity groups are a generic grouping construct for nodes and edges. Nodes and edges can belong to more than
group.
Attributes
None
Associations
activity : Activity [1..1]
Activity containing the group.
edgeContents : ActivityEdge [0..*]
Edges immediately contained in the group.
nodeContents : ActivityNode [0..*]
Nodes immediately contained in the group.
group : ActivityGroup [0..1]
Group immediately containing the group.
subgroup : ActivityGroup [0..*]
Groups immediately contained in the group.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] All nodes and edges of the group must be in the same activity as the partition.
[2] No node or edge in a group may be contained by its subgroups or its containing groups, transitively.
Semantics
See children of ActivityGroup.
None.
Notation
Presentation Option
Style Guidelines
Examples
250
ActivityNode
Rationale
Activity groups provide a generic grouping mechanism that can be used for various purposes, as defined in the children of ActivityGroup, and in extensions and profiles.
ActivityGroups are new in UML 2.0.
ActivityNode
An activity node is a point in the flow of an activity connected by activity edges.
Description
An activity node is an abstract class for the steps of an activity. It covers invocation nodes, control nodes, and object
nodes.
Attributes
None.
Associations
activity : Activity[1..1]
Activity containing the node.
incoming : ActivityEdge [0..*] Edges that have the node as target.
outgoing ActivityEdge [0..*]
Edges that have the node as source.
group : Group [0..*]
Groups containing the node. Mulitplicity specialized to [0..1] for StructuredActivityGroup.
partition : Partition [0..*]
Partitions containing the node.
Stereotypes
None.
Tagged Values
None.
Constraints
None.
Semantics
Nodes can be named, however, nodes are not required to have unique names within an activity, to support multiple
invocations of the same behavior. See InvocationNode, which is a kind of node. The fact that Activity is a
Namespace, inherited through Behavior, does not affect this, because the containment of nodes is through ownedElement, the general ownership metaassociation for Element that does not imply unique names, rather than ownedMember. Other than this functionality, and those added by the complete version of activities, an activity node is only a
point in an activity at this level of abstraction. See the children of ActivityNode for additional semantics.
None.
251
ActivityNode
Notation
The notations for activity nodes are illustrated below. There are a three kinds of nodes: invocation node, object node,
and control node. See these classes for more information.
Iinvocation node
Signal
Object node
Control nodes
TimeSignal
Object nodes
Figure 12-28. Activity node notation.
Presentation Option
Style Guidelines
Examples
This figure illustrates the following kinds of activity node: invocation nodes (e.g., Receive Order, Fill Order), object
node (Invoice), and control nodes (the initial node before Receive Order, the decision node after Receive Order, and
the fork node and Join node around Ship Order, merge node before Close Order, and activity final after Close Order).
[order
rejected]
Fill
Order
Receive
Order
Ship
Order
Close
Order
[order
accepted]
Send
Invoice
Make
Payment
Accept
Payment
Invoice
Figure 12-29. Activity node example (where the arrowed lines are only the non-activity node symbols).
Rationale
Activity nodes are introduced to provide a general class for nodes connected by activity edges.
ActivityNode replaces the use of StateVertex and its children for activity modeling in UML 1.4.
252
ActivityParameter
ActivityParameter
An activity parameter is an object node for inputs and outputs to activities.
Description
Activity parameters are object nodes at the beginning and end of flows, to accept inputs to an activity and provide
outputs from it.
Attributes
None.
Associations
See Activity.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] Activity parameter object nodes must have either no incoming edges or no outgoing edges.
[2] Activity parameter object nodes with no incoming edges and one or more outgoing edges must have in or inout
direction.
[3] Activity parameter object nodes with no outgoing edges and one or more incoming edges must have in, inout, or
return direction.
See Activity.
Semantics
When an activity in invoked, the inputs values are placed as tokens on the input activity parameter object nodes, those
with no incoming edges. Outputs of the activity must flow to output activity parameter object nodes, those with no
outgoing edges. See semantics at ObjectNode, InvocationNode, and ActivityParameter.
None.
253
ActivityParameter
Notation
Also see notation at Activity.
Activity name
...
...
...

Presentation Option
Style Guidelines
Examples
In the example below, production materials are fed into printed ciruit board. At the end of the activity, computers are
quality checked.
Production
Materials
Rejected
Computers
Produce
Printed-Circuit
Boards
Assemble
Computers
PrintedCircuit
Boards
Test
Computers
Assembled
Computers
Accepted
Computers
Figure 12-31. Example of activity parameters.

Rationale
Activity parameter object nodes are introduced to model parameters of activities in way that integrates easily with the
rest of the flow model.
ActivityParameter is new in UML 2.0.
254
ActivityPartition
ActivityPartition
An activity partition is a special kind of grouping of activity nodes and edge.
Description
Partitions divide the nodes and edges to constrain and show a view of the contained nodes. Partitions can share contents. They often correspond to organizational units in a business model. They may be used to allocate characteristics
or resources among the nodes of an activity.
Attributes
isDimension : Boolean [1..1] = falseTells whether the partition groups other partitions along a dimension.
isExternal : Boolean [1..1] = falseTells whether the partition represents an entity to which the partitioning structure does not apply.
Associations
partition : ActivityPartition [0..1]
Partition immediately containing the partition.
represents : Element [0..1]
An element constraining behaviors invoked by nodes in the partition.
subpartition : ActivityPartition [0..*]
Partitions immediately contained in the partition.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] A partition with isDimension = true may not be contained by another partition.
[2] No node or edge of a partition may be in another partition in the same dimension.
[3] If a partition represents a part, then all the non-external partitions in the same dimension and at the same level of
nesting in that dimension must represent parts directly contained in the internal structure of the same classifier.
[4] If a non-external partition represents a classifier and is contained in another partition, then the containing partition must represent a classifier, and the classifier of the subpartition must be nested in the classifier represented
by the containing partition, or be at the contained end of a strong composition association with the classifier represented by the containing partition.
[5] If a partition represents a part and is contained by another partition, then the part must be of a classifier represented by the containing partition, or of a classifier that is the type of a part representing the containing partition.
Semantics
Partitions do not affect the token flow of the model. They constrain and provide a view on the behaviors invoked in
activities. Constraints vary according to the type of element that the partition represents. The following constraints
are normative:
1.
Classifier
Behaviors of invocations contained by the partition are the responsibility of instances of the classifier represented by the partition. This means the context of invoked behaviors is the classifier. Invoked procedures containing a
call to an operation or sending a signal must target objects at runtime that are instances of the classifier.
255
2.
ActivityPartition
Instance
This imposes the same constraints as classifier, but restricted to a particular instance of the classifier.
3.
Part
Behaviors of invocations contained by the partition are the responsibility of instances playing the part represented by the partition. This imposes the constraints for classifiers above according to the type of the part. In addition,
invoked procedures containing a call to an operation or sending a signal must target objects at runtime that play the
part at the time the message is sent. Just as partitions in the same dimension and nesting must be represented by parts
of the same classifiers internal structure, all the runtime target objects of operation and signal passing invoked by the
same execution of the activity must play parts of the same instance of the structured classifier. In particular, if an
activity is executed in the context of a particular object at runtime, the parts of that object will be used as targets. If a
part has more than one object playing it at runtime, the invocations are treated as if they were multiple, that is, the
calls are sent in parallel, and the invocation does not complete until all the operations return.
4.
Attribute and Value
A partition may be represented by an attribute and its subpartitions by values of that attribute. Behaviors of invocations contained by the subpartition have this attribute and the value represented by the subpartition. For example, a
partition may represent the location at which a behavior is carried out, and the subpartitions would represent specific
values for that attribute, such as Chicago. The location attribute could be on the process class associated with an
activity, or added in a profile to extend behaviors with these attributes.
A partition may be marked as being a dimension for its subpartitions. For example, an activity may be have one
dimension of partitions for location at which the contained behaviors are carried out, and another for the cost of performing them. Dimension partitions cannot be contained in any other partition.
Partitions may be used in a way that provides enough information for review by high-level modelers, though not
enough for execution. For example, if a partition represents a classifier, then behaviors in that partition are the responsibility of instances of the classifier, but the model may or may not say which instance in particular. In particular, a
behavior in the partition calling an operation would be limited to an operation on that classifier, but an input object
flow to the invocation might not be specified to tell which instance should be the target at runtime. The object flow
could be specified in a later stage of development to support execution. Another option would be to use partitions that
represent parts. Then when the activity executes in the context of a particular object, the parts of that object at runtime
will be used as targets for the operation calls, as described above.
External partitions are intentional exceptions to the rules for partition structure. For example, a dimension may have
partitions showing parts of a structured classifier. It can have an external partition that does not represent one of the
parts, but a completely separate classifier. In business modeling, external partitions can be used to model entities outside a business.
None.
Notation
Activity partition may be indicated with two, usually parallel lines, either horizontal or vertical, and a name labeling
the partition in a box at one end. Any activity nodes and edges placed between these lines are considered to be contained within the partition. Swimlanes can express hierarchical partitioning by representing the children in the hierarchy as further partitioning of the parent partition, as illustrated in b), below. Diagrams can also be partitioned
256
ActivityPartition
multidimensionally, as depicted in c), below, where, each swim cell is an intersection of multiple partitions. The specification for each dimension (e.g., part, attribute) is expressed in next to the appropriate partition set.
Partition Name
Dimension name
Partition
Name-2
Partition
Name-4
Partition
Name-1
Sub-partition
Name
Name
Sub-partition
Partition Name
Dimension name
a) Partition using a swimlane notation
Dimension name
Partition
Name-3
c) Partition using a multidimensional

hierarchical swimlane notation
b) Partition using a hierarchical swimlane notation

Figure 12-32. Activity partition notations.
In some diagramming situations, using parallel lines to delineate partitions is not practical. An alternate is to place the
partition name in parenthesis above the activity name, as illustrated for invocations in a), below. A comma-delimited
list of partition names means that the node is contained in more than one partition. A double colon witin a partition
name indicates that the partition is nested, with the larger partitions coming earlier in the name. When activities are
considered to occur outside the domain of a particular model, the partition can be label with the keyword external,
as illustrated in b) below. Whenever an activity in a swimlane is marked external, this overrides the swimlane and
dimension designation.
external
(Partition Name)
invocation
Partition Name
external
(PartitionName)
invocation
(Name1, Name2)
invocation
(Name::Subname)
invocation
a) Partition notated on a specific activity
b) Partition notated to occur outside

the primary concern of the model.
Figure 12-33. Activity partition notations.

Presentation Option
Style Guidelines
Examples
The figures below illustrate an example of partitioning the order processing activity diagram into swim lanes. The
top partition contains the portion of an activity for which the Order Department is responsible; the middle partition,
257
ActivityPartition
Order Department
Fill
Order
Receive
Order
Ship
Order
Close
Order
[order
accepted]
Acctg Department
attribute performingDept: Department
the Accounting Department, and the bottom the Customer. These are attributes of the behavior invoked in the partitions, except for Customer, which is external to the domain.
Send
Invoice
Accept
Payment
Customer
external
Invoice
Make Payment
Figure 12-34. Activity partition using swimlane example.
(Order
Department)
(Order
Department)
(Order
Department)
Receive
Order
Fill Order
Ship Order
Close Order
[order
accepted]
(Accounting
Department)
Send Invoice
(Order
Department)
external
(Customer)
Make
Payment
(Accounting
Department)
Accept
Payment
Invoice
Figure 12-35. Activity partition using annotation example.
The example below depicts multidimensional swim lanes. The Receive Order and Fill Order behaviors are perfomrmed by an instance of the Order Processor class, situated in Seattle, but not necessarily the same instance for both
258
Behavior (in Activities)
behaviors. Even though the Make Payment is contain with in the Seattle/Accounting Clerk swim cell, its performer
and location are not specified by the containing partition, because it has an overriding partition.
attribute performingLocation:Location
class
Accounting Clerk
class
Order Processor
Seattle
Reno
Fill
Order
Receive
Order
Ship
Order
Close
Order
[order
accepted]
external
Send
Invoice
(Customer)
Make Payment
Accept
Payment
Invoice
Figure 12-36. Activity partition using multidimensional swimlane example.

Rationale
Activity partitions are introduced to support the assignment of domain-specific information to invocations.
Edges can be contained in partitions in UML 2.0. Additional notation is provided for cases when swimlanes are too
cumbersome. Partitions can be hierarchical and multidimensional. The relation to classifier, parts, and attributes is
formalized, including external partitions as exceptions to these rules.
Behavior (in Activities)

Behavior is extended when used with activities.
Description
Behaviors can be marked as reentrant to control how they are invoked in an activity. See InvocationNode.
Attributes
isReentrant : Boolean [1..1] = true

Tells whether whether the behavior can be invoked while its still executing from a previous invocation.
Associations
None.
259
CentralBufferNode
Stereotypes
None.
Tagged Values
None.
Constraints
[1] Behaviors must be activities to have parameters that are activity parameters.
Semantics
If a behavior is non-reentrant, then no more than one invocation of it will be executing at any given time. See InvocationNode and Parameter (in Activities).
None.
Notation
See InvocationNode.
Presentation Option
None.
Style Guidelines
Examples
See examples at InvocationNode.
Rationale
Behavior (in Activities) is extended to support the semantics of invoking behaviors in activities.
Behavior (in Activities) is new to UML 2.0.
CentralBufferNode
A central buffer node is a object node for managing flows from multiple sources and destinations.
Description
A central buffer node accepts tokens from upstream objects nodes and passes them along to downstream object
nodes. They act as a buffer for multiple in flows and out flows from other object nodes. They do not connect directly
to invocations.
Attributes
None.
260
CentralBufferNode
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
None.
Semantics
See semantics at ObjectNode. All object nodes have buffer functionality, but central buffers differ in that they are not
tied to an invocation as parameter usage nodes are, or to an activity as activity parameters are, and they do not have
signal sending and receiving semantics as signal nodes do. See example below.
None.
Notation
See notation at ObjectNode. A central buffer may also have the keyword centralBuffer as shown below. This is
useful when it needs to be distinguished from the standalone notation for parameter usages shown on the left of Figure 12-72 and the top left of Figure 12-74.
centralBuffer
Figure 12-37. Optional central buffer notation.
261
ChangeSignal
Presentation Option
Style Guidelines
Examples
In the example below, the behaviors for making parts at two factories produce finished parts. The central buffer node
collects the parts, and behaviors after it in the flow use them as needed. All the parts that are not used will be packed
as spares, because each token can only be drawn from the object node by one outgoing edge.
Part
[Fnished]
Make Parts
at Factory 1
Part
[Fnished]
centralBuffer
Part
[Finished]
Make Parts
at Factory2
Part
[Fnished]
Part
[Fnished]
Pack
Parts
Use
Parts
Figure 12-38. Central buffer node example.

Rationale
Central buffer nodes give additional support for queuing and competition between flowing objects.
CentralBufferNode is new in UML 2.0.
ChangeSignal
A change signal is a signal notifying the recipient of a change to an object.
Description
A change signal has a value specification to indicate when the signal should be sent according to changes in objects.
The specification may contain variables that are named according to the user-defined attributes of the signal. The
value of these variables are bound at runtime as values of the user-defined attributes of the signal before the signal is
sent.
Attributes
None.
Associations
changeSpec : ValueSpecification [1..1]Determines the conditions of objects under which the signal is sent..
Stereotypes
None.
262
ControlFlow
Tagged Values
None.
Constraints
None.
Semantics
The signal is sent when the conditions of the change specification become true. That is, the conditions must first be
absent, then become present, at which point the signal is sent. The signal is not sent redundantly while the condition
is true.
None.
Notation
None.
Presentation Option
None.
Style Guidelines
Examples
For example, a signal may be sent when a traffic light changes color. The particular color it changes to can be
recorded in an attribute of the signal.
Rationale
Change signals provide a way for changes detected by a publish/subscribe mechanism or clearinghouse to be communicated to subscribers, and to indicate the change to be detected.
ChangeSignal does not replace ChangeEvent in UML 1.4. It provides a more explicit way for objects to be notified of
changes in objects.
ControlFlow
A control flow edge starts an activity node after the previous one is finished.
Description
Objects and data cannot pass along a control flow edge.
Attributes
None.
Associations
None.
263
ControlFlow
Stereotypes
None.
Tagged Values
None.
Constraints
[1] Control flows may not have object nodes at either end.
Semantics
See semantics inherited from ActivityEdge. A control flow is an activity edge that only passes control tokens. Tokens
nominated by the source node are all approved as candidates for the target node.
None.
Notation
A control flow is notated by an arrowed line connecting two invocation node.
Control flow
(without invocation nodes)
Control flow edge linking

two invocation nodes
Figure 12-39. Control flow notation.

Presentation Option
Style Guidelines
Examples
The figure below depicts an example of the Fill Order behavior passing control to the Ship Order behavior. The activity edge between the two is a control flow which indicates that when Fill Order is completed, Ship Order is invoked.
Fill
Order
Ship
Order
Figure 12-40. Control flow example.

Rationale
Control flow is introduced to model the sequencing of behaviors that does not involve the flow of objects.
264
ControlNode

Explicitly modeled control flows are new in UML 2.0. They replace the use of (state) Transition in UML 1.4 activity
modeling.
ControlNode
A control node is an abstract activity node that coordinates flows in an activity.
Description
A control node is an activity node used to coordinate the flows between other nodes. It covers initial node, final node
and its children, fork node, join node, decision node, and merge node.
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] The edges coming into and out of a control node must be either all object flows or all control flows.
Semantics
See semantics at Activity. See subclasses for the semantics of each kind of control node.
None.
Notation
The notations for control nodes are illustrated below: decision node, fork node, join node, initial node, activity final,
and flow final. Fork node and join node are the same symbol, they have different semantics and are distinguished
notationally by the way edges are used with them. For more information, see ForkNode and JoinNode below.
Decision node
or Merge node
Fork node, join node
Initial node
Activity final
Flow final
Final nodes
Figure 12-41. Control node notations.
265
DecisionNode
Presentation Option
Style Guidelines
Examples
The figure below contains examples of various kinds of control nodes. An initial node is depicted in the upper left as
triggering the Receive Order behavior. A decision node after Received Order illustrates branching based on order
rejected or order accepted conditions. Fill Order is followed by a fork node which passes control both to Send Invoice
and Ship Order. The join node indicates that control will be passed to the merge when both Ship Order and Accept
Payment are completed. Since a merge will just pass the token along, Close Order activity will be invoked. (Control
is also passed to Close Order whenever an order is rejected.) When Close Order is completed, control passes to an
activity final.
[order
rejected]
Fill
Order
Receive
Order
Ship
Order
Close
Order
[order
accepted]
Send
Invoice
Make
Payment
Accept
Payment
Invoice
Figure 12-42. Control node examples (with accompanying invocations and control flows).
Rationale
Control nodes are introduced to provide a general class for nodes that coordinate flows in an activity.
ControlNode replaces the use of PseudoState in UML 1.4 activity modeling.
DecisionNode
A decision node is a control node that chooses between outgoing flows.
Description
A decision node has one incoming edge and multiple outgoing activity edges.
Attributes
None.
266
DecisionNode
Associations
decisionInput : Behavior [0..1] Provides input to guard specifications on edges outgoing from the decision node.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] A decision node has one incoming edge.
[2] A decision input behavior has one input parameter and one output parameter. The input parameter must be the
same as or a supertype the type of object token coming along the incoming edge. The behavior cannot have side
effects.
Semantics
Each token arriving at a decision node can traverse only one outgoing edge. Tokens are not duplicated. Each candidate token on the incoming edge is nominated to the outgoing edges.
Most commonly, guards of the outgoing edges are evaluated to determine which edge should be traversed. The order
in which guards are evaluated is not defined, because edges in general are not required to determine their candidates
in any particular order. The modeler should arrange that each token only be elected to traverse one outgoing edge,
otherwise there will be race conditions among the outgoing edges. For decision points, a predefined guard else may
be defined for at most one outgoing edge. This guard succeeds for a token only if the token fails the election process
for all the other edges outgoing from the decision point.
Notice that the semantics only requires that the token traverse one edge, rather than be a candidate for only one edge.
Multiple edges may approve the nominated token as candidate, but if only one of them has a target that accepts the
candidate, then that edge is traversed. If multiple edges accept the token as candidate and have approval from their
targets for traversal all at once, then the semantics is not defined.
If a decision input behavior is specified, then each token is passed to the behavior before guards are evaluated on the
outgoing edges. The output of the behavior is available to the guard. Because the behavior is used during the election
process, it may be run many times on the same token before the token passes the entire election process and traverses
the edge. This means the behavior cannot have side effects. It may not modify objects, but it may for example, navigate from one object to another or get an attribute value from an object.
None.
Notation
The notation for a decision node is a diamond-shaped symbol, as illustrated on the left side of the figure below. Decision input behavior is specified by the keyword decisionInput placed in a note symbol, and attached to the appropriate decision node symbol as illustrated in the figure below.
A decision node must have a single activity edge entering it, and one or more edges leaving it. The functionality of
decision node and merge node can be combined by using the same node symbol, as illustrated at the right side of the
figure below. This case maps to a model containing a a merge node with all the incoming edges shown in the diagram
267
DecisionNode
and one outgoing edge to a decision node that has all the outgoing edges shown in the diagram. It assumes the UML
2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to model elements.
Decision node
Decision node
(with control flows)
Decision node
with behavior
...
...
...
decisionInput
decision condition
Decision node and merge node used

together, sharing the same symbol
Figure 12-43. Decision node notation.

Presentation Option
Style Guidelines
Examples
The figure below contains a decision node that follows the Received Order behavior. The branching is based on
whether order was rejected or accepted. An order accepted condition results in passing control to Fill Order and
rejected orders to Close Order.
[order
rejected]
Fill
Order
Receive
Order
Close
Order
[order
accepted]
Figure 12-44. Decision node example.
The example in the figure below illustrates an order process example. Here, an order item is pulled from stock and
prepared for delivery. Since the item has been remove from inventory, the reorder level should also be checked; and if
the actual level falls below a prespecified reorder point, more of the same type of item should be reordered.
Prepare Item
for Delivery
Pull
Order Item
from Stock
Ship
Order
[true]
[false]
Reorder
Goods
decisionInput
inventoryLevel
< reorderPoint
Figure 12-45. Decision node example.

Rationale
Decision nodes are introduced to support conditionals in activities.
268
FinalNode

Decision nodes replace the use of PseudoState with junction kind in UML 1.4 activity modeling.
FinalNode
A final node is an abstract control node at which a flow in an activity stops.
Description
See descriptions at children of final node.
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] A final node has no outgoing edges.
Semantics
All candidate tokens on incoming edges are accepted. See children of final node for other semantics.
None.
Notation
The notations for final node are illustrated below. There are a two kinds of final node: activity final and flow final.
For more detail on each of these specializations, see ActivityFinal and FlowFinal.
Activity final
Flow final
Figure 12-46. Final node notation.
269
FlowFinal
Presentation Option
Style Guidelines
Examples
The figure below illustrates two kinds of final node: flow final and activity final. In this example, it is assumed that
many components can be built and installed before finally delivering the resulting application. Here, the Build Component behavior occurs iteratively for each component. When the last component is built, the end of the building iteration is indicated with a flow final. However, even though all component building has come to an end, other
behaviors are still executing. When the last component has been installed, the application is delivered. When Deliver
Application has completed, control is passed to an activity final nodeindicating that all processing in the activity is
terminated.
Install
Component
Build
Component
[more components
to be built]
[no more
components
to be built]
[no more
components
to be installed]
Deliver
Application
[more components
to be installed]
Figure 12-47. Final node example.

Rationale
Final nodes are introduced to model where flows end in an activity.
FinalNode replaces the use of FinalState in UML 1.4 activity modeling, but its concrete classes have different semantics than FinalState.
FlowFinal
A flow final node is a final node that either terminates a flow.
Description
A flow final destroys all tokens that arrive at it.
Attributes
None.
Associations
None.
Stereotypes
None.
270
FlowFinal
Tagged Values
None.
Constraints
None.
Semantics
Flow final destroys tokens flowing into it.
None.
Notation
The notation for flow final is illustrated below.
Figure 12-48. Flow final notation.

Presentation Option
Style Guidelines
Examples
In the example below, it is assumed that many components can be built and installed. Here, the Build Component
behavior occurs iteratively for each component. When the last component is built, the end of the building iteration is
indicated with a flow final. However, even though all component building has come to an end, other behaviors are
still executing (such as Install Component).
Install
Component
Build
Component
[more components
to be built]
[no more
components
to be built]
Figure 12-49. Flow final example without merge edge.

Rationale
Flow final nodes are introduced to model termination or merging of a flow in an activity.
Flow final is new in UML 2.0.
271
ForkNode
ForkNode
A fork node is a control node that splits a flow into multiple concurrent flows.
Description
A fork node has one incoming edge and multiple outgoing edges.
Attributes
None.
Associations
Stereotypes
None.
Tagged Values
None.
Constraints
[1] A fork node has one incoming edge.
Semantics
Tokens arriving at a fork are duplicated across the outgoing edges. Candidate tokens on incoming edges are all nominated for the outgoing edges. When a token becomes a candidate on all outgoing edges and is also approved by their
target nodes for traversal, duplicates of the token are made and one copy traverses each edges. No duplication is necessary if there is only one outgoing edge, but it is not a useful case.
None.
Notation
Fork node
(without flows)
Fork node
(with flows)
...
...
...
The notation for a fork node is simply a line segment, as illustrated on the left side of the figure below. In usage, however, the fork node must have a single activity edge entering it, and two or more edges leaving it. The functionality of
join node and fork node can be combined by using the same node symbol, as illustrated at the right side of the figure
below. This case maps to a model containing a a join node with all the incoming edges shown the diagram and one
outgoing edge to a fork node that has all the outgoing edges shown in the diagram. It assumes the UML 2.0 Diagram
Interchange RFP supports the interchange of diagram elements and their mapping to model elements.
Join node and fork node used

Figure 12-50. Fork node notation.
272
InitialNode
Presentation Option
Style Guidelines
Examples
In the example below, the fork node passes control to both the Ship Order and Send Invoice behaviors when Fill
Order is completed.
Fill
Order
Fill
Order
Send
Invoice
Figure 12-51. Fork node example.

Rationale
Fork nodes are introduced to support parallelism in activities.
Fork nodes replace the use of PseudoState with fork kind in UML 1.4 activity modeling. State machine forks in UML
1.4 required synchronization between parallel flows through the state machine RTC step. UML 2.0 activity forks
model unrestricted parallelism.
InitialNode
An initial node is a control node at which flow starts when the activity is invoked.
Description
An activity may have more than one initial node.
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] An initial node has no incoming edges.
273
InvocationNode
Semantics
An initial node is a starting point for invoking an activity. A control token is placed at the initial node when the activity starts. Tokens in an initial node are nominated for all outgoing edges. If an activity has more than one initial node,
then invoking the activity starts multiple flows, one at each initial node. For convenience, initial nodes are an exception to the rule that control nodes cannot hold tokens if they are blocked from moving downstream (see Activity).
This is equivalent interposing a CentralBufferNode between the initial node and its outgoing edges.
Note that flows can also start at object nodes that have no incoming edges. See ActivityParameter and SignalNode.
None.
Notation
Initial nodes are notated as a solid circle, as indicated in the figure below.
Figure 12-52. Initial node notation.

Presentation Option
Style Guidelines
Examples
In the example below, the initial node passes control to the Receive Order behavior at the start of an activity.
Receive
Order
Figure 12-53. Initial node example.
Rationale
Initial nodes are introduced to model where flows start in an activity.
InitialNode replaces the use of PseudoState with kind initial in UML 1.4 activity modeling.
InvocationNode
An invocation node is a node for the use of a behavior within an activity.
Description
Invocation nodes can show the use of any behavior, including activities. See Rationale section.
Attributes
None.
274
InvocationNode
Associations
activity : Behavior [1..1]
[argument] : ParameterUsageNode [0..*]Gives the object nodes from which inputs are taken. Specialized from
BehaviorInvocation.
[result] : ParameterUsageNode [0..*]Gives the object nodes from to which outputs are posted. Specialized from
BehaviorInvocation.
The behavior invoked at this point in the activity.
Stereotypes
None.
Tagged Values
None.
Constraints
None.
Semantics
Invocation nodes start their specified behaviors, taking the inputs from incoming edges, and posting outputs to outgoing edges. All control tokens from control edges coming into the invocation must arrive for the behavior to start.
When the behavior is finished, tokens are nominated on all outgoing control edges, with a copy made for each control
edge. Object and data tokens are nominated on the outgoing object flow edges as determined by the target parameter
usage node. Each parameter of the behavior of the invocation provides input to a parameter usage node or takes output from one. See ParameterUsageNode. If the behavior being invoked is an action that calls a behavioral feature, the
inputs to the invocation node determine the target object and additional actual arguments of the call.
All invocations are synchronous in the intermediate version of activities. An invocation completes when its behavior
completes. If it is desired to start the invocation and have some outputs provided later when they are needed, then use
a fork to give the invocation its own flow line, and rejoin the outputs of the invocation to the original flow when they
are needed.
Invocation nodes share with object nodes the capability to hold tokens before they move downstream. However,
invocations differ in that they can require that all tokens be nominated at the same time, whereas object nodes can
only nominate tokens individually to each edge. Invocations also assign tokens to particular edges, whereas outgoing
edges from object nodes choose from any of the tokens nominated by the object node.
An invocation of a reentrant beahvior will start the behavior with newly arrived tokens, even if the behavior is already
executing from tokens arriving at the invocation earlier. An invocation of a non-reentrant behavior does not start the
behavior when the behavior is already executing. In this case, tokens collect at the input parameter usages of the invocation, if their upper bound is greater than one, or upstream otherwise.
See variations in ActivityEdge and ObjectNode.
275
InvocationNode
Notation
Each invocation node starts one behavior. Invocation nodes are notated as round-cornered rectangles. The name of
the behavior that is started by the invocation node is placed inside the rectangle. If the invocation node has a different
name than the behavior, then this is used in the rectangle instead.
name
Figure 12-54. Invocation node

Other notations depend on the type of behavior being invoked. If the behavior is an activity, then this is optionally
indicated in the invoking activity by placing a rake-style symbol within the round-cornered rectangle of the invocation node notation. The rake resembles a miniature hierarchy, indicating that this invocation starts another activity
that has nodes and edges. An alternative notation is to show the contents of the invoked activity inside the round-cornered rectangle. Edges flowing into the invocation connect to the parameter object nodes in the invoked activity. The
parameter object nodes are shown on the border of the invoked activity. The model is the same regardless of the
choice of notation. This assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to model elements..
Activity name
Activity
name
...
...
...
(Note: the border and name are the notation; the

other symbols are present to provide clarity, only.)
Figure 12-55. Invoking Activities that have nodes and edges.
If the behavior being invoked is a procedure that calls a behavioral feature, then the name of the behavioral feature is
displayed in the symbol. If the invocation node has a different name than the behavioral feature, then this is used in
the rectangle instead. The name of the class may optionally appear below the name of the behavioral feature, in
parentheses postfixed by a double colon. If the invocation node name is different than the behavioral feature name,
then the behavioral feature name may be shown after the double colon.
name
(ClassName::)
name
name
(ClassName::BehavioralFeatureName)
Figure 12-56. Invoking behavioral feature notations.

If the behavior being invoked is a procedure expressed in an action language, then a textual notation for the actions in
the procedure can be put in the symbol instead of the name, or below it, as shown in the figure below.
276
InvocationNode
Presentation Option
Style Guidelines
Examples
Examples of invocation nodes are illustrated below. These invoke behaviors called Send Payment and Accept Payment.
Send
Payment
Accept
Payment
Figure 12-57. Examples of invocation nodes.

Below is an example of invoking an activity. The invocation of the Fill Order activity uses the rake symbol to show
that it invokes an activity.
Fill
Order
Figure 12-58. Example of invoking an activity.
Below are examples of invocation nodes that start behavioral features.
Send
Invoice
Accept
Payment
Accept Payment
(Accounting::)
Accept Payment for Order

(Accounting::AcceptPayment)
Figure 12-59. Examples of invoking behavioral features.

Below is an example of an invocation node that starts an action behavior. The action language used in the round-cornered rectangle is implementation-dependent.
FOR every Employee

calculate salary
print check
ENDFOR
Figure 12-60. Example of invocation node for an action behavior.

Rationale
Invocation nodes are introduced to distinguish the use of a behavior from the behavior itself. Sometimes invocations
are informally called activities. However, the invocation is a distinct concept from behavior and activity, in order
to support the use of edges coming in and going out of the invocation. This means the same behavior can be invoked
277
from many activities, without burdening the content-independent behavior with the flows associated with its invocation in a particular activity.
Explicitly modeled invocation nodes are new in UML 2.0, and replace ActionState, CallState, and SubactivityState in
UML 1.4. They eliminate the need for separate metaclasses for invoking actions and activities.
An iteration group is a structured activity group that demarks a loop in the flow of an activity.
Description
An iteration group calls out an iteration that already exists in the flow.
Attributes
kind : IterationActivityGroupKind [1..1] = testAtBeginTells whether the test to continue the loop is done at the
beginning or end of the loop.
Associations
test : ValueSpecification [1..1] The specification used in a guard of an edge from a decision node that determines
whether to continue the loop.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] The guard specification of the edge crossing out of the group must be else. The source of this edge must be a
decision node. The decision node must have exactly two outgoing edges.
[2] The test specification of an iteration group must be the guard specification on the non-else edge outgoing from
the decision node identified in rule 2.
[3] If the kind of iteration is testAtBegin then the edge identified in rule 1 must target the decision node identified in
rule 2.
[4] If the kind of iteration is testAtEnd then the edge identified in rule 1 may not target the decision node identified in
rule 2.
Semantics
Iteration groups do not affect token flow in a model. They demark a part of the flow that is a loop, pointing to the
specification used as a guard on an edge outgoing from a decision node that determines whether to continue the iteration.
None.
278
Notation
The testAtEnd or testAtBegin loops are notated by placing a the keywords testAtEnd or testAtBegin along with
the decision condition specification within the group. The else guard specifies where the iteration terminates and
continues processing elseware.
testAtEnd
condition
[else]
testAtBegin
condition
[else]
Figure 12-61. Interation notation.

Presentation Option
Style Guidelines
Examples
The example below involves extracting the first hundred words from an article and emailing them to a recipient.
testAtEnd
when the first 100
words are extracted
Get Next
Word from
Article
[exit]
Email first
100 words
of article
Add to
Abstract
Figure 12-62. Iteration example.

Rationale
Iteration groups are introduced to emphasize structured iteration in an activity.
Iteration groups are new in UML 2.0.
The datatype IterationActivityGroupKind is an enumeration with possible values testAtBegin and testAtEnd.
279
JoinNode
JoinNode
A join node is a control node that synchronizes multiple flows.
Description
A join node has multiple incoming edges and one outgoing edge.
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] A join node has one outgoing edge.
Semantics
If there is a candidate token nominated along all incoming edges, then tokens are nominated on the outgoing edge
according to the following join rules:
1.
2.
If all the incoming candidate tokens are control tokens, then one control token is nominated along the outgoing
edge.
If some are control tokens and other data tokens, then only the data tokens are nominated.
No joining of tokens is necessary if there is only one incoming edge, but it is not a useful case.
If any tokens are nominated on the outgoing edge, they must be accepted or rejected for traversal before any more
tokens are nominated on the outgoing edge. If tokens are rejected for traversal, their nominations are withdrawn.
Other rules for when tokens may be passed along the outgoing edge depend the characteristics of the edge and its target. For example, if the outgoing edge targets an object node that has reached its upper bound, no token can be
passed. The rules may be optimized to a different algorithm as long as the effect is the same. In the full object node
example, the implementation can omit the unnecessary join evaluations until the down stream object node can accept
tokens.
None.
Notation
The notation for a join node is a line segment, as illustrated on the left side of the figure below. The join node must
have one or more activity edges entering it, and only one edge leaving it. The functionality of join node and fork node
can be combined by using the same node symbol, as illustrated at the right side of the figure below. This case maps to
a model containing a a join node with all the incoming edges shown in the diagram and one outgoing edge to a fork
node that has all the outgoing edges shown in the diagram. It assumes the UML 2.0 Diagram Interchange RFP sup-
280
MergeNode
Join node
(without flows)
Join node
(with flows)
...
...
...
ports the interchange of diagram elements and their mapping to model elements. Lastly, join specifications can be
represented by attaching a note to the join node, as depicted at the bottom of the figure.
Join node and fork node used

Figure 12-63. Join node notations.

Presentation Option
Style Guidelines
Examples
The example at the left of the figure indicates that a Join is used to synchronize the processing of the Ship Order and
Accept Order behaviors. Here, when both have been completed, control is passed to Close Order. The example at the
right illustrates how a join specification can be used to ensure that both a drink is selected and the correct amount of
money has been inserted before the drink is dispensed. Names of the incoming edges are used in the join specification
to refer to whether tokens are available on the edges.
{joinSpec =
A and B
and the total coin value
inserted is >= drink price}
Ship
Order
Accept
Order
Select
Drink
Close
Order
Insert
Coin
A
B
Dispense
Drink
Figure 12-64. Join node example.

Rationale
Join nodes are introduced to support parallelism in activities.
Join nodes replace the use of PseudoState with join kind in UML 1.4 activity modeling.
MergeNode
A merge node is a control node that brings together multiple flows without synchronization.
281
MergeNode
Description
A merge node has multiple incoming edges and a single outgoing edge.
Attributes
None.
Associations
Stereotypes
None.
Tagged Values
None.
Constraints
[1] A merge node has one outgoing edge.
Semantics
All candidate tokens on incoming edges are nominated on the outgoing edge. There is no synchronization of flows or
joining of tokens.
None.
Notation
Merge node
Merge node
(with flows)
...
...
...
The notation for a merge node is simply a diamond-shaped symbol, as illustrated on the left side of the figure below.
In usage, however, the merge node must have two or more edges entering it and a single activity edge leaving it. The
functionality of merge node and decision node can be combined by using the same node symbol, as illustrated at the
right side of the figure below. This case maps to a model containing a a merge node with all the incoming edges
shown the diagram and one outgoing edge to a decision node that has all the outgoing edges shown in the diagram. It
assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to
model elements.
Merge node and decision node used

Figure 12-65. Merge node notation.
282
ObjectFlow
Presentation Option
Style Guidelines
Examples
In the example below, either one or both of the behaviors, Buy Item or Make Item could have been invoked. As each
completes, control is passed to Ship Item. That is, if only one of Buy Item or Make Item complete, then Ship Item is
invoked only once; if both complete, Ship Item is invoked twice.
Buy
Item
Ship
Item
Make
Item
Figure 12-66. Merge node example.
Rationale
Merge nodes are introduced to support bringing multiple flows together in activities. For example, if a decision is
used after a fork, the two flows coming out of the decision need to be merged into one before going to a join. Otherwise the join will wait for both flows, only one of which will arrive.
Merge nodes replace the use of PseudoState with junction kind in UML 1.4 activity modeling.
ObjectFlow
An object flow is an activity edge that can have objects or data passing along it.
Description
An object flow is always used in conjunction with object nodes.
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
283
ObjectFlow
Constraints
[1] Object flows may have an invocation node on at most one end.
[2] Object flows with an invocation node at one end must have an parameter usage node at the other.
[3] Object flows with an invocation at one end may not have guards.
[4] Object nodes connected by an object flow, with optionally intervening control nodes, must have compatible
types. In particular, the downstream object node type must be the same or a supertype of the upstream object
node type.
[5] Object nodes connected by an object flow, with optionally intervening control nodes, must have the same upper
bounds.
Semantics
See semantics inherited from ActivityEdge. An object flow is an activity edge that only passes object and data
tokens. Tokens nominated by the source node are all approved as candidates for the target node, subject to the
restrictions inherited from ActivityEdge.
Two object flows may have the same object node as source. In this case the edges will compete for objects. Once an
edge takes an object from an object node, the other edges do not have access to it. Use a fork to duplicate tokens for
multiple uses.
None.
Notation
An object flow is notated by an arrowed line.
Object flow
(without activity nodes)
Two object flow edges linking

object nodes and invocation nodes
An object flow edge linking

two object node pins.
Figure 12-67. Object flow notations.
Presentation Option
To reduce clutter in complex diagrams, object nodes may be elided. The names of the invoked behaviors can suggest
their parameters. Tools may support hyperlinking from the edge lines to show the data flowing along them, and show
284
ObjectNode
a small square above the line to indicate that pins are elided, as illustrated in the figure below. Any adornments thatwould normally be near the pin, like effect, can be displayed at the ends of the flow lines.
With explicit pins
With pins elided
Figure 12-68. Eliding objects flowing on the edge.

Style Guidelines
Examples
In the example on the left below, the two arrowed lines are both object flow edges. This indicates that order objects
flow from Fill Order to Ship Order. In the example on the right, the one arrowed line starts from the Fill Order object
node pin and ends at Ship Order object node pin. This also indicates that order objects flow from Fill Order to Ship
Order.
Order
Fill
Order
Ship
Order
Order
Order
Fill
Order
Ship
Order
Figure 12-69. Object flow example.

On the left, the example below shows the Pick Materials activity provide an order along with its associated materials
for assembly. On the right, the object flow has been simplified through eliding the obect flow details.
Order
Pick
Materials
for Order
Materials
Order
Assemble
Order
Pick
Materials
for Order
Assemble
Order
Materials
With explicit pins
With elided pins
Figure 12-70. Eliding objects flowing on the edge.

Rationale
Object flow is introduced to model the flow of data and objects in an activity.
Explicitly modeled object flows are new in UML 2.0. They replace the use of (state) Transition in UML 1.4 activity
modeling.
ObjectNode
An object node is an abstract activity node that is part of defining object flow in an activity.
285
ObjectNode
Description
An object node is an activity node that indicates an instance of a particular classifier, possibly in a particular state,
may be available at a particular point in the activity. Object nodes can be used in a variety of ways, depending on
where objects are flowing from and to, as described in the semantics section.
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] All edges coming into or going out of object nodes must be object flow edges.
Semantics
The type association inherited from TypedElement is used in activity modeling. Object nodes may only contain
objects at runtime that conform to the type of the object node, in the state or states specified, if any. The isSet attribute
inherited from TypedElement (in Activities) is also used. If it is true, then the tokens contain sets of the type of the
object node. Multiple tokens containing the same value may reside in the object node at the same time. This includes
data values.
None.
Notation
Object nodes are notated as rectangles. A name labeling the node is placed inside the symbol, where the name indicates the type of the object node. Object nodes whose instances are sets of the name type are indicated with the
set keyword above the node name.
set
name
name
Object node
Object node
for tokens
containing sets
Figure 12-71. Object node notations.
286
ParameterUsageNode
Presentation Option
It is expected that the UML 2.0 Diagram Interchange RFP will define a metaassociation between model elements and
view elements, like diagrams. It can be used to link an object node to an object diagram showing the classifier that is
the type of the object and its relations to other elements. Tools can use this information in various ways to integrate
the activity and class diagrams, such as a hyperlink from the object node to the diagram, or insertion of the class diagram in the activity diagram as desired. See example in Figure 12-76.
Style Guidelines
Examples
See examples at ObjectFlow and children of ObjectNode.
Rationale
Object nodes are introduced to model the flow of objects in an activity.
ObjectNode replaces and extends ObjectFlowState in UML 1.4. In particular, it and its children support collection of
tokens at runtime, single sending and receipt, and the new pin style of activity model.
ParameterUsageNode
A parameter usage node is an object node for inputs and outputs to invocations.
Description
Parameter usage nodes flow directly to or from invocations. They provide input to the parameters of the behavior of
the invocation, or take output from them.
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] Parameter usage nodes must have both incoming and outgoing edges.
[2] Parameter usage nodes must have an invocation immediately upstream or downstream, but not both.
[3] Parameter usage nodes with invocations immediately upstream can only have one incoming edge, and must be
the usage of a parameter of the behavior of the upstream invocation that has out, inout, or return direction.
[4] Parameter usage nodes with invocations immediately downstream can only have one outgoing edge, and must
use a usage of a parameter of the behavior of the downstream invocation that has an in or inout direction.
287
ParameterUsageNode
[5] Parameter usage nodes must be the usage of the parameters of the behavior of the invocation that is either immediately upstream or downstream from the parameter usage node.
[6] The number of parameter usage nodes must be the same as the number of parameters of the behavior of the
immediately upstream or downstream invocation.
[7] The type (including isSet) of the parameter usage node must be compatible with the type of the parameter it is a
usage of.
See constraints on ObjectFlow.
Semantics
A parameter usage node is the usage in the flow of a parameter that accepts tokens from an invocation or provides
tokens to the invocation. The used parameter is from the behavior invoked by the immediately downstream or
upstream invocation node. The parameter usage is uniquely assigned to a parameter by matching the parameter usage
nodes of the invocetion in order with the parameters of the behavior in order. Weight can be set on the object flow
edges going from a parameter usage to an invocation to control how many tokens are taken into each invocation of
the behavior. See InvocationNode, ActivityParameter, and ObjectNode.
None.
Notation
Parameter usage node rectangles may be notated apart from invocation node round-cornered rectangles or may be
notated as small rectangles that are attached to invocation node rectangles. See figure below. The latter is informally
called the pin notation. Both of these notational styles map to the same model, which uses an parameter usage node
attached to an invocation. For example, a flow from one invocation node to another has two parameter usage nodes,
one for the output of the first invocation and one of the input of the second. This may be notated with a single standalone object node rectangle, but the model has two parameter usage nodes. It assumes the UML 2.0 Diagram Interchange RFP supports the interchange of diagram elements and their mapping to model elements. If the type of the
object nodes on each end of the flow is different, and a stand-alone notation is used, then the type displayed in the diagram is vendor-specific. In general, this sort of model should be displayed using the pin style to avoid ambiguity.
name
name
name
Parameter usage node ,
stand-alone style
Input parameter usage node,

pin-style
Output parameter usage node,

pin-style
Figure 12-72. Parameter usage node notations.

See ObjectNode for other notations applying to parameter usage nodes, with examples for parameter usage nodes
below.
288
ParameterUsageNode
Presentation Option
When edges are not present to distinguish input and output pin-style parameter usages, an optional arrow may be
placed inside the parameter usage rectangle, as shown below. Input pins have the arrow pointing toward the invocation and output pins have the arrow pointing away from the invocation.

pin-style, with arrow
Input parameter usage node,

pin-style, with arrow
Figure 12-73. Parameter usage node notations, with arrows.

Style Guidelines
Examples
In the example below, the parameter usage node named Order represents Order objects. In this example at the upper
left, the Fill Order behavior produces filled orders and Ship Order consumes them and an invocation of Fill Order
must complete for Ship Order to begin. The example on the upper right using pin notation expresses the same thing.
The example at the bottom of the figure illustrates the use of multiple pins.
Fill
Order
Ship
Order
Order
Order
Fill
Order
Ship
Order
Order
Order
Accept
Order
Pick
Materials
for Order
Materials
[picked]
Produce
Designs
PC designs
{stream}
Order
[accepted]
PC designs
Assemble
Order
Materials
[picked]
Order
[assembled]
Figure 12-74. Parameter usage examples.
289
SignalNode
Below is an example of the isSet attribute of object nodes. The partitioning behavior divides up all the members in an
asembly into groups. Once the gourps are defined, each is assigned to a room for working. The Assembly Members
object node contains tokens, each of which consists of one ore more assembly members.
Partition
Assembly into
Working Groups
set
Assembly
Members
Assign
groups to rooms
Figure 12-75. Specifying object nodes as containing sets.

In the figure below, the object node rectangle Order is linked to a class diagram that further defines the node. The
class diagram shows that filling an order requires order, line item, and the customers trim-and-finish requirements.
An Order token is the object flowing between the Accept and Fill activities, but linked to other objects. The activity
without the class diagram provides a simplified view of the process. The link to an associated class diagram is used to
show more detail.
Accept
Order
Fill
Order
Order
Object node
rectangle linked
with a class diagram
Order
Line
Item
Trim &
Finish
Figure 12-76. Linking a class diagram to an object node.

Rationale
Parameter usage nodes are introduced to model inputs and outputs of invocation nodes.
ParameterUsageNode is new in UML 2.0.
SignalNode
A signal node is an object node that sends or receives signals.
Description
Signals coming into the context object are placed as token in signal nodes. Signal objects flowing on edges into a signal node are sent out as signals to the context object.
Attributes
[type] : Signal
The signal sent or received by the signal node. Specialized from TypedElement.
290
SignalNode
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] Signal nodes must have either no incoming edges or no outgoing edges.
[2] The activity containing a signal node must have a context classifier or be owned by a classifier.
Semantics
The type of a signal node is a signal.
Signal nodes that have no incoming edges are receivers of signals sent to the classifier that is the context of the activity, or if the context is a behavioral feature, of the classifier owning the behavioral feature. Each activity in a classifier
gets a copy of all signals sent to the classifier. Each signal node with a type compatible with the arriving signal gets a
token with the signal object as a value when the signal arrives. A receiving object node of an activity can accept a signal only if the containing activity has been invoked and has not finished. See semantic variation points.
Signal nodes that have no outgoing edges are senders of signals to the classifier that is the context of the activity, or if
the context is a behavioral feature, of the classifier owning the behavioral feature. All candidate tokens nominated to
leave a signal node have the signal object they contain sent out as a signal to the classifier owning the containing
activity. Tokens are consumed by the signal node when signals are sent out. The classifier treats these signals as it
would any other signal. The signal may be noticed by activities on the classifier, including the one that sent it.
Also see semantics at ObjectNode.
The management of signals that arrive at an activity is a variation point. For example, implementations may choose to
buffer up signals if they are not used immediately, or not.
discard signals after they are used, or not.
keep separate signal buffers for each activity on an object, or not.
Notation
Signal nodes are notated with a, arrow-shaped pentagon. Object nodes with time signal type are notated with an hour
glass.
Signal node
Signal node with time signal type

Figure 12-77. Signal node notations.
291
StructuredActivityGroup
Presentation Option
Style Guidelines
Examples
The object node in the lower left is an example of a signal that an order cancellation request was made, resulting in an
invocation of a cancellation behavior. In the lower right, a signal can be raised that the end of the month occurred,
resulting in an behavior that reads the electric meter for monthly billing purposes.
Order
cancel
request
Cancel
Order
End of
month
occurred
Report
Meter
Reading
Figure 12-78. Signal node notations.

Rationale
Signal nodes are introduced to to abstract inputs and outputs of activities and invocations.
SignalNode replaces the control icons for sending and receiving signals in UML 1.x.
A structured activity group is a group is for demarking well-nested portions of the activity.
Description
A structured activity group demarks a portion of the activity that is not shared with any other structured group, and
that is entered only at one edge an exited only at one edge.
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] An activity containing an structured group has exactly one edge with its source outside the group and its target
inside the group.
292
TimeSignal
[2] An activity containing an structured group has exactly one edge with its source inside the group and its target outside the group.
[3] The edges in a structured group must have source and target nodes in the same group.
Semantics
Nodes and edges contained by a structured group cannot be contained by any other structured group. This constraint
is modeled as a specialized multiplicity from ActivityNode and ActivityEdge to StructuredActivityGroup. See children of StructuredActivityGroup.
None.
Notation
A structured activity group is notated with a dashed round cornered rectangle enclosed its nodes and edges, with the
keyword structured at the top. Also see children of StructuredActivityGroup.
Presentation Option
None.
Style Guidelines
Examples
Also see children of StructuredActivityGroup.
Rationale
StructuredActivityGroup is for applications that require well-nested flows.
StructuredActivityGroup is new in UML 2.0.
TimeSignal
A signal representing the passing of a point in time.
Description
A time signal has a value specification telling when the signal should be sent. The specification may contain variables
that are named according to the user-defined attributes of the signal. The value of these variables are bound at runtime
as values of the user-defined attributes of the signal before the signal is sent.
Attributes
None.
Associations
timeSpec : ValueSpecification [1..1]Determines when the signal should be sent..
Stereotypes
None.
293
TypedElement (in Activities)
Tagged Values
None.
Constraints
None.
Semantics
The signal is sent when the time passes given by the value specification, which must evaluate to a time. The signal is
not sent redundantly after the time passes.
None.
Notation
See notation for object nodes that have time signal type.
Presentation Option
None.
Style Guidelines
Examples
See examples for object nodes that have time signal type.
Rationale
Time signals provide a way for a timer mechanism to communicate to other objects.
TimeSignal does not replace TimeEvent in UML 1.4, but provides a more explicit way for objects to be notified of the
arrival of points in time.

TypedElement is extended when used with activities.
Description
TypedElement indicates whether values are sets of its type or not..
Attributes
isSet : Boolean [1..1] = false
Tells whether the values of the typed element are sets of the type or not.
Associations
None.
Stereotypes
None.
294
Tagged Values
None.
Constraints
None.
Semantics
The values of the typed element must be sets of its type. See ObjectNode and its children.
None.
Notation
See notation at ObjectNode.
Presentation Option
Style Guidelines
Examples
See examples at ObjectNode.
Rationale
TypedElement (in Activities) is extended to supports sets typing.
TypeElement (in Activities) is new in UML 2.0.
295
296
13 Common::Classes
Chapter 13. Common::Classes

The Classes package extends classes with the capability to represent the internal structure of classes by contained
parts and connectors.Figure 13-1 shows the dependencies of the Classes package on other packages within the Structure package.
Common
Behaviors
(from Common)
Ports
(from Common)
Classes
Figure 13-1. Dependencies of the Common::Classes package.

Port
(from Ports)
+ownedPort
EncapsulatedClassifier
(from Ports)
Class
+ is Behavior : Boolean = false
Class
Figure 13-2. Classes with internal structure.
Class (extended)
Description
Extends class with the capability to have internal structure and ports.
Semantics
As a kind of encapsulated classifier, class inherits all its properties. In addition to attributes, the structural features of
a class comprise its parts. Other features of class are ports and connectors. All objects instantiated from a class will
Classes.fm Version 2 beta R1
297
13 Common::Classes
Class (extended)
have slots matching all its features. The semantics of parts and connectors is given in Chapter 9, Basic::InternalStructures. The semantics of ports is given in Chapter 18, Common::Ports.
A class acts as the namespace for various kinds of classifiers defined within its scope, including classes. Nesting
of classifiers limits the visibility of the classifier to within the scope of the namespace of the containing class and is
used for reasons of information hiding. Nested classifiers are used like any other classifier in the containing class.
Notation
Presentation Option
A part symbol may be shown containing just a single name (without the colon) in its name string. This implies the
definition of an anonymously named class nested within the namespace of the containing class. The part has this
anonymous class as its type. Every occurrence of an anonymously named class is different from any other occurrence. The anonymously defined class has the properties specified with the part symbol. It is allowed to show compartments defining attributes and operations of the anonymously named class.
Examples
The following example shows two classes, Car and Wheel. The Car class has four parts, all of type Wheel, representing the four wheels of the car. The front wheels and the rear wheels are linked via a connector representing the front
and rear axle, respectively. An implicit association is defined as the type of each axle with each end typed by the
Wheel class. Figure 13-3 specifies that whenever an instance of the Car class is created, four instances of the Wheel
class are created and are strongly aggregated in the car instance. In addition, two links are created between the front
wheel instances and the rear wheel instances.
Wheel
Car
tire: String
size: String
leftfront :
Wheel
leftrear :
Wheel
frontaxle
rearaxle
rightfront :
Wheel
rightrear :
Wheel
Figure 13-3. Connectors and parts in a structure diagram.

Figure 13-4 specifies an equivalent system, but relies on multiplicities to show the replication of the wheel and axle
arrangement: This diagram specifies that there will be two instances of the left wheel and two instances of the right
298
13 Common::Classes
Port (extended)
wheel, with each matching instance connected by a link deriving from the connector representing the axle. As specified by the multiplicities, no additional instances of the Wheel class can be added as parts for a Car instance.
Car
Wheel
tire: String
size: String
axle
left: Wheel [2]
right: Wheel [2]
Figure 13-4. Connectors and parts in a structure diagram using multiplicities.

Finally, Figure 13-5 shows the constructor makeCar for the Car class (as specified in Figure 13-3). This constructor
takes a parameter brand of type String. It describes the internal structure of the Car that it creates and how the four
contained instances of Wheel will be initialized. In this case, every instnace of Wheel will have the predefined size
and use the brand of tire passed as parameter. The left wheel instances are given names, and all wheel instances are
shown as playing the parts. The types of the wheel instances are omitted.
makeCar (brand: String) : Car
l1 / leftfront
frontaxle
tire = brand
size = "215x95"
l2 / leftrear
Wheel
/ rightfront
tire: String
size: String
tire = brand
size = "215x95"
rearaxle
tire = brand
size = "215x95"
/ rightrear
Car
tire = brand
size = "215x95"
Figure 13-5. A constructor for the Car class.

Rationale
Not applicable.
Class has been extended with internal structure.
Port (extended)
Description
Port is extended with the ability to specify that any requests arriving at this port are handled by the behavior of the
owning classifier, rather than being forwarded to its parts, if any.
299
13 Common::Classes
Port (extended)
Attributes
isBehavior : Boolean
Specifies whether the port is attached to the behavior of the classifier (whether
the port is a behavior port). Any invocation of a behavioral feature targeted at a
behavior port will be handled by the instance of the owning classifier itself,
rather than by any instances that this classifier may contain. The default value is
false.
Semantics
For a behavior port, the instance of the owning classifier will handle any requests arriving at this port (as specified in
the behavior of the classifier, see Chapter 15, Common::CommonBehaviors), if this classifier has any behavior. If
there is no behavior defined for this classifier, any communication arriving at a behavior port is lost.
Notation
A behavior port is indicated by a port being connected through a line to a small state symbol drawn inside the symbol
representing the containing classifier. (The small state symbol indicates the behavior of the containing classifier.)
Engine
powertrain
p
power
Figure 13-6. Port notation.

Figure 13-6 shows the behavior port p, as indicated by its connection to the state symbol representing the behavior of
the Engine class. Its provided interface is powertrain. In addition, a required interface, power, is shown also.
300
14 Common::Collaborations
Chapter 14. Common::Collaborations

Entities in a system typically cooperate with each other to produce the behavior of a system. By behavior of a system it is meant that the system performs some task. The description of these cooperating entities involves two
aspects: 1) the structural description of the participants and 2) the description of their communication patterns (their
exchange of messages to accomplish a task). The structure of the participants that play the roles in the performance of
a specific task and their relationships will be modeled by a structured classifier (see Chapter 9, Basic::InternalStructures). The communication pattern performed by participants playing the roles to accomplish the task will be modeled by an interaction (see Chapter 8, Basic::Interactions).
A behavior of will eventually be exhibited by a set of cooperating instances (specified by classifiers) that
exchange messages. However, to understand the mechanisms used in a design, it may be important to describe only
those aspects of these classifiers and their interactions that are involved in accomplishing a task or a related set of
tasks, projected from these classifiers. Collaborations allow us to describe only the relevant aspects of the cooperation of a set of instances. Interfaces allow the externally observable properties of an instance to be specified without
determining the classifier that will eventually be used to specify this instance. Consequentially, the roles in a collaboration will often be typed by interfaces rather than classes and will then prescribe properties that the participating
instances must exhibit, but will not determine what class will specify the participating instances.
A collaboration is not instantiated. Instead, the cooperation defined by the collaboration comes about as a consequence of the actual cooperation between the instances that play the roles defined in the collaboration.
Common
Behaviors
(from Basic)
InternalStructures
(from Basic)
Collaborations
Figure 14-1. Dependencies of the Common::Collaborations package.
Collaborations.fm Version 2 beta R1
301
ConnectableElement
(from InternalStructu...
(from InternalSt ructu...
*
+collaborationRole
[role]
*
Collaboration
Attribute
Parameter
Parameter
)
Attribute
(from Kernel)
Figure 14-2. Collaboration.
Dependency
(from Dependencies)
TypedElement
(from Kernel)
+roleBinding
[ownedElement]
RoleBinding
CollaborationOccurrence
*
+feature
[client]
+collaboration
[owner]
*
+role
[supplier]
+type
[type]
Collaboration
ConnectableElement
(from InternalStructu...
Figure 14-3. Collaboration.occurrence and role binding
Classifier
(from Kernel)
Operation
(from Kernel)
0..1
Operation
*
+collaboration
[ownedElement]
0.. 1
0..1
+representation
[collaboration]
*
+collaboration
[ownedElement]
0.. 1
0..1
+represent ation
[collaboration]
0..1
Classifier
Figure 14-4. Use of collaboration.occurrence
Attribute (extended)
Description
Attributes are allowed to be treated as connectable elements.
302
Operation (extended)
Constraints
[1] An attribute may only be associated with a connector end within the context of a collaboration.
Description
Classifier is extended with the capability to own collaboration occurrences. These collaboration occurrences link a
collaboration with the operation to give a high-level description of the workings of the operation.
Associations
collaboration : CollaborationOccurrence
References the collaboration occurrences owned by the operation. (Specializes
Element.ownedElement.)
representation : CollaborationOccurrence [ 0..1 ]

References a collaboration occurrence which indicates the collaboration that represents this operation. (Specializes Classifier.collaboration.)
Semantics
An operation can own collaboration occurrences which relate a collaboration to (aspects of) this operation. The
collaboration describes those aspects of this operation.
One of the collaboration occurrences owned by an operation may be singled out as representing the operation as
a whole. The collaboration that is related to the operation by this collaboration occurrence shows how the properties
of this operation (e.g., its parameters) interact to generate the overall behavior of the operation. The representing collaboration may be used to provide a description of the behavior of the operation at a different level of abstraction than
is offered by an associated description of the behavior itself (see Chapter 15, Common::CommonBehaviors). The
roles in the collaboration occurrence are mapped to properties of the operation by role bindings.
Notation
See CollaborationOccurrence.
Behavior.representation was shown as collaboration (Collaboration.representedOperation) in 1.x.
Description
Classifier is extended with the capability to own collaboration occurrences. These collaboration occurrences link a
collaboration with the classifier to give a high-level description of the workings of the classifier.
Associations
collaboration : CollaborationOccurrence
References the collaboration occurrences owned by the classifier. (Specializes
Element.ownedElement.)
303
Collaboration
representation : CollaborationOccurrence [ 0..1 ]

References a collaboration occurrence which indicates the collaboration that represents this classifier. (Specializes Classifier.collaboration.)
Semantics
A classifier can own collaboration occurrences which relate a collaboration to (aspects of) this classifier. The collaboration describes those aspects of this classifier.
One of the collaboration occurrences owned by a classifier may be singled out as representing the behavior of the
classifier as a whole. The collaboration that is related to the classifier by this collaboration occurrence shows how the
structural features of this classifier (e.g., its attributes and parts) interact to generate the overall behavior of the classifier. The representing collaboration may be used to provide a description of the behavior of the classifier at a different
level of abstraction than is offered by the intrernal structure of the classifier. The roles in the collaboration occurrence
are mapped to properties of the classifier by role bindings.
Notation
Replaces and widens the applicability of Collaboration.usedCollaboration. Replaces Collaboration.representedClassifier.
Collaboration
A collaboration describes how an operation or a classifier is realized by a set of classifiers used and related in a specific way. It may also be used to describe how a set of instances are used and related in a specific way.
Description
A collaboration is represented as a kind of classifier and defines a set of cooperating entities to be played by instances
(its roles), as well as a set of connectors that define links between the participating instances. The cooperating entities
are the parts of the collaboration (see Chapter 9, Basic::InternalStructures for detail on the concepts of parts and
connectors). A collaboration is not instantiable.
A collaboration specifies a view (or projection) of a set of cooperating classifiers. It describes the required links
between instances that play the roles of the collaboration, as well as the features required of the classifiers that specify
the participating instances. Several collaborations may describe different projections of the same set of classifiers.
Attributes
Associations
collaborationRole: ConnectableElement
References connectable elements owned by other classifiers which represent
roles that instances may play in this collaboration. (Abstract; specializes StructuredClassifier.role.)
Constraints
None.
304
Collaboration
Semantics
To understand the mechanisms used in a design, a collaboration allows to view only those aspects of the cooperating
instances and their interactions that are involved in accomplishing a task or a related set of tasks, projected from the
larger system of which they are parts of. These instances might be involved in other tasks as well.
A collaboration defines a set of cooperating participants that are needed for a given task. The roles of a collaboration will be played by instances when interacting with each other. Their relationships relevant for the given task are
shown as connectors between the roles. Roles of collaborations define a usage of instances, while the classifiers typing these parts specify all required properties of these instances. Thus, a collaboration specifies what properties
instances must have to be able to participate in the collaboration: A role specifies (through its type) the required set of
features a participating instance must have. The connectors between the roles specify what links must exist between
the participating instances.
Neither all features nor all contents of the participating instances nor all links between these instances are always
required in a particular collaboration. Therefore, a collaboration is often defined in terms of parts typed by interfaces
(see Chapter 7, Basic::Interfaces). An interface is a description of a set of properties (externally observable features) required by an instance. An interface can be viewed as a projection of the externally observable features of the
classifier realizing the interface. Instances of different classifiers can play a role defined by a given interface, as long
as these classifiers realize the interface, i.e., have all the required properties. Several interfaces may be realized by the
same classifier, even in the same context, but their features may be different subsets of the features of the realizing
classifier.
Collaborations may be specialized from other collaborations which means that the former collaboration specifies
a specialization of the task of the latter. All the roles of the general collaboration are also available in the specialized
collaboration. The specialized collaboration may, of course, contain additional roles, and the inherited roles may be
extended. However, the type of the role in the specialized collaboration must be a specialization of the type of the role
in the general collaboration. As these types could be interfaces, the realizing classifiers of the specialized roles are not
necessarily specializations of the realizing classifiers of the roles of the general collaboration; however, they are guaranteed to contain all the required properties.
A collaboration may be attached to an operation or a classifier through a CollaborationOccurrence. A collaboration used in this way describes how this operation or this classifier is realized by a set of cooperating instances. The
connectors defined within the collaboration specify the links between the instances when they perform the behavior
specified in the operation or the classifier. The collaboration specifies the context in which behavior is performed.
Such a collaboration may constrain the set of valid interactions that may occur between the instances that are connected by the link.
When there is a connector between two connectable elements in a collaboration, there will be a link between the
instances that play the roles within the collaboration. However, this link may not necessarily be an instance of the
type of the connector, but it may be derived from a (chain of) associations between the classifiers typing the features
bound to these roles.
A collaboration is not instantiable.
A parameterized collaboration represents a design construct that can be used repeatedly in different designs and
will be used to capture the structure of a design pattern. The participants in the collaboration typically will be template parameters of the generic collaboration. These parameters will be bound to particular model elements in each
instantiation of the generic collaboration.
Note: The term pattern is used synonymously for a collaboration template that describes the structure of
a design pattern. Therefore, UML patterns are more limited than those used by the design pattern community. In general, design patterns involve many non-structural aspects, such as heuristics for their use and
usage trade-offs. Such aspects are not modeled in UML but could be associated with a collaboration.
305
Notation
A collaboration specifies parts and connectors of a collaboration and can be shown in a structure diagram. In a collaboration diagram it is also possible to show interaction sequences between the roles (see Chapter 8, Basic::Interactions).
A collaboration is shown as a dashed ellipse icon containing the name of the collaboration. The internal structure of a
collaboration as comprised by roles and connectors may be shown in a compartment within the dashed ellipse icon.
Observer
Subject : CallQueue
Observer : SlidingBarIcon
Figure 14-5. The internal structure of the Observer collaboration shown inside the collaboration icon (a connection
is shown between the Subject and the Observer role).
Rationale
Collaborations are often associated with classifiers to describe the cooperation of parts of the classifier. Collaborations are can also be used to describe how parameters of behavior cooperate with parts of the context classifier. Those
connectable elements may be used directly in such a collaboration, without an intervening role binding.
The contents of a collaboration is specified as its internal structure relying on roles and connectors; the concepts of
ClassifierRole, AssociationRole, and AssociationEndRole have been superseded. A collaboration in UML 2.0 is a
kind of classifier, and can have any kind of behavioral descriptions associated.
Description
A collaboration occurrence represents one particular use of a collaboration to explain the relationships between the
parts of a classifier or the properties of an operation. It may also be used to indicate how a collaboration represents a
classifier or an operation. A collaboration occurrence indicates a set of roles and connectors that cooperate within the
classifier or operation according to a given collaboration, indicated by the type of the collaboration occurrence. There
may be multiple occurrences of a given collaboration within a classifier or operation, each involving a different set of
roles and connectors. A given role or connector may be involved in multiple occurrences of the same or different collaborations.
Attributes
Associations
type: Collaboration
The collaboration which is used in this occurrence. The collaboration defines the
cooperation among the roles of the classifier or operation and the way in which
these interact.
306
roleBinding: RoleBinding
A mapping from the roles of the collaboration type to the roles of the classifier or
operation. This mapping indicates which connectable element of the classifier or
operation plays which role(s) in the collaboration. A connectable element may be
bound to multiple roles in the same collaboration occurrence (that is, it may play
multiple roles).
Constraints
[1] All the features are in one classifier or operation and all roles are in one collaboration and they are compatible.
[2] Every role in the collaboration is bound within the collaboration occurrence to a connectable element within the
classifier or operation.
[3] If a collaboration associated with an operation contains a connector, there must be a path of associations between
the features to which the roles that are associated with the ends of the connector are bound to.
[4] If a collaboration associated with a classifier, the connectors in the classifier connect according to the connectors
in the collaboration
Semantics
A collaboration occurrence relates feature in its collaboration type to connectable elements in the classifier or operation that owns the collaboration occurrence.
Any behavior attached to the collaboration type applies to the set of roles and connectors bound within a given
collaboration occurrence. For example, an interaction among parts of a collaboration applies to the classifier parts
bound to a single collaboration occurrence. If the same connectable element is used in both the collaboration and the
represented element, no role binding is required to indicate their relationship.
Notation
A collaboration occurrence is shown by a dashed ellipse containing the name of the occurrence, a colon, and the name
of the collaboration type. The usual suppressions are permitted. The ellipse is drawn within the structure compartment of a classifier symbol. There is a dashed line from the ellipse to each of the parts in the role binding. The dashed
line is labeled on the part end with the name of the role part. In most cases, bindings for connectors can be determined
from the role bindings for the parts, but they may be shown when necessary by drawing a dashed line from the ellipse
to one end of a connector line; the dashed line is labeled on the connector end with the connector end name of the
bound connector in the collaboration. Connectors in the classifier may be elided if the parts at all their ends are bound
in a collaboration occurrence, and there is a connector between the corresponding roles.
Presentation Option
A dashed arrow with a stick arrowhead may be used to show that a collaboration represents an operation or a classifier. The arrowhead points at the represented operation or classifier. When using this presentation option, the role
bindings cannot be shown.
Window
display (...)
RealizeDisplay
Operation
Figure 14-6. Relationship between a collaboration and the element it represents
307
Examples
Sale
Buyer
Seller
Figure 14-7. The Sale collaboration.
BrokeredSale
wholesale:
Sale
broker
Buyer
Seller
Seller
producer
retail:
Sale
Buyer
consumer
Figure 14-8. The BrokeredSale collaboration.

This example shows the definition of two collaborations, Sale and BrokeredSale. Sale is used twice as part of the definition of BrokeredSale. Sale is a collaboration among two roles, a seller and a buyer (in this example, the types of the
roles are not specified). An interaction could be attached to Sale to specify the steps involved in making a Sale.
BrokeredSale is a collaboration among three roles, a producer, a broker, and a consumer. The specification of
BrokeredSale shows that it consists of two occurrences of the Sale collaboration, indicated be the dashed ellipses. The
occurrence wholesale indicates a Sale in which the producer is the seller and the broker is the buyer. The occurrence
retail indicates a Sale in which the broker is the seller and the consumer is the buyer. The connectors between sellers
and buyers are not shown in the two occurrences; these connectors are implicit in the BrokeredSale collaboration in
virtue of them being comprised of Sales. The BrokeredSale collaboration could itself be used as part of a larger collaboration.
Rationale
Not applicable.
308
Description
Parameters are allowed to be treated as connectable elements.
Constraints
[1] A parameter may only be associated with a connector end within the context of a collaboration.
RoleBinding
Description
A role binding maps a role in a collaboration to a role in a classifier. That is, it tells which role in the classifier plays
which role in the collaboration. The role bindings owned by a single collaboration occurrence represent a consistent
set of bindings that are meant to be used together. Role bindings in different collaboration occurrences are not meant
to be used together and are unrelated.
Attributes
Associations
feature: ConnectableElement Indicates a role within the classifier or operation that owns the collaboration
occurrence that contains the role binding. This part plays the collaboration role
indicated. (Specializes Dependency.client.)
role: ConnectableElement
Indicates a connectable element within the collaboration that is the type of the
collaboration occurrence that contains the role binding. This is the role being
bound to a role of the classifier or operation owning the collaboration occurrence.
(Specializes Dependency.client.)
Constraints
Semantics
Notation
Rationale
Not applicable.
309
14.2 Diagrams
14.2. Diagrams
Diagrams for collaborations are described in Chapter 37, Internal Structure Diagrams.
310
15 Common::CommonBehaviors
Chapter 15. Common::CommonBehaviors

The Common Behaviors subpackage of the Common package adds the infrastructure to communicate between
objects in the system and to invoke behaviors.
Common
Behaviors
(from Basic)
Interfaces
(from Basic)
Common
Behaviors
Figure 15-1. Dependencies of the Common::CommonBehaviors package.
CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am
311
15.1 Class Description
15.1. Class Description

BehavioralFeature
Classifier
(from Kernel)
+feature
Signal
+raisedException
[ raisedException]
BehavioralFeature
concurrency : CallConcurrencyKind
0..1
{ordered} *
<<enumeration>>
CallConcurrencyKind
sequential
guarded
concurrent
+ownedAttribute
Attribute
(from Kernel)
Figure 15-2. Extensions to behavioral features and signal.
BehavioralFeature
concurrency : CallCo...` rencyK ind
*
Signal
0..1
+signal
+reception
Reception
0..1
+ownedReception
Class
(from Kernel)
Class
isActive : Boolean
*
0..1
*
+ownedReception
Interface
Interface
(from Interfaces)
Figure 15-3. Reception.
312
Element
(from Kernel)
ValueSpecification
(from Kernel)
+arguments
[ ownedElement]
* {ordered}
SignalEvent
0..1
CallEvent
ChangeEvent
TimeEvent
+signal
Event
+operation
Signal
Operation
(from Kernel)
+when
[ ownedElement]
Expression
(from Kernel)
+c hangeExpression
[ownedElement]
Expression
(from Kernel)
Figure 15-4. Events
Description
A behavioral feature specifies that a classifier will respond to a designated request by invoking its implementing
method.
Attributes
concurrency : CallConcurrencyKind
Specifies the semantics of concurrent calls to the same passive instance (i.e., an instance
originating from a class with isActive being false). Active instances control access to
their own behavioral feature.
Associations
raisedException : Signal
The signals that the behavioral feature raises as exceptions. (Specializes BehavioralFeature.raisedException.)
Constraints
None.
See BehavioralFeature (extended) in the Chapter 5, Basic::Common Behaviors package.
313
CallConcurrencyKind
CallConcurrencyKind
Description
CallConcurrencyKind is an enumeration with the following literals:
sequential
Instances that invoke a behavioral feature must coordinate so that only one invocation to
a target on any behavioral feature may be outstanding at once.
guarded
Multiple invocations of a behavioral feature may occur simultaneously to one instance,

but only one is allowed to commence. The others are blocked until the performance of
the first behavioral feature is complete. It is the responsibility of the system designer to
ensure that deadlocks do not occur due to simultaneous blocks.
concurrent
Multiple invocations of a behavioral feature may occur simultaneously to one instance

and all of them may proceed concurrently.
Attributes
None.
Associations
None.
Constraints
None.
Semantics
Not applicable.
Notation
None.
Rationale
Not applicable.
None.
CallEvent
Description
A call event represents the reception of a request to invoke a specific operation. A call event occurrence is distinct
from the call action that caused it.
Object creation and object destruction are special cases of call events. Create is a stereotyped call event denoting that the instance receiving that event has just been created. It invokes the classifier behavior defined for the
classifier specifying the created object. Destroy is a stereotyped call event denoting that the instance receiving the
event is being destroyed.
314
ChangeEvent
Attributes
None.
Associations
operation : Operation [1]
Designates the operation whose invocation raised the call event.
Constraints
None.
Semantics
A call event results in the execution of the behavior that implements the called operation.
The means by which requests are transported to their target depend on the type of requesting action, the target, the
properties of the communication medium, and numerous other factors. In some cases, this is instantaneous and completely reliable while in others it may involve transmission delays of variable duration, loss of requests, reordering, or
duplication.
Notation
None.
Rationale
Not applicable.
None.
ChangeEvent
Description
A change event models an event that occurs when a boolean-valued 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
an explicit action.
The 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 expression changes to false thereafter.
Attributes
None.
Associations
changeExpression : Expression [1]

A boolean-valued expression that results in the occurrence of the change event when its
value becomes true.
Constraints
None.
315
Class (extended)
Semantics
When the value of the change expression becomes true, a change event occurs.
Notation
None.
Rationale
Not applicable.
None.
Class (extended)
Attributes
isActive : Boolean
Determines whether an object specified by this class is active or not. An active object is
an object that, as a direct concsequence of its creation, commences to execute its behavior specification, and does not cease until either the complete specification is executed
or the object is terminated by some external agent. (This is sometimes referred to as the
object having its own thread of control.) The points at which an active object responds
to communications from other objects is determined solely by the behavior of the active
object and not by the invoking object. If this attribute is true, then a class is referred to
as an active class. If false, then such a class is referred to as a passive class.
Associations
ownedReception : Reception
Receptions that objects of this class are willing to accept. (Specializes

Notation
Presentation options
A class with the property isActive = true can be shown by a class box with an additional vertical bar on either side, as
depicted in Figure 15-5.
EngineControl
Figure 15-5. Active class
Event
Description
An event models an observable occurrence that may cause the execution of a specified behavior. An event is often
caused by the execution of an action, but need not be. Event is an abstract metaclass.
316
Interface (extended)
Attributes
None.
Associations
arguments: ValueSpecification The list of arguments used by the event. (Specializes Element.ownedElement.)
Constraints
None.
Semantics
Event occurrences are often 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.
Upon their occurrence, events are placed on the event queue of the object where they occurred. An event is dispatched when it is dequeued from the event queue and delivered to a behavior for processing. At this point, it is
referred to as the current event. The classifier behavior of the object consumes events from this queue. A consumed
event is no longer available for processing.
Any argument values associated with the current event are available to all behaviors caused by that event (such
as transition actions or entry actions).
No assumptions are made about the time intervals between event occurrence, event dispatching, and consumption.
This leaves open the possibility of different semantic variations such as zero-time semantics.
Notation
None.
Rationale
Not applicable.
Parameters of events have been changed to value specifications. These are available for all kinds of events.
Associations
ownedReception : Reception
Receptions that objects providing this interface are willing to accept. (Specializes
Reception
Description
A reception is a declaration stating that a classifier is prepared to react to the receipt of a signal. A reception designates a signal and specifies the expected behavioral response. The details of handling a signal are specified by the
behavior associated with the reception or the classifier itself.
317
Signal
Attributes
None.
Associations
signal: Signal [0..1]
The signal that this reception handles.
Constraints
[1] A Reception can not be a query.
not self.isQuery
Semantics
The receipt of a signal instance by the instance of the classifier owning a matching reception will cause the asynchronous invocation of the behavior specified as the method of the reception. The details of how the behavior responds to
the received signal depends on the kind of behavior associated with the reception. (For example, if the reception is
implemented by a state machine, the signal event will trigger a transition and subsequent effects as specified by that
state machine.)
Notation
Receptions are shown using the same notation as for operations with the stereotype signal.
Rationale
Not applicable.
None.
Signal
Description
A signal is a specification of an asynchronous stimulus communicated between instances. The target instance handles
the signal as specified by its receptions. The data carried by a signal is represented as attributes of the signal. A signal
is defined independently of the classifiers handling the signal.
Attributes
None.
Associations
reception : BehavioralFeature A set of behavioral features that are prepared to handle this signal.
Constraints
None.
Semantics
A signal triggers a reaction in the receiver in an asynchronous way and without a reply. By declaring a reception associated to a given signal, a classifier specifies that its instances will be able to receive that signal and will respond to it
with the designated behavior. An exception is a special kind of signal, typically used to signal fault situations. The
318
SignalEvent
sender of the exception aborts execution and execution resumes with 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.
Notation
None.
Rationale
Not applicable.
None.
SignalEvent
Description
A signal event represents the receipt of an asynchronous signal.
Attributes
signal : Signal [1]
The specific signal that is associated with this event.
Associations
None.
Constraints
None.
Semantics
A signal event results in the execution of the behavior that implements the reception matching the received signal.
The means by which requests are transported to their target depend on the type of requesting action, the target, the
properties of the communication medium, and numerous other factors. In some cases, this is instantaneous and completely reliable while in others it may involve transmission delays of variable duration, loss of requests, reordering, or
duplication.
Notation
None.
Rationale
Not applicable.
None.
319
TimeEvent
TimeEvent
Description
A TimeEvent models the expiration of a specific deadline.
Attributes
when : Expression [1]
Specifies the corresponding time deadline.
Associations
None.
Constraints
None.
Semantics
The expression specifying the deadline may be relative or absolute. If the 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.
There may be a variable delay between the time of reception and the time of dispatching (e.g., due to queueing
delays).
Notation
None.
Rationale
Not applicable.
None.
320
16 Common::Components
Chapter 16. Common::Components

The Components subpackage of the Common package specifies a set of constructs that can be used to define software
systems of arbitrary size and complexity. In particular, the package specifies modular units with well-defined interfaces: components and subsystems. These concepts address the area of component-based development and component-based system structuring, where a component is modeled throughout the development life cycle and
successively refined into deployment and run-time.
An important aspect of component-based development is the reuse of previously constructed components. A
component can always be considered an autonomous unit within a system or subsystem. It has one or more ports, and
its internals are hidden and inaccessible other than as provided by its interfaces. Although it may be dependent on
other elements in terms of interfaces that are required, a component is encapsulated and its dependencies are designed
such that it can be treated as independently as possible. As a result, components and subsystems can be flexibly
reused and replaced by connecting (wiring) them together via their provided and required interfaces. The aspects of
autonomy and reuse also extend to components at deployment time. The artifacts that implement component are
intended to be capable of being deployed and re-deployed independently, for instance to update an existing system.
The Components package supports the specification of both logical components (e.g. business components, process components) and physical components (e.g. EJB components, CORBA components, COM+ and .NET components), along with the artifacts that implement them and the nodes on which they are deployed and executed. It is
anticipated that profiles based around components will be developed for specific component technologies and associated hardware and software environments.
Kernel
(from Foundation)
Ports
(from Common)
Components
Figure 16-1. Dependencies of the Common::Components package.
Components.fm Version 2 beta R1
321

(from Ports)
PackagingNamespace
(from Kernel)
Memb erI mport

(f rom Kernel)
+componentImport
[import]
Component
isIndirectl yInstantiated : Boolean
1
0..1
PackagingNamespace
(f rom Ke rne l)
*
+elementImpor t
[elementImport]
+importedNamespace
[importedNamespace]
ComponentImport
ElementImport
(f rom Kernel)
Figure 16-2. The definition of the Component metaclass.
Component
A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.
A component exposes a set of ports that define the component specification in terms of provided and required
interfaces. As such, a component serves as a type, whose conformance is defined by these provided and required
interfaces (encompassing both their static as well as dynamic semantics). One component may therefore be substituted by another only if the two are type conformant.
Larger pieces of a systems functionality may be assembled by reusing components as parts in an encompassing
component or subsystem, or in a component assembly and wiring together their required and provided ports based on
interface compatibility.
A component may be manifest by one or more artifacts, and in turn, that artifact may be deployed to its environment. A deployment specification may define values that parameterize the components execution. (See Chapter 23,
Complete::ComponentDeployments.)
Description
A component is a subtype of EncapsulatedClassifier which provides for a component having an internal structure and
to own a set of ports that encapsulate its contents and formally define its interaction points.
A component is also a subtype of PackagingNamespace. This defines the Namespace aspects of a Component
through its inherited ownedMember and elementImport associations. In the namespace of a component, all classifiers
that act as the type of a Port, Part or Connector are either owned or imported explicitly. Interfaces that are the type of
Ports have public visibility in the namespace of the component.
Internal Parts and Connectors are private Features of the Component, but their Classifier types do not necessarily
have private visibility in the Components namespace (such that e.g. associations are possible to contained classes).
Apart from Classifiers, a Component may function as a fully fledged building block that defines owned and imported
AutonomousElements such as independent Behavior specifications and Dependencies.
Attributes
isIndirectlyInstantiated : Boolean
The kind of instantiation that applies to a Component. If false, the component is
instantiated as an addressable object and will have slots for all its parts. If true,
the Component is defined at design-time, but at run-time (or execution-time) an
322
Component
object specified by the Component does not exist. At run-time, the component is
instantiated only indirectly, through the instantiation of its parts (e.g. a focus
Class inside the Component) and the connectors between these parts. Indirect
instantiation is required for certain component implementations and for general
components such as installation components.
Associations
elementImport: ElementImport References the ElementImports owned by the Component. The association is a
specialization of the elementImport association from PackagingNamespace to
ElementImport.
componentImport: ComponentImport
References the ComponentImports owned by the Component. The association is
a specialization of the import association from PackagingNamespace to MemberImport.
Constraints
[1] The visibility of Port Features of a Component is public, the visibility of its Parts and Connectors is private.
[2] A Component minimally contains (through ownership or element import) in its Namespace all the Classifiers that
are the types of the representedComponents Features, i.e. Ports, Parts and Connectors.
Semantics
A component is a self contained unit that encapsulates the state and behavior of a set of classifiers. A component
specifies a formal contract of the services that it provides to its clients and those that it requires from other components in the system. The required and provided services are defined through ports that are characterized by interfaces.
A component does not realize an interface directly, instead, one its parts jointly realize all interfaces offered by the
component.
Thus, a component may be said to implicitly realizes the provided interfaces associated with its ports. The invocation of the behavioral features offered at a port by a provided interface must only be requested through that port.
There must be a connector to a part the type of which realizes an interface offering this service. An encapsulated classifier uses the required interfaces associated with its ports either implicitly or explicitly.
A component is a substitutable unit that can be replaced at design time or run-time by a component that offers that
offers equivalent functionality based on compatibility of its port definitions. As long as the environment obeys the
constraints expressed by the provided and required interfaces of a component, it will be able to interact with this environment. Similarly, a system can be extended by adding new component types that add new functionality.
A component has an external view (or. black-box view) by means of its publicly visible properties which are
defined through ports. A port represents a named interface that the component either provides to its environment or
requires from its environment.
Optionally, a protocol state machine attached to a port may define the external view more precisely by making
dynamic constraints in the sequence of operation calls explicit. Such a state machine must be conformant with the
state machine defined for the interface that types the port (if one has been defined). The overall coordination or
sequencing of behavior across port services may be defined in a specifying state machine. That is, the specifying state
machine must be conformant with the complete set of port protocols specified.
A component also has an internal view (or white-box view) by means of its private properties which are its
internal classifiers and how they are connected. This view shows how the external behavior is realized internally. The
mapping between external and internal view is by means of delegation connectors behind the ports that are connected
to internal parts (i.e. sub-components or classes).
323
Component
A contract between contained classifiers specifies how a the component provides its internal behavior as a result
to an external request by means of interaction or activity specifications. If protocol state machines have been specified for the ports, they can be mapped to implementation state machines of its parts.
Examples of commonly used stereotypes of component are:
entity
A persistent information component.
process
A transaction based component.
service
A stateless, functional component (computes a value).
Examples of commonly used stereotypes of classifiers that function as parts are:
focus
A part that implements the core business logic of the component.
auxiliary
A part that plays an auxiliary role in implementing the business logic (e.g. a database access class).
interfaceImplementation
A part that implements a provided interface of a component.
Notation
A component is shown as a Classifier rectangle with the keyword component. Optionally, in the right hand corner a
component icon can be displayed. This is a classifier rectangle with two smaller rectangles protruding from its left
hand side.
QuoteInf
component
QuoteService
Figure 16-3. A Component with one provided interface.
component
Order
Person
Invoice
OrderableItem
Figure 16-4. A Component with two provided and three required interfaces.
An external view of a Component is by means of Interface symbols sticking out of the Component box (external,
or black-box view). Alternatively, the interfaces can be listed in the second compartment of a component box. This
notation can be used for overview diagrams where components expose and require large sets of interfaces.
324
Component
component
Order
provided interfaces
OrderEntry
Billing
required interfaces
Person
Invoice
OrderableItem
Figure 16-5. Alternative black box notation of a component.
For displaying the full signature of an interface of a component, the interfaces can also be displayed as typical
classifier rectangles that can be expanded to show details of operations and events.
Interface
Interface
use
OrderEntry
Order
Person
FindbyName()
Create()
GetDetails()
Create()
ValidateDetails()
AddOrderline()
Figure 16-6. Explicit representation of the provided and required interfaces, allowing interface details such as operation to be
displayed (when desired).
An internal, or white box view of a Component is where the Classifier symbol has Ports that are displayed as elements in the second compartment under the component name compartment. The third compartment displays Parts
and (optionally) Connectors. The optional fourth compartment contains the name of any implementing Artifact. .
component
Order
provided interfaces
OrderEntry
AccountPayable
required interfaces
Person
parts
OrderHeader
LineItem
artifacts
Order.jar
Figure 16-7. A white-box representation of a component.
The internal structure of a component can be shown in more detail by viewing its parts and connectors. Classifiers that are owned or imported by a component can be shown nested inside the component. Optionally, explicit part
names or connector names can be shown in situations where the same Classifier or Association is the type of more
than one Part (Connector).
325
Component
Store
OrderEntry
delegate
Person
:Order
OrderEntry
:Customer
Person
OrderableItem
Account
delegate
OrderableItem
Account
:Product
Figure 16-8. An internal or white-box view of a hierarchical or nested component that contains other components as parts of its
internal assembly.
Order
OrderEntry
delegate
:OrderHeader
delegate
:order
:item
delegate
Person
:LineItem
order
item
OrderHeader
LineItem
Figure 16-9. An internal or white-box view of a component showing how the classes that function as internal parts are wired to
external interfaces.
326
Component
Order
OrderEntry
delegate
OrderHeader
delegate
order
item
delegate
Person
LineItem
Figure 16-10. A shorthand notation for a component showing classes that function as internal parts that are defined in the
namespace of the component.
Artifacts that implement components can be connected to them by physical containment or by an implement
relationship, which is an instance of the meta association between Component and Artifact.
A component specification is a static structure diagram with a graph of components (shown either in classifier
form or in nested form) that are linked by connector and dependency relationships. Connector relationships are
shown by dashed, directed arrows between provided and required Interfaces. Optionally, only provided Interfaces can
be shown explicitly (in which case the connector relationship originates directly from the requiring component).
Dependencies are shown as directed dashed lines from a client component to a supplier component that it depends
on in some way.
Examples
<<session>>
ShoppingCart
cart
client
customerOrder
cartOrder
<<entity>>
Customer
1..*
0..1
0..*
1
<<entity>>
Account
accountOrder
<<entity>>
OrderHeader
1..*
order
{xor}
organizationOrder
account
client
item
<<entity>>
Organization
<<entity>>
LineItem
serviceItem
productItem
{xor}
service
<<entity>>
Service
product
1
<<entity>>
Product
Figure 16-11. Example of an analysis level class model that can be componentized in a subsequent step.
327
Component
component
component
Order
Account
component
Product
Figure 16-12. Example of an overview diagram showing components and their general dependencies.
component
:Order
component
:Account
/account
1
delegate
focus
:OrderHeader
AccountPayable
concerns
*
delegate
:LineItem
/orderedItem
1
component
:Product
OrderableItem
Figure 16-13. Example of a platform independent model of a component, its provided and required interfaces, and wiring
connectors to other components based on the underlying structural associations.
328
Component
Person
:BackOrder
OrderEntry
:ShoppingCart
Person
:Order
:Customer
OrderEntry
Person
OrderableItem
OrderableItem
:Service
:Organization
OrderableItem
Client
:Product
Figure 16-14. Example of the internal structure of a component, with wiring between provided and required interfaces (Note:
Client interface is a subtype of Person).
Figure 16-15 shows an example how a technology specific profile might extend the Components model with stereotypes and tagged values.
EJBEntity
:Order
OrderEntry
EJBSession
:ShoppingCart
delegate
OrderEntry
delegate
AccountPayable
EJBEntity
:Account
AccountPayable
focus
EJBEntityClass
OrderHeader
order
item
auxiliary
JavaClass
UUIDGenerator
auxiliary
JavaClass
OrderDAOOracle
Person
auxiliary
EJBEntityClass
LineItem
delegate
OrderableItem
EJBEntity
:Service
EJBEntity
:Product
Figure 16-15. Example fragment of a platform specific design model for Enterprise Java Beans (EJB), with internal parts
functioning as focus and auxiliary classes that implement the components external wiring contract.
329
ComponentImport

The following changes from UML 1.x have been made:
In UML 2.0, a Component is notated by a classifier symbol that no longer has two protruding rectangles. These were
cumbersome to draw and did not scale well in all circumstances. Also, they interfered with any interface symbols on
the edge of the Component. Instead, a component keyword notation is used in UML 2.0. Optionally, a component
icon that is similar to the UML 1.4 icon can still be used in the upper right-hand corner of the component symbol. For
backward compatibility reasons, the UML 1.4 notation with protruding rectangles can still be used.
ComponentImport
A component imports allows one component to import the members of another packaging namespace, thereby making it possible to refer to elements of the imported packaging namespace as if they were defined in the importing
component (i.e., without using qualified names).
Description
ComponentImport is a kind of MemberImport that can only be owned by Components.
Attributes
Associations
importedNamespace: PackagingNamespace [1]

References the PackagingNamespace that is being imported by the importing
Component. The association is a concrete specialization of the importedNamespace association from MemberImport to Namespace.
Constraints
[1] The visibility of a ComponentImport is either public or private.
[2] Only the names (or aliases) of public AutonomousElements of the importedNamespace or Autonomous elements
with no specified visibility may be added to the namespace of the importingComponent.
Semantics
Notation
A component import is shown using a dashed arrow with an open arrowhead from the importing component to the
imported packaging namespace. A keyword is shown near the dashed arrow to identify which kind of component
import that is intended. The predefined keywords are import for a public component import , and use for a private component import.
This metaclass was added in UML 2.0.
330
16.2 Diagrams
16.2. Diagrams
In UML 2.0, Component diagrams are Static Structure diagrams, showing graphs of interconnected components,
either in classifier like notation or in containment like notation. In addition, Deployment diagrams show how
Component Artifacts are allocated to Nodes.
Because Component diagrams are no longer separate Implementation diagrams as in UML 1.4, Deployment diagrams are the only form of Implementation diagrams in UML 2.0. Hence, the term Implementation diagram is depracated.
331
16.2 Diagrams
332
17 Common::Deployments
Chapter 17. Common::Deployments

The Deployments subpackage of the Common package specifies a set of constructs that can be used to define the execution architecture of systems that represent the assignment of software artifacts to nodes. Nodes are connected
through communication paths to create network systems of arbitrary complexity. Nodes are typically defined in a
nested manner, and represent either hardware devices or software execution environments.
The Deployment package is expected to be extended in specific technology profiles to model specific hardware
and software environments.
Kernel
(from Foundation
InternalStructures
(from Basic)
Deployments
Figure 17-1. Dependencies of the Common::Deployments package.
Deployments.fm Version 2 beta R1
333
StructuredCl assifier
Class
(f rom Kernel )
+nest edNode
[ownedMember]
[nestedClassifier]
+nestedArtifact
*
Node
Artifact
+location
0..1
Auton omo usEleme nt

(from Kernel)
+depl oye dEl em ent
+implementedElement
fileName : String
contentStream : BinaryObject
0..1
+implementingArtifact
Relationship
(from Kernel)
[target]
+loc ation
ExecutionEnvironment
[source] 1..*
*
+depl oyme nt
+depl oyment
Dev ice
Deployment
Associ ation
(from Kernel )
+depl oyedArtif act
CommunicationPath
Network
{all ends in a communication

path are typed by nodes or by
networks}
{al l parts in a net wo rk are typ ed b y

no des, and all c onnecto rs are typ ed
by communi cati on path s}
Bi naryO bjec t
primitive type
Figure 17-2. The deployment of Artifacts to Nodes.
Artifact
An artifact represents a physical piece of information that is used or produced by a software development process,
and that can be deployed to nodes. Examples of artifacts include model files, source files, scripts, and binary executable files.
Description
In the metamodel, an Artifact is a Class that represents a physical entity. As a Class, Artifacts may have Features that
represent properties of the Artifact (for example, a read-only Attribute or a check-in Operation). Artifacts can be
involved in Associations to other Artifacts, specifically composition associations to Artifacts that are contained
within it.
334
Artifact
Attributes
filename : String [0..1]
The filesystem name for the Artifact.
contentStream : BinaryObject [0..1]

The binary content of the Artifact on the filesystem.
Associations
nestedArtifact : Artifact [*]
The Artifacts that are defined (nested) within the Artifact.

The association is a specialization of the nestedClassifier association from Class
to Classifier.
implementedElement : AutonomousElement [*]

The elements that are implemented by the Artifact.
deployment : Deployment [*] The deployment of an Artifact to a host Node.
Constraints
Semantics
An Artifact defined by the user represents a class of files in the physical world, typically denoted by a file extension. A particular instance of a file is deployed to a node instance. Artifacts may have composition associations to
other artifacts that are nested within it. For instance, a deployment descriptor artifact for a component may be contained within the artifact that implements that component. In that way, the component and its descriptor are deployed
to a node instance as one artifact instance.
Examples of commonly used stereotypes of artifact are:
file
A physical file in the context of the system developed
executable
Denotes a program file that can be executed on a computer system. Subclass of

file
script
A script file that can be interpreted by a computer system. Subclass of file.
source
A textual source file that can be compiled into an executable file. Subclass of
file.
library
A static or dynamic library file. Subclass of file.
document
A generic file that is not a source file or executable. Subclass of file.
These stereotypes can be further subclassed into implementation and platform specific stereotypes in profiles, for
example, jar for executable Java archives.
Notation
An artifact is presented using an ordinary class rectangle with the key-word artifact. Alternatively, it may be
depicted by a file icon.
335
Artifact
Optionally, the underlining of the name of an artifact instance may be omitted, as the context is assumed to be
known to users.
artifact
Order.jar
Figure 17-3. An Artifact instance.
The property string {location=name} maps into a Deployment to a Node. The name is the name of the hosting
Node. The property string {element=name} maps into an implemented element association. The name is the name
of the implemented element or elements.
artifact
Order.jar
{element = Order}
{location = AppServer1}
Figure 17-4. An Artifact displaying the name of the component that it implements and the location where it is deployed.
component
Order
implement
artifact
Order.jar
Figure 17-5. A visual representation of the implements relationship between artifacts and components.

The following changes from UML 1.x have been made: Artifacts have been extended to link to deployment specifications.
336
AutonomousElement (extended)
AutonomousElement (extended)
An autonomous element is extended in this chapter with capability to have on or more implementing Artifacts, that
may be deployed to Nodes.
Description
In the metamodel, AutonomousElement is extended with one concrete association to Artifact, and one concrete association to Node.
Attributes
Associations
implementingArtifact : Artifact [*]

The Artifacts that implement the element.
.location : Node [*]
The Nodes on which this element is deployed.

This is an optional association where the deployment of elements to Nodes can
be modeled without using Artifacts. In the case that explicit Artifacts are used in
Deployment, this association is derived via the implementing Artifact that is the
subject of one or more Deployments to Nodes.
Constraints
Semantics
Notation
The following changes from UML 1.x have been made: Only Components could have implementingArtifacts
associated with them in UML 1.4.
BinaryObject
BinaryObject is a primitive type that defines an arbitrary binary stream.
BinaryObject is used to type the content stream of an Artifact, as typically stored on a file system or transmitted
across a network. This property can be used to (optionally) interchange the artifact stream via XMI.
Description
In the metamodel, BinaryObject is a primitive type.
Attributes
337
CommunicationPath
Associations
Constraints
Semantics
Notation
The following changes from UML 1.x have been made: BinaryObject does not exist in UML 1.4.
CommunicationPath
A communication path is an association between two Nodes, through which Nodes are able to exchange signals and
messages.
Description
In the metamodel, CommunicationPath is a subclass of Association.
Attributes
Associations
Constraints
The types of the AssociationEnds of a CommunicationPath are typed by Nodes.
Semantics
Notation
The following changes from UML 1.x have been made: CommunicationPath does not exist in UML 1.4.
Deployment
A deployment is the allocation of an artifact to a node.
338
Deployment
Description
In the metamodel, Deployment is a subtype of Relationship.
Attribute
Associations
deployedArtifact : Artifact [*] The Artifacts that are deployed as a set onto a Node.
This association is redefined from Foundation::Elements::Relationship.source.
location : Node [1]
The Node which is the target of a Deployment.

This association is redefined from Foundation::Elements::Relationship.target
Constraints
Semantics
To be written.
Notation
Deployment diagrams show the allocation of Artifacts to Nodes according to the Deployments defined between them.
:AppServer1
artifact
ShoppinCart.jar
artifact
Order.jar
{component = SCart}
{component = Order}
Figure 17-6. A visual representation of the deployment location of component artifacts (including a dependency between the
artifacts).
339
Device
:AppServer1
Order.jar
ShoppingCart.jar
Account.jar
Product.jar
BackOrder.jar
Service.jar
Figure 17-7. A textual list based representation of the deployment location of artifacts.

The following changes from UML 1.x have been made: An association to DeploymentSpecification has been added.
Device
A Device is a physical computational resource with processing capability upon which artifacts may be deployed for
execution. Devices may be complex, i.e. they may consist of other devices.
Description
In the metamodel, a Device is a subclass of Node.
Attributes
Associations
Constraints
Semantics
A device may be a nested element, where a physical machine is decomposed into its elements, either through
namespace ownership or through attributes that are typed by Devices.
340
Notation
A Device is notated by a Node annotated with the stereotype device.
device
:AppServer
:DBServer
device
:DBServer
container
:J2EEServer
Order.jar
OrderSchema.ddl
ItemSchema.ddl
ShoppingCart.jar
Account.jar
Product.jar
BackOrder.jar
Service.jar
Figure 17-8. Notation for a Device.

The following changes from UML 1.x have been made: Device is not defined in UML 1.4.
A ExecutionEnvironment is a node that offers an execution environment for specific types of components that are
deployed on it in the form of executable artifacts.
Description
In the metamodel, a ExecutionEnvironment is a subclass of Node. It is usually part of a general Node, representing
the physical hardware environment on which the ExecutionEnvironment resides. In that environment, the ExecutionEnvironment implements a standard set of services that Components require at execution time (at the modeling
level these services are usually implicit). For each component Deployment, aspects of these services may be determined by properties in a DeploymentSpecification for a particular kind of ExecutionEnvironment.
Attributes
Associations
Constraints
341
Network
Semantics
ExecutionEnvironment instances are assigned to node instances by using composite associations between nodes and
ExecutionEnvironments, where the ExecutionEnvironment plays the role of the part. ExecutionEnvironments can be
nested, e.g. a database ExecutionEnvironment may be nested in an operating system ExecutionEnvironment. Components of the appropriate type are then deployed to specific ExecutionEnvironment nodes.
Typical examples of standard ExecutionEnvironments that specific profiles may define stereotypes for are:
OS ExecutionEnvironment
An operating system ExecutionEnvironment.
workflow ExecutionEnvironment
A ExecutionEnvironment that offers workflow services.
database ExecutionEnvironment
A ExecutionEnvironment that offers persistence and query services.
EJB ExecutionEnvironment
A ExecutionEnvironment for enterprise javabeans.
A ExecutionEnvironment can optionally have a default service component with infrastructure API, if the modeler wants to make the ExecutionEnvironment software execution environment services explicit.
Notation
A ExecutionEnvironment is notated by a Node annotated with the stereotype ExecutionEnvironment.
container
:J2EEServer
Order.jar
ShoppingCart.jar
Account.jar
Product.jar
BackOrder.jar
Service.jar
Figure 17-9. Notation for a ExecutionEnvironment (example of an instance of a J2EEServer ExecutionEnvironment).

The following changes from UML 1.x have been made: ExecutionEnvironment is not defined in UML 1.4.
Network
A network is a set of Nodes that are interconnected through communication paths.
Description
In the metamodel, Network is a subclass of Collaboration.
Attributes
Associations
342
Node
Constraints
The parts of a Network are typed by Nodes.
The connectors of a Network are typed by CommunicationPaths.
Semantics
Notation
The following changes from UML 1.x have been made: CommunicationPath does not exist in UML 1.4.
Node
A node is computational resource upon which artifacts may be deployed for execution.
Nodes can be interconnected through communication paths to define network structures.
Description
In the metamodel, a Node is a subclass of Class. It is associated with a Deployment of an Artifact. It is associated
with a set of Elements that are deployed on it. This is a derived association in that these Elements have an implementingArtifact that is deployed on the Node.
Attributes
Associations
nestedNode : Node [*]
The Nodes that are defined (nested) within the Node.

deployment : Deployment [*] The set of Deployments defined for this Node.
deployedElement : AutonomousElement [*]

A derived association that defines the set of AutonomousElements that are
deployed on the Node. The derivation is via the Deployment of the Artifact that
implements the Component.
Constraints
Semantics
Nodes can be connected to represent a network topology by using associations. Associations can be defined between
user defined nodes such as application server and client workstation to define the possible communication paths
between nodes. Specific network topologies can then be defined through links between node instances.
Hierarchical nodes (i.e. nodes within nodes) can be modeled using composition associations.
343
Node
Typical examples of nodes are
application server
A server computer that executes applications remotely.
client workstation
A client computer that executes the user interface of applications.
mobile device
A mobile computer.
embedded device
A computer that is part of a physical environment.
Notation
A node is shown as a figure that looks like a 3-dimensional view of a cube.
:AppServer
Figure 17-10. An instance of a Node.
Dashed arrows with the keyword deploy show the capability of a node type to support a component type.
Alternatively, this may be shown by nesting component symbols inside the node symbol.
Nodes may be connected by associations to other nodes. A link between node instances indicates a communication path between the nodes.
AppServer
DBServer
*
*
Figure 17-11. A communication path between Nodes.
344
17.2 Diagrams
Artifacts may be contained within node instance symbols. This indicates that the items are deployed on the node
instances.
:AppServer1
artifact
ShoppinCart.jar
artifact
Order.jar
{component = SCart}
{component = Order}
Figure 17-12. A set of deployed component artifacts on a Node.
Examples
The following changes from UML 1.x have been made: to be written.
17.2. Diagrams
Deployment diagrams show how Artifacts are allocated to Nodes.
Because Component diagrams are no longer separate Implementation diagrams, Deployment diagrams are the
only form of Implementation diagrams in UML 2.0. Hence, the term Implementation diagram is depracated
345
17.2 Diagrams
346
18 Common::Ports
Chapter 18. Common::Ports

The Ports subpackage in the Common package provides mechanisms for encapsulating a classifier from its environment. Ports allow to specify a classifier without any knowledge of the environment it will be embedded in.. As long
as the environment obeys the constraints expressed by the ports, such a classifier will function properly.
Interfaces
(from Basic)
InternalStructures
(from Basic)
Ports
Figure 18-1. Dependencies of the Common::Ports package.
Note: The conditions under which one may connect ports is still under discussion. The two options considered are structural (considering the signals and operations supported and required by the interfaces typing
the ports) or purely based on the types of the ports (without considering their structure). Constraints due to
these conditions are shown with in blue text with a blue sidebar in the subsequent text.
Ports.fm Version 2 beta R1
347
18 Common::Ports

ConnectableElement
(f rom InternalStruct ures)
(from InternalStructures)
EncapsulatedClass if ier
0..1
+ownedPort
[redefinitionCont ext ]
ConnectorEnd
Feature
(from Kernel)
Port
isService : Boolean = true
isSignal : Boolean = false
*
0..1
+required
/
Interface
(from Interfaces)
+provided
+port
*
{ visibility = public}
ConnectorEnd
(from InternalStruct ures )
+redefinedPort
[redefinedElement]
ComplexPort
StructuralFeature
(from Kernel)
Figure 18-2. The Port metaclass
ComplexPort
Description
A complex port, in addition to being an interaction point between a classifier and its environment, is also a structural
feature of the owning classifier. As such, it may specify behavior on its own as defined by its type. The classifier typing a complex port may impose, for example, state dependent behavior on the port, it may filter or reroute communication, etc.
Attributes
None.
Associations
None.
Constraints
[1] All provided interfaces of a complex port are mutually exclusive.
[2] All required interfaces of a complex port are mutually exclusive.
[3] The multiplicity of a composite port is 1..1.
Semantics
A complex port allows more elaborate constraints on the communication to be represented. For example, it may
describe that communication is filtered, modified in some way, or routed to other parts depending on its contents.The
behavior of a complex port is specified by the classifier that types the complex port. When an instance of the owning
classifier is created, an instance of the classifier that types the complex port is also created and will handle any com-
348
18 Common::Ports
Connector
munication targeted at this port as specified by that classifier. A link from that instance to the instance of the owning
classifier is created through which communication is forwarded to the instance of the owning classifier or through
which the owning classifier communicates with its environment.
Notation
A complex port is shown with the same notation as a port (see Port). The name string is placed near the square
symbol and follows the syntax of the name string for a part.
ComplexPort does not exist in UML 1.4.
Connector
When two ports are connected, additional constraints apply.
Constraints
ConnectorEnd
Description
A connector end is an endpoint of a connector, which attaches the connector to a part. Each connector end is part of
one connector. The connector ends of each connector are ordered.
Attributes
None.
Associations
port : Port [ 0..1 ]
Indicates the port to which the connector end is attached. This port could be
either a port of the containing classifier or a port on some part of the internal
structure of the classifier. In the first case, the connector end is only associated
with the port. Otherwise, the connector has an association to the port and an association to the corresponding part.
Constraints
Semantics
A connector end specifies which part is attached to the connector owning that end.
Notation
Adornments may be shown on the connector end corresponding to adornments on association ends (see Chapter 1,
Foundation::Kernel). These adornments specify properties of the association typing the connector.
Rationale
Not applicable.
349
18 Common::Ports

Connector end has been added in UML 2.0. The UML 1.4 concept of association end roles is subsumed by connector
ends.
Description
Extends a classifier with the ability to own ports as specific and type checked interaction points.
Attributes
Associations
ownedPort: Port
References a set of ports that an encapsulated classifier may own. (Specializes

Classifier.feature and Namespace.ownedMember.)
Constraints
Semantics
See Port.
Notation
This metaclass has been added to UML.
Port
A port is a feature of a classifier that specifies a distinct interaction point between that classifier and its environment
or between the (behavior of the) classifier and its internal parts. Ports are connected to other parts through connectors
through which requests can be made to invoke the behavioral features of a classifier. A Port may specify the services
a classifier offers to its environment (a provided port) as well as the services that a classifier expects of its environment (a required port).
Description
Ports represent interaction points between a classifier and its environment. The interfaces associated with a port specify the nature of the interactions that may occur over a port. The required interfaces of a port characterize the requests
which may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port. A port that has associated only
required interfaces is referred to as a required port (and supports only outbound communication); a port that has associated only provided interfaces is referred to as a provided port (and supports only inbound communication).
350
18 Common::Ports
Port
Attributes
isSignal: Boolean
If true, the port relays only signals. That is, the interfaces exposed by this port
contain only receptions. The default value for this attribute is false.
isService: Boolean
If true indicates that this port is used to provide the published functionality of a
classifier; if false, this port is used to implement the classifier but is not part of
the essential externally-visible functionality of the classifier and can,therefore, be
altered or deleted along with the internal implementation of the classifier and
other properties that are considered part of its implementation. The default value
for this attribute is true.
Associations
required: Interface
References the interfaces specifying the set of operations and receptions which
the classifier expects its environment to handle.
provided: Interface
References the interfaces specifying the set of operations and receptions which
the classifier offers to its environment, and which it will handle either directly or
by forwarding it to a part of its internal structure.
portEnd : ConnectorEnd
References the connector ends attached to this port.
redefinedPort: Port
A port may be redefined when its containing classifier is specialized. The redefining port may have additional interfaces to those that are associated with the
redefined port or it may replace an interface by one of its subtypes. A port may be
redefined into a complex port. (Specializes Element.redefinedElement.)
Constraints
[1] If a port is a required port, a connector may only connect this port to a port that is of the same type, or of a subtype (unless that port is a port on the containing classifier).
[2] If a port is a required port, a connector may only connect this port to a part that realizes the interface that types
this port, or a subtype thereof.
[3] Ports have public visibility.
Semantics
A port represents an interaction point between a classifier instance and its environment or between a classifier
instance and its internal parts. A port by default has public visibility. However, a behavior port may be hidden but
does not have to be.
The required interfaces characterize the behavioral features that the owning classifier expects from its environment and that it may access through this interaction point: The classifier expects that the features owned by its
required interfaces will be offered by one or more classifiers in its environment. The provided interfaces characterize
the behavioral features that the owning classifier offers to its environment at this interaction point: The owning classifier must support the features owned by the provided interfaces.
The provided and required interfaces completely characterize any interaction that may occur between a classifier
and its environment at a port. When an instance of a classifier with a port is created, that instance is identifiable not
just through its object identity, but also through a unique reference corresponding to each port (this reference is
referred to as an interaction point). It is, therefore, possible for an instance to differentiate between requests for the
invocation of a behavioral feature targeted at its different ports. Similarly, it is possible to direct such requests at a
port, and the requests will be routed as specified by the links corresponding to connectors attached to this port. (In the
following, requests arriving at a port shall mean request occurrences arriving at the interaction point of this
instance corresponding to this port.)
351
18 Common::Ports
Port
If connectors are attached to both the inbound and outbound sides of a port, the instance of the owning classifier
will forward any requests arriving at this port along the link specified by those connectors. If there is a connector
attached to only one side of a port, any requests arriving at this port will terminate at this port.
If several connectors are attached on one side of a port, then any request arriving at this port on a link derived from a
connector on the other side of the port will be forwarded on links corresponding to these connectors. It is a semantic
variation point whether these request will be forwarded on all links, or on only one of those links. In the latter case,
the link at which this request will be forwarded will be arbitrarily selected among those links attached to an instance
that had been specified as being able to handle this request (i.e., this request is specified in a provided interface of the
part corresponding to this instance).
Notation
A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. If the
port symbol is placed overlapping the boundary of the rectangle symbol denoting that classifier this port is exposed
(i.e., its visibility is public) which is the customary case. If the port is shown inside the rectangle symbol, then the port
is hidden and its visibility may be given (or is assumed private if not given).
A port of a classifier may also be shown as a small square symbol overlapping the boundary of the rectangle
symbol denoting a part typed by that classifier (see Figure 18-5).
A provided interface may be shown using the lollipop notation (see Chapter 7, Basic::Interfaces) attached to
the port. A required interface may be shown by the socket notation attached to the port. The presentation options
shown there are also applicable to interfaces of ports.
Engine
powertrain
p
power
Figure 18-3. Port notation.

Figure 18-3 shows the notation for ports: p is a port on the Engine class. The provided interface of port p is powertrain. In addition, a required interface, power, is shown also.
If there are multiple interfaces associated with a port, these interfaces may be listed with the interface icon, separated by commas. Figure 18-4 below shows a port OnlineServices on the OrderProcess class with two provided interfaces, OrderEntry and Tracking, as well as a required interface Payment.
Online
Services
OrderEntry,
Tracking
OrderProcess
Payment
Figure 18-4. Port notation showing multiple provided interfaces.
352
18 Common::Ports
Port
Presentation Option
The name of a port need not be shown. If the name of the port is omitted, it is given an anonymous name. Every
occurrence of a port with an anonymous name denotes a different port from any other occurrence.
Examples
powertrain
Engine
Car
p
axle
rear : Wheel [2]
e : Engine
power
<<interface>>
powertrain
Boat
shaft
<<interface>>
power
: Propeller
p
e : Engine
Figure 18-5. Port examples.

Figure 18-5 shows a class Engine with a port p with a provided interface powertrain. This interface specifies the services that the engine offers at this port (i.e., the operations and receptions that are accessible by communication arriving at this port). The interface power is the required interface of the engine. The required interface specifies the
services that the engine expects its environment to provide. At port p, the Engine class is completely encapsulated; it
can be specified without any knowledge of the environment the engine will be embedded in. As long as the environment obeys the constraints expressed by the provided and required interfaces of the engine, the engine will function
properly.
Two uses of the Engine class are depicted: Both a boat and a car contain a part that is an engine. The Car class
connects port p of the engine to a set of wheels via the axle. The Boat class connects port p of the engine to a propeller via the shaft. As long as the interaction between the Engine and the part linked to its port p obeys the constraints
specified by the provided and required interfaces, the engine will function as specified, whether it is an engine of a car
or an engine of a boat. (This example also shows that connectors need not necessarily attach to parts via ports (as
shown in the Car class.)
Rationale
By using ports, one can specify encapsulated classes independently from any knowledge about how these classes will
be used in a surrounding environment. The required and provided interfaces specify everything that is necessary to
use such a class and everything that is necessary for the class to be able to fulfill its task. Ports are also a mechanism
that allows a classifier to distinguish service requests based on its source.
This metaclass has been added to UML.
353
18 Common::Ports
Port
354
19 Common::StateMachines
Chapter 19. Common::StateMachines

The StateMachine package defines a set of concepts that can be used for modeling discrete behavior through finite
state-transition systems. Statemachines can be used to specify behavior of various model elements. 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. The statemachine formalism described in this section is an object-based variant of
Harel statecharts.
Common
Behaviors
(from Common)
StateMachines
Figure 19-1. Dependencies of the Common::StateMachines package.
StateMachines.fm Version 2 beta R1
355
<<enumeration>>
PseudostateKind
initial
deepHistory
shallowHistory
join
fork
junction
choice
entryPoint
stop
Behavior
0..1
StateMachine
+submachine
1
NamedElement
0..1
NamedElement
(from Kernel)
(fromKernel)
+region
+container
[owner]
*
StateVertex
0..1
0..1
+subvertex
[ownedElement]
Constraint
1..* [ownedMember]
+container
Region
[owner]
*
+outgoing
1
+target
*
+incoming
0..1
+transitions
* [ownedElement]
+contents
+source
(from Kernel)
+guard
[ownedElement]
0..1
Transition
isInternal : Boolean
*
0..1
0..1
State
Pseudostate
kind : PseudostateKind
*
+connectionPoint
[ownedMember]
1
*
+entry
ConnectionPoint
*
1
+definition
/
/
/
/
0..1
isComposite : Boolean
isOrthogonal : Boolean
isSimple : Boolean
isSubmachineState : Boolean
0..1
0..1
+effect
[ownedElement]
Procedure
+entry
[ownedElement]
0..1
0..1
+exit
[ownedElement]
0..1
+doActivity
[ownedElement]
0..1
0..1
*
+connection
[ownedElement]
*
+submachineState
+trigger
*
+exit
FinalState
+deferrableEvent
0..1
+port
Event
Port
(from Ports)
Event
(from CommonBehavio rs)
Figure 19-2. State Machines
356
ConnectionPoint
0..1
RedefinableElement
(fromKernel)
+ownedStateMachine
[ownedBehavior]
*
StateMachine
1..*
0..1
Transition
State
Region
*
0..1
+extendedRegion
[redefinedElement]
+redefinedState
[redefinedElement]
0..1
+replacedTransition
[redefinedElement]
0..1 [redefinitionContext]
/
0..1 [redefinitionContext]
/
0..1
+extendedStateMachine
[redefinedElement]
Figure 19-3. State Machine Redefinitions
ConnectionPoint
A connection point represents either a definition (as part of a statemachine) or a usage (as part of a submachine state)
of an entry/exit point.
Description
Connection points of a submachine state can be used as sources/targets of transitions. They represent entries into or
exits out of the submachine StateMachine of the submachine state.
Associations
definition: ConnectionPoint[0..1]The defined connection point for this usage connection point. A connection
point definition has no definition connection point.
entry: Pseudostate[1..*]
The entry kind pseudo states corresponding to this connection point.
exit: FinalState[1..*]
The exit points (named final state) corresponding to this connection point.
Constraints
[1] The entry Pseudostates must be Pseudostates with kind entryPoint.
[2] The exit FinalStates must be named.
357
Event (extended)
Semantics
Connection points are sources/targets of transitions implying exits out of/entries into the submachine statemachine of
a submachine state.
An entry point connection point as the target of a transition implies that the target of the transition is the entry
point as defined in the submachine of the submachine state. As a result, the regions of the submachine statemachine
are entered at the corresponding entry pseudo states.
An exit point connection point as the source of a transition implies that the source of the transition is the exit
point as defined in the submachine of the submachine state that has the exit point connection point defined. When all
regions of the submachine statemachine has reached the corresponding exit points (named final states) the submachine state exits at this exit point.
Notation
An entry point within a statemachine is a named initial pseudostate, in which case it is the source of a transition.
Optionally the statemachine frame may have a initial pseudostate symbol with the name of the entry point attached.
activeEntry
Figure 19-4. Entry Point

An exit point within a statemachine is a named final state. Optionally the statemachine frame may have a named
final state symbol with the name of the exit point attached.
aborted
Figure 19-5. Exit Point
Event (extended)
Even is defined as a specialization of the general Event, adding an association to a Port.
Associations
port: Port[*]
Specifies the ports from which the event may have been received.
Semantics
Specifying one or more ports for a trigger event implies that the event triggers a transition only if the event was
received via one of the ports of the trigger.
Notation
The ports of an event has a notation in terms of acomma-separated list of the names of the ports, headed by the
keyword via, associated with the event signature:
event-signature [via-ports] [[ guard-constraint ] ] / procedure-expression
358
FinalState
where via-ports obeys the following syntax:

via ( comma-separated-port-list )
FinalState
A special kind of state signifying that the enclosing region is completed. If the enclosing region is contained in a state
machine and all other regions in the state machine also are completed, then it means that the entire state machine is
completed.
An exit connection point is a final state, where the name is the same as the corresponding exit point defined for
the statemachine.
A final state cannot have any outgoing transitions.
Constraints
[1] A final state cannot have any outgoing transitions
self.outgoing->size() = 0
Semantics
When the final state is entered, its containing region is completed, which means that it satisfies the completion
condition. If the region is contained in a non-orthogonal composite state, this also implies that the composite state
is completed. If the region is one of several regions in an orthogonal composite state, then this state is considered
completed when all contained regions are completed. If the region is contained in a state machine and all other
regions in the state machine also are completed, the entire state machine terminates, implying the termination of the
context object of the state machine.
If the final state is a named final state (an exit point), then entering the final state implies the execution of the
transition that has this exit point as source in the statemachine enclosing the submachinestate with the corresponding
exit connection point.
Notation
A final state is shown as a circle surrounding a small solid filled circle (see Figure 19-6. on page 359). It represents
the completion of activity in the enclosing state and it triggers a transition on the enclosing state labeled by the
implicit activity completion event (usually displayed as an unlabeled transition), if such a transition is defined.
Figure 19-6. Final State

Example
Figure 19-22. on page 372 has an example of a final state (the rightmost of the states within the composite state).
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 orthogonal target states.
359
PseudoState
Attributes
kind: PseudoStateKind
Determines the precise type of the PseudoState and can be one of: entryPoint,
initial, deepHistory, shallowHistory, join, fork, junction, terminate or choice.
Constraints
[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 an orthogonal 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.isOrthogonal)
[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 orthogonal 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.isOrthogonal)
[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))
[9] Pseudostates of kind entryPoint can only be defined in the topmost regions of a StateMachine.
Semantics
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 region. The initial transition may have an action.
deepHistory is used as a shorthand notation that represents the most recent active configuration of the composite
state that directly contains this pseudostate; e.g. the state configuration that was active when the composite state
was last exited. A composite state can have at most one deep history vertex. At most one 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. Eventual entry actions are performed as part of entering via a deep history.
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. At most one transition may originate from the history connector to the initial shallow history state. This
360
PseudoState
transition is taken in case the composite state had never been active before. Eventual entry actions are performed
as part of entering via a shallow history.
join vertices serve to merge several transitions emanating from source vertices in different orthogonal regions.
The transitions entering a join vertex cannot have guards on their triggers.
fork vertices serve to split an incoming transition into two or more transitions terminating on orthogonal target
vertices (i.e. vertices in different regions of a composite state). The segments outgoing from a fork vertex must
not have guards on their triggers.
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).
choice vertices which, when reached, result in the dynamic evaluation of the guards of the triggers 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).
An entry point pseudostate is an entry point of a composite state represented by a StateMachine. In each region
of the statemachine it has a single transition to a state vertex within the same region.
Entering a terminate pseudostate implies that the execution of this statemachine by means of its context object is
terminated.
Notation
An initial pseudostate is shown as a small solid filled circle (see Figure 19-7). In a region of a classifierBehavior state
machine, the transition from an initial pseudostate may be labeled with the event that creates the object; otherwise, it
must be unlabeled. If it is unlabeled, it represents any transition from the enclosing state.
Figure 19-7. Initial Pseudo State

A shallowHistory is indicated by a small circle containing an H (see Figure ). It applies to the state region that
directly contains it.
Figure 19-8. Shallow History
361
PseudoState
A deepHistory is indicated by a small circle containing an H* (see Figure 19-9). It applies to the state region that
directly contains it.
H*
Figure 19-9. Deep History
An entry point is shown as a small solid filled circle with the name associated with it (see Figure 19-10)
activeEntry
Figure 19-10. Entry Point
A junction is represented by a small black circle (see Figure 19-11).
State0
State1
e2[b < 0]
e1[b < 0]
[a > 7]
[a < 0]
[a = 5]
State2
State3
State4
Figure 19-11. Junction

A choice pseudostate is shown as a diamond-shaped symbol as exemplified by Figure 19-12. on page 363.
362
PseudoState
[Id>10]
[Id<=10]
Figure 19-12. Choice Pseudo State

A terminate pseudostate is shown as an x, see Figure 19-13.
Figure 19-13. Terminate node

The notation for a fork and join includes a short heavy bar (Figure 19-14). The bar may have one or more arrows from
source states to the bar (when representing a joint) The bar may have one or more arrows from the bar to states (when
representing a fork). A transition string may be shown near the bar. Individual arrows do not have their own transition
strings.
Process
A1
A2
Setup
Cleanup
B1
B2
Figure 19-14. Fork and Join

If all guards associated with triggers of transitions leaving a choice PseudoState are binary expressions that share a
common left operand, then the notation for choice PseudoState may be simplified. The left operand may be placed
inside the diamond-shaped symbol and the rest of the Guard expressions placed on the outgoing transitions. This is
exemplified in Figure 19-15. on page 364.
363
PseudoStateKind
Id
[>10]
[<=10]
Figure 19-15. Alternative Notation for Choice Pseudostate.

As a presentation option, the special case with a number of states joining a junction with trigger-free and effect-free
transitions may be presented as a state symbol with a list of the state names and with an outgoing transition corresponding to the transition from the junction. The special case of the transition from the junction having a history as
target may optionally be presented as the target being the state list state symbol. See Figure 19-16 and Figure 19-17
for examples.
s1, s2
e
f
s3
Figure 19-16. State List Option
VerifyC ard ,
R ele as eC a rd
logC ard
Ve rifyC ard ,
VerifyTrans a ction
log Verify
Figure 19-17. State Lists

Entry point Pseudostates have been introduced.
The semantics of deepHistory has been aligned with ShallowHistory in that the containing state does not have to
be exited in order for deepHistory to be defined. The implication of this is that deepHistory (as is the case for
shallowHistory) can be the target of transitions also within the containing state and not only from states outside.
The state list presentation option is an extension to UML1.x.
PseudoStateKind
PseudoStateKind kind is an enumeration type.
Description
PseudoStateKind is an enumeration of the following literal values:
initial
364
deepHistory
shallowHistory
join
fork
junction
choice
entry point
Region

Entry point and terminate has been added.
Region
A region is an orthogonal part of either a composite state or a statemachine. It contains states and transitions.
Associations
transition:Transition[*]
The set of transitions owned by the state machine region. Note that internal transitions are owned by a region, but applies to the source state.
subvertex: StateVertex[*]
The set of state vertices that are owned by this state machine region.
extendedRegion: Region[0..1] The region of which this region is an extension.
Constraints
[1] A region can have at most one initial vertex
self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->
select(p : Pseudostate | p.kind = #initial)->size <= 1
[2] A region can have at most one deep history vertex

select(p : Pseudostate | p.kind = #deepHistory)->size <= 1
[3] A region can have at most one shallow history vertex

self.subvertex->select(v | v.oclIsKindOf(Pseudostate))->
select(p : Pseudostate | p.kind = #shallowHistory)->size <= 1
[4] A region may have both shallow and deep history.

Semantics
The semantics of regions is tightly coupled with states or state machines having regions, and it is therefore defined as
part of the semantics for state and state machine.
Notation
A composite state or statemachine with regions is shown by tiling the graph region of the state/statemachine
using dashed lines to divide it into regions. Each region may have an optional name and contains the nested disjoint
365
State
states and the transition between these. The text compartments of the entire state are separated from the orthogonal
regions by a solid line.
Figure 19-18. Notation for composite state/statemachine with regions

A composite state or statemachine with just one region is shown by showing a nested state diagram within the graph
region.
When a composite state or statemachine is extended, each inherited region may be extended, and regions may be
added. In order to indicate that an inherited region is extended, the keyword extended is associated with the name
of the region.
State
Description
A state is an 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).
The following kinds of states are distinguished:
Simple state,
composite state, and
submachine state.
A composite state is either a simple composite state (with just one region) or an orthogonal state (with more than one
region).
Simple state
A simple state is a state that does not have substates, i.e. it has no regions and it has no submachine statemachine.
Composite state
A composite state either contains one region or is decomposed into two or more orthogonal regions. Each region has
a set of mutually exclusive disjoint substates and a set of transition. A given state may only be decomposed in one of
these two ways. Any substate of a composite state can in turn be a composite state of either kind.
Any state enclosed within a region of 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.
Each region of a composite state may have an initial pseudostate and a final state. A transition to the enclosing
state represents a transition to the initial pseudostate. A newly-created object takes its topmost default transitions,
originating from the topmost initial pseudostates of each region.
366
State
A transition to a final state represents the completion of activity in the enclosing region. Completion of activity in all
orthogonal regions represents completion of activity by the enclosing state and triggers a completion event on the
enclosing state. Completion of the topmost regions of an object corresponds to its termination.
Submachine state
A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that
contains the submachine state is called the containing state machine. The same state machine may be a submachine
more than once in the context of a single containing state machine.
A submachine state is semantically equivalent to a composite state. The regions of the submachine statemachine
are the regions of the composite state. The entry, exit and activity actions, and internal transitions, are defined as part
of the state. However, submachine state is a decomposition mechanism that allows factoring of common behaviors
and their reuse.
Transitions in the containing state machine can have entry/exit points of the inserted state machine as destinations/sources.
Attributes
/isSimple
A state with isSimple=true is said to be a simple state. A simple state does not
have any regions and it does not refer to any submachine statemachine.
/isComposite
A state with isComposite=true is said to be a composite state. A composite state

is a state that contains at least one region.
/isOrthogonal: Boolean
A state with isOrthogonal=true is said to be an orthogonal composite state. An

orthogonal composite state contains two or more regions.
/isSubmachineState
A state with isSubmachineState=true is said to be a submachine state. Such a

state refers to a statemachine (submachine).
Associations
deferrableEvent: Event
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). A deferred event is retained
until the statemachine reaches a state configuration where it is no longer
deferred.
entry: Procedure[0..1]
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: Procedure[0..1]
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: Procedure[0..1]
An optional procedure 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.
redefinedState: State[0..1]
The state of which this state is a redefinition.
submachine: StateMachine[0..1]The state machine that is to be inserted in place of the (submachine) state.
connection: ConnectionPoint The entry and exit points used in conjunction with this (submachine) state, i.e. as
targets and sources, respectively, in the region with the submachine state.
367
State
Constraints
[1] A composite state can have at most one initial vertex
select(p : Pseudostate | p.kind = #initial)->size <= 1
[2] A composite state can have at most one deep history vertex
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 regions in an orthogonal composite state

(self.isOrthogonal) implies
(self.region->size >= 2)
[5] The connection ConnectionPoints used as destinations/sources of transitions associated with a submachine state
must be defined as entry/exit points in the submachine StateMachine.
[6] A state is not allowed to have both a submachine and regions.
not ( self.isSubmachineState and self.isComposite )
Semantics
States in general
The following applies to states in general. Special semantics applies to composite states and submachine states.
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 procedure before any other action is executed. Conversely, whenever
a state is exited, it executes its exit procedure as the final step prior to leaving the state.
If defined, the activity associated with a state is forked as a orthogonal activity at the instant when the entry procedure of the state is completed. Upon exit, the activity is terminated before the exit procedure is executed.
Activity in state (do-activity)
The activity represents the execution of a procedure, that occurs while the state machine is in the corresponding state.
The activity starts executing upon entering the state, following the entry procedure. 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 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.
State redefinition
A state of an extended state may in the extension state be redefined, provided that the value of isFinal is False. A
simple state can be extended to become a composite state (by adding a region) and a composite state can be extended
368
State
by adding regions and by adding states, entry/exit/do procedures (if the general state has none), and transitions to
inherited regions.
Composite state
Active state configurations
In a hierarchical state machine more than one state can be active at the same time. 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 the statemachine as a whole and some of the composite states in this
hierarchy may be orthogonal (i.e. containing regions), the current active state is actually represented by a set of tree
of states starting with the top-most states of the root regions 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 orthogonal, exactly one of its substates is active.
If the composite state is active and orthogonal, all of its regions are active, one substate in each region.
Entering a non-orthogonal 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 trigger of 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 procedure of the state is executed before the procedure associated with the initial transition.
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 orthogonal composite state

Whenever a orthogonal composite state is entered, each one of its orthogonal 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-orthogonal state
When exiting from a composite state, the active substate is exited recursively. This means that the exit procedures are
executed in sequence starting with the innermost active state in the current state configuration.
Exiting a orthogonal state
When exiting from a orthogonal state, each of its regions is exited. After that, the exit procedures of the regions are
executed.
Deferred events
369
State
Composite states introduce potential event deferral conflicts. Each of the substates may defer or consume an event,
potentially conflicting with the composite state, e.g. a substate defers an event while the composite state consumes it,
or vice versa. In case of a composite orthogonal state, substates of orthogonal regions may also introduce deferral
conflicts. The conflict resolution follows the triggering priorities, where nested states override enclosing states. In
case of a conflict between states in different orthogonal regions, a consumer state overrides a deferring state.
Submachine state
A submachine state is semantically equivalent to the composite state defined by the referenced statemachine.
Entering and leaving this composite state is, in contrast to an ordinary composite state, via entry and exit points.
A submachine composite state machine can be entered via its default (initial) pseudostate or via any of its entry
points, i.e. it may imply entering a non-orthogonal or a orthogonal composite state with regions. Entering via the initial pseudostate has the same meaning as for ordinary composite states. An entry point is equivalent with a junction
pseudostate (fork in case the composite state is orthogonal): Entering via an entry point implies that the entry procedure of the composite state is executed, eventually followed by the entry procedures of its regions, followed by the
(partial) transition(s) from the entry point to the target state(s) within the composite state. As for default initial transitions, guards associated with the triggers of these entry point transitions must evaluate to true in order for the specification not to be ill-formed.
Similarly, it can be exited as a result of reaching its final state, by a group transition that applies to all substates
in the submachine state composite state, or via any of its exit points. Exiting via a final state or by a group transition
has the same meaning as for ordinary composite states. An exit point is equivalent with a junction pseudostate (join in
case the composite state is orthogonal): Exiting via an exit point implies that first the procedure(s) of the transition(s)
with the exit point as target is executed, eventually followed by the exit procedures of regions, and finally the exit
procedure of the composite state.
Notation
States in general
A state is in general shown as a rectangle with rounded corners.
Ty ping
P asswo rd
Figure 19-19. State

Optionally, it may have an attached name tab, see Figure 19-20. The name tab is a rectangle, usually resting on
the outside of the top side of a state and it contains the name of that state. It is normally used to keep the name of a
composite state that has orthogonal regions, but may be used in other cases as well. The state in Figure 19-14. on page
363 illustrates the use of the name tab.
Typing Password
Figure 19-20. State with name tab
370
State
A state may be optionally subdivided into multiple compartments separated from each other by a horizontal line,
see Figure 19-21.
Typing Password
entry / set echo invisible
exit / set echo normal
character / handle character
help / display help
Figure 19-21. State with compartments

These compartments are as follows:
Name compartment
This compartment holds the (optional) name of the state, as a string. States without names are anonymous and
are all distinct. It is undesirable to show the same named state twice in the same diagram, as confusion may ensue,
unless control icons (page 387) are used to show a transition oriented view of the state machine. Name compartments
should not be used if a name tab is used and vice versa.
Internal actions compartment
This compartment holds a list of internal procedures or activities that are performed while the element is in the
state.
The procedure label identifies the circumstances under which the procedure specified by the procedure expression
will be invoked. The procedure expression may use any attributes and links that are in the scope of the owning entity.
For list items where the procedure expression is empty, the backslash separator is optional.
A number of procedure labels are reserved for various special purposes and, therefore, cannot be used as event
names. The following are the reserved procedure labels and their meaning:
entry
This label identifies an procedure, specified by the corresponding procedure expression, which is performed
upon entry to the state (entry procedure)
exit
This label identifies an procedure, specified by the corresponding procedure expression, that is performed upon
exit from the state (exit procedure)
do
This label identifies an ongoing activity (do activity) that is performed as long as the modeled element is in the
state or until the computation specified by the procedure expression is completed (the latter may result in a completion event being generated).
include
This label is used to identify a submachine. The procedureexpression contains the name of the submachine that is
to be invoked. Submachine states and the corresponding notation are described in Transition on page 19-383.
In all other cases, the label identifies the event that triggers the corresponding procedure expression. These events are
called internal transitions and are semantically equivalent to self transitions except that the state is not exited or reentered. This means that the corresponding exit and entry procedures are not performed. The general format for the
list item of an internal transition is:
371
State
event-name ( comma-separated-parameter-list ) [ guard-condition] / expression

Each event name may appear more than once per state if the guard conditions are different. The event parameters and
the guard conditions are optional. If the event has parameters, they can be used in the procedure expression through
the current event variable.
Composite state
An expansion of a state symbol shows its internal structure. In addition to the (optional) name and internal transition
compartments, the state may have an additional compartment that contains a nested diagram. For convenience and
appearance, the text compartments may be shrunk horizontally within the graphic region.
In some cases, it is convenient to hide the decomposition of a composite state. For example, the states inside a
composite state may be many and may simply not fit in the graphical space available for the diagram. In that case, the
composite state may be represented by a simple state graphic with a special composite icon, usually in the lower
right-hand corner (see Figure 19-23. on page 373). This icon, consisting of two horizontally placed and connected
states, is an optional visual cue that the state has a decomposition that is not shown in this particular statechart diagram. Instead, the contents of the composite state are shown in a separate diagram. Note that the hiding here is
purely a matter of graphical convenience and has no semantic significance in terms of access restrictions.
Examples
Dialing
Start
digit(n)
entry/ start dial tone

exit/ stop dial tone
Partial Dial
[number.isValid()]
entry/number.append(n)
digit(n)
Figure 19-22. Composite state with initial state, two states and a final state
372
State
HiddenComposite
entry / start dial tone
exit / start dial tone
Figure 19-23. Composite State with hidden decomposition indicator icon
Taking Class
Studying
Lab1
lab done
Lab2
Term Project
project done
Final Test
pass
lab done
fail
Failed
Passed
Figure 19-24. Orthogonal state with regions
Submachine state
The submachine state is depicted as a normal state with the appropriate include declaration within its internal transitions compartment (see Figure 19-25). The expression following the include reserved word is the name of the referenced state machine.
The submachine state symbol may contain the usage of one or more entry points and of one or more exit points.
The notation for these are labeled initial state/final symbols, respectively. The labels represent the names of the corresponding entry/exit points defined within the referenced state machine.
If the substatemachine is entered through its default initial pseudostate or if it is exited as a result of the completion of the submachine, it is not necessary to use the entry/exit point notation. Similarly, an exit point is not required
if the exit occurs through an explicit group transition that emanates from the boundary of the submachine state
(implying that it applies to all the substates of the submachine).
373
State
Submachine states invoking the same submachine may occur multiple times in the same state diagram with the
entry and exit points being part of different transitions.
Examples
The diagram in Figure 19-25 shows a fragment from a statechart diagram in which a sub state machine (the FailureSubmachine) is referenced. The actual sub state machine is defined in some enclosing or imported name space.
Note that the same state machine can be referenced elsewhere in the same statechart diagram with different entry
and exit configurations.
Handle Failure
include / FailureSubmachine
error1/
sub1
error3/
subEnd
/fixed1
Figure 19-25. Submachine State

In the above example, the transition triggered by event error1 will terminate on entry point sub1 of the FailureSubmachine state machine. The error3 transition implies taking of the default transition of the FailureSubmachine.
The transition emanating from the subEnd exit point of the submachine will execute the fixed1 procedure in
addition to what is executed within the HandleFailure statemachine. This transition must have been triggered within
the HandleFailure StateMachine. Finally, the transition emanating from the edge of the submachine state is taken as a
result of the completion event generated when the FailureSubmachine reaches its final state.
374
State
Figure 19-26 is an example of a state machine defined with two exit points. Optionally the entry and exit points
may also be shown on the frame, and not only withing the state graph.
ReadAmountSM
abort
selectAmount
otherAmount
amount
enterAmount
abort
aborted
ok
Figure 19-26. StateMachine with exit point definition

In Figure 19-27 this state machine is referenced in a submachine state, and the presentation option with the exit points
on the state symbol is shown.
ATM
VerifyCard
acceptCard
ReadAmount
OutOfService
aborted
outOfService include /ReadAmountSM
VerifyTransaction
releaseCard
ReleaseCard
Figure 19-27. SubmachineState with usage of exit point
375
StateMachine
Rationale
Submachine states with usages of entry and exit points defined in the corresponding statemachine has been introduced in order for statemachines with submachines to scale and in order to provide encapsulation.
StateMachine
State machines can be used to express the behavior of part of a system. 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
events. During this traversal, the state machine executes a series of procedures associated with various elements of
the state machine.
Description
A state machine owns one or more regions, which in turn own states and transitions.
The association to either a Classifier or a BehavioralFeature provides the context of the state machine. The classifier context model element defines which signal and call events are defined for the state machine, and which
attributes and operations are available in procedures of the state machine. Signal events and call events for the statemachine are defined according to the receptions and operations of this classifier. The event queue for the statemachine is associated with an instance of this classifier.
As a kind of behavior, a statemachine may have an associated behavioral feature (specification) and be the
method of this behavioral feature. In this case the statemachine specifies the behavior of this behavioral feature. The
parameters of the statemachine in this case match the parameters of the behavioral feature and provides the means for
accessing (within the statemachine) the behavioral feature parameters. The statemachine cannot in this case have
entry/exit points apart from those corresponding to the initial and final states. The event queue for the statemachine is
the event queue of the instance according to the classifier owning the behavioral feature.
Attributes
None.
Associations
region: Region[1..*]
The regions of the statemachine.
connectionPoint: ConnectionPoint[*]
The connection points defined for this state machine. They represent the interface
of the statemachine when used as part of submachine state.
extendedStateMachine: StateMachine[*]
The statemachines of which this is an extension.
Constraints
[1] The classifier context of a state machine cannot be an interface
[2] The context classifier of the method statemachine of a behavioral feature must be the classifier that owns the
behavioral feature.
[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
376
StateMachine
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)
Semantics
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 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 procedures (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 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 orthogonal regions it is possible to fire multiple transitions as a result of the same event as
many as one transition in each region 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.
Each orthogonal region in the active state configuration that is not decomposed into orthogonal 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 is fully consumed, and the run-to-completion step is completed.
During a transition, a number of actions may be executed. If such an action is a synchronous operation invocation on an object executing a statemachine, then the transition step is not completed until the invoked object complete
its run-to-completion step.
377
StateMachine
Run-to-completion and concurrency

It is possible to define state machine semantics by allowing the run-to-completion steps to be applied orthogonally 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 steps taken by orthogonal 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.
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. 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
378
StateMachine
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.
StateMachine extension
A statemachine is generalizable. A special statemachine is an extension of the general statemachine, in that
regions, states and transitions may be added, regions and states may be extended (simple states to composite states
and composite states by adding states and transitions), and transitions can be redefined.
As part of a classifier generalization, the classifierBehavior statemachine of the general classifier and the method
statemachines of behavioral features of the general classifier can be redefined (by other statemachines). These statemachines may be specializations (extensions) of the corresponding statemachines of the general classifier or of its
behavioral features.
An extension state machine will have all the elements of the extended state machine, and it may have additional
elements. Regions may be added. States and transitions of the regions of the statemachine being extended may be
redefined.
States and transitions of each region of the extended statemachine can be redefined as part of a state machine
extension.
A simple state can be extended to a composite state.
A composite state can be extended by either extending inherited regions or by adding regions. A region is
extended by adding states and transitions and by redefining states and transitions.
A submachine state may in the redefinition statemachine be redefined. The submachine statemachine may be
replaced by another submachine statemachine, provided that it has the same entry/exit points as the redefined submachine statemachine, but it may add entry/exit points and it may replace the submachine statemachine with another
statemachine.
The redefinition of a state applies to the whole state machine, e.g. if a state group as part of the extended state
machine includes a state that is redefined, then the state group for the extension state machine includes the redefined
state.
Transitions can have their content and target state replaced, while the source state and trigger is preserved. In
case of multiple general classifiers, extension implies that the extension statemachine gets orthogonal regions for
each of the statemachines of the general classifiers in addition to the one of the specific classifier.
Notation
A statechart diagram is a graph that represents a state machine. States and various other types of vertices (pseudostates) in the state machine graph are rendered by appropriate state and pseudostate symbols, while transitions are
generally rendered by directed arcs that connect them or by control icons representing the actions of the procedure on
the transition (page 387).
The association between a state machine and its context classifier or behavioral feature does not have a special
notation.
A state machine that is an extension of the statemachine in a general classifier will have the keyword extended
associated with the name of the statemachine.
The default notation for classifier is used for denoting statemachines. The keyword is statemachine.
Presentation options
Inherited states may be drawn in two different ways: with dashed lines or with gray-toned lines.
379
StateMachine
Examples
Figure 19-28 is an example statechart diagram for a the state machine for simple telephone object. In addition to
activeEntry
Active
Time-out
do/ play message
dial digit(n)
[incomplete]
after (15 sec.)

after (15 sec.)
DialTone
dial digit(n)
do/ play dial tone
lift
receiver
/get dial tone
Dialing
dial digit(n)[invalid]
dial digit(n)[valid]
/connect
Invalid
do/ play message
Idle
busy
Pinned
caller
hangs up
/disconnect
callee
answers
Connecting
connected
Busy
callee
hangs up
do/ play busy

tone
Ringing
Talking
callee answers
/enable speech
abort
do/ play ringing

tone
terminate
aborted
Figure 19-28. Statemachine Diagram representing a StateMachine

the initial state, the state machine has an entry point called ActiveEntry, and in addition to the final state, it has an
exit point called aborted.
As an example statemachine specialization, the states VerifyCard, outOfService and VerifyTransaction in the
ATM statemachine in Figure 19-29 have been specified as {final}, which means that they can not redefined (i.e.
extended) in specializations of ATM. The other states can be redefined. The (VerifyCard,acceptCard) and (verifyTransaction,releaseCard) transitions have also been specified as {final}, meaning that the procedures and the target
states cannot be replaced.
380
StateMachine
ATM
VerifyCard
{final}
acceptCard
ReadAmount
s elect Amount
OutOfService
{final}
outOfService
amount
VerifyTransact ion
{final}
releaseCard
{final}
ReleaseCard
Figure 19-29. A general state machine

In Figure 19-30 a specialized ATM (in being the statemachine of a class being a specialization of the class with the
ATM of Figure 19-29) is defined by extending the composite state by adding a state and a transition, so that users can
enter the desired amount. In addition a transition is added from an inherited state to the newly introduced state.
Both presentation options for inherited states are shown.
381
StateVertex
A TM
{ex t ended}
ReadA m ount
S elec tA m ount
{ex tended}
otherA m ount
E nterA m ount
ok
rejec tTrans ac tion
V erify Trans ac tion
Figure 19-30. An extended statemachine

Rationale
The rationale for statemachie extension is that it shall be possible to define the redefined behavior of a special classifier as an extension of the behavior of the general classifier.
The association ownedStateMachine is introduced in order for StateMachines to have locally defined StateMachines that can be referenced from SubmachineStates.
Statemachine extension is an extension of 1.x.
Rationale
State machines are used for the definition of behavior for e.g. classes that are generalizable. As part of the specialization of a class it is desirable also the specialize the behavior definition.
This is an extension to 1.x. In 1.x state machine generalization is only described through a note.
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.
382
Transition
Associations
outgoing: Transition[1..*]
Specifies the transitions departing from the vertex.
incoming: Transition[1..*]
Specifies the transitions entering the vertex.
container: CompositeState[0..1]
The composite state that contains this state vertex.
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.
Description
Associations
trigger: Event[0..1]
Specifies the event that fires the transition.
guard: Constraint[0..1]
A guard is a constraint that provides a fine-grained control over the firing of the
transition. The guard is evaluated when an event is dispatched by the state
machine. If the guard is true at that time, the transition may be enabled, otherwise, it is disabled. Guards should be pure expressions without side effects.
Guard expressions with side effects are ill formed.
effect: Procedure[0..1]
Specifies an optional procedure to be performed when the transition fires.
source: StateVertex
Designates the originating state vertex (state or pseudostate) of the transition.
target: StateVertex
Designates the target state vertex that is reached when the transition is taken.
replacedTransition: Transition[0..1]The transition of which this is a replacement.
isInternal: Boolean
isInternal=true implies that the transition, if triggered, occur without exiting or

entering the source state. Thus, it does not cause a state change. This means that
the entry or exit condition of the source state will not be invoked. An internal
transition can be taken even if the state machine is in one or more regions nested
within this state.
Constraints
[1] A fork segment should not have guards or triggers.
(self.source.oclIsKindOf(Pseudostate)

((self.source.oclAsType(Pseudostate).kind = #fork) implies
((self.guard->isEmpty) and (self.trigger->isEmpty)))
[2] A join segment should not have guards or triggers.

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

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.
383
Transition
(self.stateMachine->notEmpty

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 (region of a statemachine) 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))
Note: [6] OCL above should be changed to reflect topmost region

Semantics
High-level transitions
Transitions originating from composite states themselves are called high-level or group transitions. If triggered, they
result in exiting of all the substates of the composite state executing their exit procedures 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
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 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.
384
Transition
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
transitions and entry procedures and activities in the currently active state are completed, a completion event 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 orthogonal composite state will be taken automatically as soon as all the orthogonal 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 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 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, 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.
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 orthogonal 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 orthogonal state, the main source and main target are the orthogonal state
itself. The reason is that if a orthogonal region is exited, it forces exit of the entire orthogonal state.
385
Transition
Example:
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.
Note that a transition from one region to another in the same immediate enclosing composite state is not allowed: the
two regions must be part of two different composite states. Here least common ancestor of t is s, the main source is s
and the main target is s, since s is a orthogonal 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.
Procedures are executed in sequence following their linear order along the segments of the transition: The closer
the procedure to the source state, the earlier it is executed.
If a choice point is encountered, the guards following that choice point are evaluated dynamically and a path
whose guards are true is selected.
The main target state is properly entered.
Transition Replacement
A transition of an extended statemachine may in the statemachine extension be redefined by replacement, provided
that the value of isFinal is False. A replacement transition replaces all properties of the corresponding replaced transition in the extended statemachine, except the source state and the trigger.
Transitions are identified by the (source state, trigger) pair. Only transitions that can be uniquely defined by this
pair can be redefined. This excludes transitions with the same source, same trigger but different guards from being
redefined.
Notation
A transition is shown as a solid line originating from the source state vertex and terminated by an arrow on the target
state vertex. It may be labeled by a transition string that has the following general format:
event-signature [[ guard-constraint ] ] / procedure-expression
The event-signature describes an event with its arguments:
event-name ( comma-separated-parameter-list )
The guard-constraint is a Boolean expression written in terms of parameters of the triggering event and attributes and
links of the object that owns the state machine. The guard constraint may also involve tests of orthogonal states of the
current state machine, or explicitly designated states of some reachable object (for example, in State1 or not in
State2). State names may be fully qualified by the nested states and regions that contain them, yielding pathnames of
the form (RegionOrState1::RegionOrState2::State3. This may be used in case the same state name occurs in different composite state regions.
The procedure-expression is executed if and when the transition fires. It may be written in terms of operations,
attributes, and links of the owning object and the parameters of the triggering event, or any other features visible in
its scope. The corresponding procedure must be executed entirely before any other procedures are considered. This
model of execution is referred to as run-to-completion semantics. The procedure expression may be an action
sequence comprising a number of distinct actions including actions that explicitly generate events, such as sending
signals or invoking operations. The details of this expression are dependent on the action language chosen for the
model.
Note: The above has been copied from 1.4 and needs to be reviewed.
Internal transitions are specified in a special compartment of the source state, see Figure 19-21. on page 371.
386
Transition
The following icons provide explicit symbols for certain kinds of information that can be specified on transitions.
The control icons are intended to provide a transition-oriented view of a statemachine as exemplified in Figure 19-31.
on page 387. These icons are not necessary for constructing statemachine diagrams, but many users prefer the added
impact that they provide.
Signal receipt
The receipt of a signal may be shown as a concave pentagon that looks like a rectangle with a triangular notch in its
side (either side). The signature of the signal is shown inside the symbol. A unlabeled transition arrow is drawn from
the source state to the pentagon and another unlabeled transition arrow is drawn from the pentagon to the target state.
Signal sending
The sending of a signal may be shown as a convex pentagon that looks like a rectangle with a triangular point on one
side (either side). The signature of the signal is shown inside the symbol. A unlabeled transition arrow is drawn from
the source state to the pentagon and another unlabeled transition arrow is drawn from the pentagon to the target state.
Action sequence
A sequence of actions in a transition my be shown as a rectangle that contains a textual description of the actions. The
syntax used in the textual description is tool specific but must map to a sequence of Actions.
Idle
Req(Id)
[Id>10]
[Id<=10]
Minor(Id)
Major(Id)
MinorReq = Id;
MajorReq = Id;
Busy
Figure 19-31. Symbols for Signal Receipt, Sending and Actions on transition
Deferred events
A deferrable event is shown by listing it within the state followed by a slash and the special operation defer. If the
event occurs, it is saved and it recurs when the object transitions to another state, where it may be deferred again.
When the object reaches a state in which the event is not deferred, it must be accepted or lost. The indication may be
placed on a composite state or its equivalents, submachine and subactivity states, in which case it remains deferrable
throughout the composite state. A contained transition may still be triggered by a deferrable event, whereupon it is
removed from the queue.
387
Transition
Turn on
Machine
turnOn
Brew coffee
light goes out / defer
Get Cups
light goes out / defer
light goes out
Pour Coffee
Figure 19-32. Deferred Event Notation
Figure 19-33 shows an example of adding transitions in a specialized statemachine.
388
Transition
ATM
{ex tended}
ReadAmount
SelectAmount
EnterAmount
abort
abort
Releas eCard
Figure 19-33. Adding Transitions

Example
Transition, with guard constraint and transition string
right-mouse-down (location) [location in window] / object := pick-object (location);
object.highlight ()
The event may be any of the standard event types. Selecting the type depends on the syntax of the name (for time
events, for example); however, SignalEvents and CallEvents are not distinguishable by syntax and must be discriminated by their declaration elsewhere.
Transition redefinition has been added, in order to express if a transition of a general state machine can be redefined or not
Along with this, an association to the redefined transition has been added.
Guard has been replaced by a Constraint
389
Transition
390
Part III. UML::Complete

This part describes the package structure and contents of the UML::Complete package, which defines various
advanced and other optional constructs. The Complete package is one of the top-level packages that defines the
UML. The relationship of the Common package to the other top-level packages is shown in Figure 19-34.
UML
Complete
import
Common
import
Basic
import
Foundation
Figure 19-34. The Common package is owned by the UML package.
Part-Complete.fm Version 2 beta R1
391
19 UML::Complete
The Complete package, which imports the Common package, consists of the subpackages shown in Figure 1935.
Kernel
(from Foundation)
Generalizations
B as ic
(from UML)
Common
(from UML)
InformationFlows
Associations
A ctions
Models
ProtocolS tateMachines
Templates
ComponentDeployments
Activities
Figure 19-35. The contents of the Complete package.

The function and contents of these packages are described in separate chapters, corresponding to each package
392
393
19 UML::Complete
394
Chapter 20. Complete::Actions

This Complete::Actions package describes the full semantics of UML actions. The major constructs associated with
complete action semantics are outlined below.
Associations
Common
Behaviors
(from Common)
Actions
(from Common)
Actions
Figure 20-36. Dependencies of the Complete::Actions package

Composite Actions
A composite action (as extended) may have input and output pins of its own that allow data flows to be connected
directly to the composite action. Composite actions also allow data flow to cross the boundary of the composite
action and connect directly to pins on subactions within the composite action. 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.
Read Write Actions
Additional actions deal with the relation between object and class. These read the instances of a given classifier,
check which classifier an instance is classified by, and change the classifier of an instance. (see Figure 20-37). Link
object actions operate on instances of association classes (see Figure 20-41 and Figure 20-40). The semantics of
actions that read and write associations that have a static end is undefined. Also LinkEndData is extended to support qualifiers (see Figure 20-39).
Collection Actions
Collection actions are control constructs that apply a subaction repeatedly to the elements of a collection, 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. A collection may be ordered or unordered. During the execution of a collection action, multiple executions of the subaction may occur, either concurrently or sequentially, but
from the outside the execution of the collection action appears as a single unit. For some of the collection actions, the
result is another collection of the same kind as the input collection; for others, the results are scalar values that are
accumulated across the entire input collection.
The filter action applies a test subaction to each of the elements of a collection to produce a collection containing
a subset of the original elements. The subaction returns a Boolean value. If the Boolean value is true, the element is
included in the output collection; if the Boolean value is false, the element is excluded from the output collection. An
example is a subaction that determines whether an account has a negative balance, resulting in the collection of
accounts with negative balances. The iterate action applies a subaction repeatedly to each of the elements in a collection in sequence, accumulating the effects in loop variables. At execution of the subaction may affect subsequent
3-395
20 Complete::Actions
executions. An example is paying creditor accounts in order of precedence until funds are exhausted. 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. The reduce action repeatedly applies a subaction
to pairs of adjacent elements in a collection, replacing a pair of elements by the result, until a single value remains.
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., such as summing up balances of all accounts.
A number of elements, all of the same type, comprise a collection. The element type is the type of the collections
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 has more than one collection as input, they
must all have the same size. Multiple output collections produced by the same collection action must have the same
size as each other.
If an collection action has multiple input collections, these are conceptually equivalent to a single collection of
tuples, where each position of the tuple is drawn from one of the collections. A slice is a tuple containing one element, at the same position, from each collection. Each subaction has a single pin for position in the tuple. That is, the
input and output pins to collection actions hold collections while the pins to the subactions hold the corresponding
element values.
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 shape.) The constraint {ordered congruent collection} indicates that the set of collections must be ordered and that each of the collections must have the same shape as the others (unordered, ordered, or
possibly additional choices in a profile).
Subactions may have other scalar inputs from outside the collection action. Such inputs will be the same value
for all the subaction executions during one execution of a collection action. In other words, even those such inputs
might change from execution to execution of the overall collection action, they are fixed during any one execution of
the collection action. Subaction outputs are never available outside the collection action.
3-396
CompositeAction
Cl ause
(from Actions)
(from Acti ons)
GroupA ction
Cond it ion alAct ion
LoopAction
(from Acti ons)
(from Acti ons)
(from Acti ons)
Clause
*
+bodyOutput
ValueDenot ation
(from CommonBeh avi or)
+bodyOutput
Loo pActi on
ConditionalAction
GroupA ction
0..1
mustIsolate : Boolean
0..1
0..1
{ordered}
+result
[output]
0..1
{ordered}
+result
[out put]
+loop
{ordered} *
Input Pin
+loop Va riable Input

[ in put]
(from Acti ons)
{ordered}
+loopVariable
[ownedElement]
Output Pin
Output Pin
(from Acti ons)
(from Actions)
Figure 20-37. The metaclasses declared in the Composite Actions package.
InputPin
InputPin
Input Pin
(from Acti ons)
(from Acti ons)
(from Acti ons)
+input
[input]
+inp ut
[input]
+input
[input]
PrimitiveAction
(from Acti ons)
0..1
ReadExtentAction
0..1
+resul t
[output]
Re class ifyObje ctA ct ion

isReplaceAll : Boolean [1..1] = false
0..1
+oldClassifier
1
Output Pin
(from Actions)
0..1
Classifier
+clas sifier
(f rom Kernel )
ReadIsClassifiedObjectAction
0..1
StartObjectSt ateMach ineA ction
isDirect : Boolean [1..1] = false

0..1
+newClassifier
+result
[output]
1
+classifier
OutputPin
(from Acti ons)
Figure 20-38. Complete read-write actions.
3-397
LinkEndData
(f rom Ac ti on s)
LinkEndData
Associati onEnd
[end]
(from Associati ons)
+qualifier
Input Pin
0.. 1
*
QualifierValue
(from Acti ons)
+qualifier
+value
Attribute
(from Associ ati ons)
Figure 20-39. Link identification
Creat eLinkAction
(from Actions)
CreateLinkObjectAction
0..1
1
+result
[output]
OutputPin
(from Acti ons)
Figure 20-40. Creating link objects
3-398
PrimitiveAction
(from Actions)
InputPin
(f ro m Ac ti ons)
+object
[ input]
+object
[input]
1
1
0..1
0.. 1
ReadL inkObject EndA ction
0..1
ReadLinkObjectQualifierAction
0..1
(f rom Ac ti on s)
0..1
+result
[output]
Out putPin
+end
0.. 1
1
+result
[output]
+qualifier
AssociationEnd
At tribute
(from Kernel )
(f rom Asso ciati on s)
Figure 20-41. Read link object actions
3-399
+subaction
[ownedElement]
Action
(from Acti ons)
CollectionAct ion
MapAction
FilterAction
It erat eAction
ReduceActi on
isUnordered : Boolean
Figure 0-55 Collection actions
.:
+subinput
[ownedElement]
0..1
+argument
[input]
FilterAction
+result [output]
0..1
InputPin
(from Actions)
1..*{ordered
congruent
collection}
{ordered
congruent
collection}
0..1
*
{ordered}
1..*
OutputPin
1.. *
1 +s ubtes t
pin of the
subaction
Figure 20-42. Filter action
3-400
+loopVariableInpu t [input]
{ordered}
InputPin
(f rom Ac ti on s)
+collectionInput
[input]
0.. 1
0..1
*
+lo opVariable
{ordere d}
[ownedElem ent]
OutputPin
+result [ou tput]
0..1
IterateAction
1..* {ordered
congruent
collection}
0..1
{ordered}
0 .. 1
{ordered }
+suboutput
1..*
+subinp
pin of the
subaction
Figure 20-43. Iterate action
+argument
[input]
InputPin
1..*
{ordered
congruent
collection}
+subinput
1..*
{ordered}
0..1
+result [output]
MapAction
0.. 1
OutputPin
{ordered
*
congruent
collection} +suboutput
0..1
*
{ordered}
pin of t he
subact ion
Figure 20-44. Map action
+leftSubinput
[ownedElement]
0..1
+argum ent
[input]
Input Pin
(from Actions)
1..* {ordered
congruent
collection}
0..1
0..1
0..1
Re duceAction
+rightSubinput
[ownedElement]
{ordered}
{ordered}
1..*
1.. *
+result [output]
OutputPin
{ordered} 1 .. *
+suboutput
{ordered}
1..*
pin of the
subaction
Figure 20-45. Reduce action
3-401
Clause (extended)
Clause (extended)
Description
The outputs of a clause are an ordered subset of the outputs of the body actions. No output of the body actions may be
connected to outside the clause.
Associations
bodyOutput: ValueDenotation The ordered set of values that are considered to be output of the clause. These
may be output pins of the body actions, or they may be other denoted values.
CollectionAction
Description
This is an abstract superclass of actions that contain subactions that are executed multiple times on the elements of
one or more input collections. The rules of execution are described under each subclass.
Attributes
none
Associations
subaction: Action[1..1]
An action applied repeatedly or concurrently to the elements of the collection. Its

precise use is described under each specific action subclass.
Semantics
None specified.
Notation
None.
Examples
None
Rationale
This serves as a convenient place for the description of all the collection actions. There is not actually much to share
among the subtypes.
This metaclasses did not exist in UML 1.4. They were added in the Action Semantics specification.
3-402
ConditionalAction (extended)
Description
If a conditional action has a set of output pins, each of its clauses must designate a corresponding set of value denotations as bodyOutput; these may include output pins from its body actions. Any output pin designated as body output
must have a type and multiplicity conforming to the corresponding output pin of the conditional action. Consequentially, the conditional action will produce the same types of output values, regardless of which clause body executes.
When the body actions of the selected clause execute, then the body output values designated by the clause become
the values of the output pins of the conditional action. There is no explicit data flow from the body output of a clause
to the output pins of the 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 the body actions of one of the clauses can execute during the
execution of the conditional action, and consequentially, each output pin of the conditional action will receive only
one value.
A conditional is not required to have a default clause, but unless the conditional action has no output pins, at least
one clause must succeed, or the model is ill-formed.
The only output pins of the conditional action accessible outside the conditional action are the output pins owned
by the conditional action.
Associations
output: OutputPin
An ordered list of output pins that are the only available outputs of the conditional action. At the completion of execution of the conditional action, each
output pin is given the value of the corresponding body output of the clause
that had been executed.
Constraints
[1] The body outputs of each clause of a conditional action must agree in type, multiplicity, and ordering, if they
denote output pins.
[2] The type, multiplicity, and ordering of the output pins of a conditional action are derived from the type, multiplicity, and ordering of the corresponding body output.
Semantics
The following two steps are inserted in step [4] of the evaluation of a conditional action, as specified in Chapter 11,
Common::Actions.
[1] When the body actions have completed execution, the values on the pins designated as bodyOutput are copied to
the output pins of the conditional action.
[2] If all clauses have failed and the conditional action has one or more output pins, then the conditional action is ill
formed and the behavior of the conditional action is undefined.
CreateLinkObjectAction
CreateLinkObjectAction creates a link object.
Description
This action is exclusively for creating links of association classes. It returns the created link object.
3-403
FilterAction
Attributes
None.
Associations
result [1..1] : OutputPin [1..1] (Specialized from Action:output) Gives the output pin on which the result is put.
Constraints
[1] The association must be an association class.
self.association().oclIsKindOf(Class)
[2] The type of the result pin must be the same as the association of the action.
self.result.type = self.association()

Semantics
CreateLinkObjectAction 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.
Notation
None.
Examples
None.
Rationale
CreateLinkObjectAction is introduced to create link objects in a way that returns the link object. Compare CreateLinkAction.
CreateLinkObjectAction is new in UML 2.0.
FilterAction
Description
The input to the filter action (argument) is a list of collections, all of the same size but possibly containing different
types of values from each other. The subaction is applied concurrently to each slice of argument values. That is, a
copy of an execution of the subaction is created and the list of values at the same position in each of the argument collections is copied to the subinput pins of the subaction execution. The filter action designates a boolean output within
the subaction; on completion of execution of the subaction, the Boolean value determines whether each slice of argument values is copied to the result collections. If the Boolean value is true, each argument value is copied to the corresponding position in the result collection; if the value is false, the corresponding element position is removed from
each of the result collections and, for ordered collections, the hole is closed up.The result of the filter action is a list 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
3-404
closed up, therefore the result collections may have fewer elements than the argument collections, or even no elements. All executions of the subaction are concurrent.
In the simplest case, the subaction takes a single input value (a single element from a single argument collection
of the filter action), and produces a Boolean value on the output pin.
The filter action may also take multiple argument collections, all 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 result collections. The number of argument and result collections must therefore be the same. The type of each result collection matches the type of its corresponding argument collection, but the
different argument collections may contain values of different types. The number of elements in all the result collection will be the same, but it may be less than the number of elements in the argument collections.
The subaction may also have inputs that are not inputs to the filter action, such as a constant or value used in
every execution of the subaction. These values may be drawn from outside the filter action and they will remain the
same for each of the concurrent executions of the subaction.
The executions of the subaction occur concurrently and any presumption of execution order may produce an
unexpected result. Even if the elements of a collection are ordered, there is no assumption that the execution occurs in
the same order.
Attributes
none
Associations
An ordered list of input pins whose values are collections. These pins represent
the external inputs of the filter action. All the collections must have the same
size, but each collection may contain a different type of element. If there is more
than one collection, they must be ordered so that the element values can be
matched.
An ordered list of output pins whose values are collections. These pins represent
the external outputs of the filter action. 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. 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.
subaction: Action[1..]
An action that tests whether to include an argument slice in the result. It must
contain an output pin that yields a Boolean value (see subtest).
subinput: OutputPin [1..*]
An output pin owned by the filter action, but not accessible externally to it. The
number of pins is equal to the number of argument collections of the filter action.
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.
subtest: OutputPin [1]
An output pin owned by the subaction or an action nested within it At the completion of an execution of the subaction, this pin holds a Boolean value that determines whether the argument values at the given position are copied to the result
collections.
3-405
FilterAction
Constraints
[1] The number of argument pins, the number of subinput pins, and the number of result pins must be equal.
[2] The subtest pin must be owned by the subaction or an action nested within it.
[3] None of the output pins of the subaction or actions nested within it are accessible outside the filter action.
[4] The subinput pins are accessible within the subaction, but they are not accessible outside the filter action.
Execution Constraints
[1] The argument values must all be collections of the same size and shape, otherwise the model is ill formed and its
subsequent behavior is undefined.
[2] When a subordinate action execution completes, the designated subtest pin must hold a Boolean value.
Semantics
The filter action begins execution when all of its data and control prerequisites are satisfied. One execution of the
subaction occurs for each position in the argument collections, which must all have the same number of elements.
The execution of the subactions is concurrent. No assumptions can be made about the order of execution of the subactions. Several executions may proceed simultaneously and any access to shared writable resources may result in
unexpected behavior.
For each execution of the subaction, the element value at the given position is copied from each of the argument
collections to the corresponding subinput pin.
At the conclusion of execution of the subaction, the designated subtest pin must hold a Boolean value. If the
value is true, the element value at the given position is copied from each of the argument collections to the corresponding result collection at the given position. If the value is false, the given position of the result collections will
lack a value.
When all executions of the subaction have completed, gaps in the result collections due to false values of the subtest are eliminated by moving elements forward as necessary. The result collections each have a number of elements
equal to the number of subaction executions that produced true values.
The result collections are made available outside the filter action.
Notation
None.
Examples
None.
Rationale
Filtering a set of values to produce a subset is a common need and it cannot be expressed as a map action, because of
the need to eliminate the gaps in the output.
3-406
GroupAction (extended)
Description
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.
In order to avoid race conditions or other concurrency-related problems, it is sometimes necessary to isolate the
effects of a group of actions from the effects of actions outside the group. This may be 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.
Note: Any required isolation may be achieved using a locking mechanisms, or it may simply sequentialize
execution to avoid concurrency conflicts. Isolation is different from 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.
Attributes
mustIsolate : Boolean
If true, then the actions in the group execute in isolation.
Semantics
Note: The semantics of group actions with mustIsolate = true is currently not defined.
IterateAction
The iterate action applies an action repeatedly, once for each input slice of the input collections. A set 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. This action executes sequentially and the effects of one iteration may affect subsequent iterations.
An iterate action has two kinds of input pins: the argument collections and scalar values used to initialize the
loop variables. The iterate action has one kind of result output pins, whose number and types match the loop variable
input pins. When the execution of the iterate action is complete, the result pins hold the values produced for the loop
variables after the final execution of the subaction (or the initial values of the loop variables, if there are zero iterations).
The subinput action is executed once for each position in the collectionInputs; all of the collections must have the
same size. The iterate action owns internal OutputPins, the loopVariable pins, whose number must be equal to the
number of loop variable input pins. On the initial execution of the subaction, these pins hold copies of the values on
the loop variable input pins. The iterate action also owns other internal OutputPins, the subinput pins, whose number
must be equal to the number of collectionInput input pins. During the ith execution of the subaction, each subinput
pin holds the value of the ith element of the collection on the corresponding collectionInput pin. The iterate action
also designates internal OutputPins, the suboutput pins, owned by the subaction or an action nested within it.
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 external values are fixed during the executions of the subactions during any one execution of the overall iterate action. During each execution, the
subaction computes values for the suboutput pins. The values on the suboutput pins become the new values of the
3-407
IterateAction
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 suboutput pins designated by the iterate action, which are
available only to the iterate action itself. If an iterate action has no loop variables, its effects must be performed by
storing values in object memory.
The isUnordered attribute states that the order of execution of slices is irrelevant, even though the ordering of
elements in each collection (for ordered collections) 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 collectionInputs
are sets, then the slices are processed in an indeterminate order. If the results of the computation do in fact depend on
the order of execution of the iterations, the iterate action may produce an unpredictable and nonrepeatable result.
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 true only if the final result is insensitive to
execution order, otherwise the computation may produce nonrepeatable results.
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 effect.
Associations
collectionInput: InputPin [1..*]

A subset of the external input pins of the iterate action. Each pin holds a collection of values. All the collections must have the same shape (ordered or unordered) and number of elements, but the types of elements on 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 (unless
the isUnordered attribute is true).
loopVariable: OutputPin[0..*]
A (possibly empty) list of output pins, owned by the iterate action, whose values
accumulate the result of executing the action through preceding iterations. During the first execution of the subaction, each pin holds a copy of the corresponding loopVariableInput pin. 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.
loopVariableInput: InputPin [0..*]

A subset of the external input pins of the iterate action. The number of pins must
equal the number of loop variable pins. 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.

The external output pins of the iterate action. The number of pins must equal the
number of loop variable input pins and the number of loop variable pins. After
the execution of the subaction on the final slice of values from the input collections, the result pins receive values equal to the values of the suboutput pins on
the completion of the final execution of the subaction. If the input collections are
3-408
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:OutputPin[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 as the value of its subinput pins. 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 suboutput values in the subaction are copied to the loop variables.
After the subaction has been executed once for each slice of the input collections,
the final values of the loop variables are copied to the result output pins of the
iterate action.
A nonempty list of internal output pins owned by the iterate action whose values
represent one slice of the input collections during one execution of the subaction.
The number of subinput pins must equal the number of argument input pins. During each execution of the subaction, a different slice of values appears on the
pins. The pins are available to the subaction.
suboutput: OutputPin[0..*]
A (possibly empty) list of available output pins owned by the subaction. The
number of suboutput pins must equal the number of loopVariable pins. 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.
Constraints
[1] The number of collectionInput pins and the number of subinput pins must be the same.
[2] The number of loopVariableInput pins, the number of loopVariable pins, the number of suboutput pins, and the
number of result pins must all be the same.
[3] The loopVariable pins, the subinput pins, and the suboutput pins are not accessible outside the subaction.
[4] The output pins of the subaction are not accessible outside of it.
Execution constraints
[1] All of the values on argument input pins must be collections of the same size and shape.
Semantics
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.
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
3-409
LinkAction (extended)
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).
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.
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.
Notation
None.
Examples
None.
Rationale
An iterate action could be expressed as a LoopAction, but providing a special collection action eliminates the need to
model the details of advancing the iteration, which would be overspecified when the iteration is driven by a collection
of values. In many respects, however, IterateActon and LoopAction are similar.
LinkAction (extended)
LinkAction is an abstract primitive action class for all link actions that identify their links by the objects at the ends of
the links and by the qualifiers at ends of the links.
Description
A link action creates, destroys, or reads links, identifying a link by its end objects and qualifier values, if any.
Attributes
None.
Associations
endData : LinkEndData [2..*] Specialized for complete LinkEndData.
Constraints
[1] 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 =
if self.endData.oclIsKindOf(Actions-Complete::LinkEndData)
then self.endData->collect(value)->union(self.endData.qualifier.value)
else self.endData->collect(value) in
if self.oclIsKindOf(LinkEndCreationData)
then ledpins->union(self.endData.oclAsType(LinkEndCreationData).insertAt)
else ledpins
3-410
Semantics
Notation
Examples
None.
Rationale
LinkAction is extended for qualifiers.
LinkEndData (extended)
LinkEndData is not an action. It is part of the model that identifies links. It identifies one end of a link to be read or
written by the children of LinkAction. See LinkAction.
Description
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.
Attributes
None.
Associations
qualifier : QualifierValue [0..*] Specifies qualifier attribute/value pairs of the given end.
Constraints
[1] The qualifiers include all and only the qualifiers of the association end.
self.qualifier->collect(qualifier) = self.end.qualifier
[2] The end object input pin is not also a qualifier value input pin.
self.value->excludesAll(self.qualifier.value)
Semantics
Notation
None.
Examples
None.Rationale
LinkEndData is introduced to indicate which inputs are for which link end objects and qualifiers.
3-411
LoopAction (extended)
LoopAction (extended)
The subactions have access to the values of a set of loop variables, which are represented as a list of internal output
pins owned by the loop action.
The loop variables may be connected to input pins of the subactions, thus providing the current values of the
loop variables during a loop iteration. The loop action also designates a set of output pins of the subactions as bodyOutputs. These output pins must match in type, ordering, and multiplicity the loop variable pins. At the completion of
execution of the body actions, the values of these pins become the values of the loop variable pins for the next iteration of the loop.
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. Before the first execution of the loop clause, the values of the loop inputs become the values of the loop variable
pins.
When the loop action completes, the values of the loop variable pins become the values of the output pins of the
loop action.
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,
preserving the single-assignment principle. There are no data flows 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 output pins of the loop
action.
Description
Loop actions permit the repeated execution of a subaction depending on a repeated test, with outputs of one iteration
used as inputs for the next iteration.
A list of output pins acts as loop variables for the loop action. The loop variables are not 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. The loop variables may be connected via data flow to available inputs of subactions, to provide the old values of the loop variables during an iteration. The output pins of the subactions designated as bodyOutput provide new values that are copied to the loop variables at the completion of an iteration. The initial test is
executed after the initial values are copied to the loop variables. When the loop terminates, the final values of the loop
variables are copied to the result output pins of the loop action, which are the only available outputs for the loop
action.
Associations
loopVariableInput: InputPin
An ordered list of input pins representing 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.
result: OutputPin
An ordered list of output pins. When the execution of the loop action is complete, the result output pins have values equal to the values on the corresponding loop variable pins.
loopVariable: OutputPin
An ordered list of output pins. On each subsequent execution of the body

actions, each loop variable pin has a value equal to the value of the corresponding bodyOutput pin at the completion of the previous execution of the body
action owning that pin. The values of the loop variable pins are available inputs
to subactions of the loop action. They are not available outside the loop action.
3-412
Constraints
[1] The type, ordering, and multiplicity of the loop variable output pins is derived from the bodyOutput value denotations.
[2] The type, ordering, and multiplicity of the loop variable input pins is derived from the bodyOutput value denotations.
[3] The type, ordering, and multiplicity of the result output pins is derived from the bodyOutput value denotations.
[4] The loop variables must not be connected by data flows to actions outside the loop action.
[5] The loop variables must not be the destination of data flow.
[6] The result output pins must not be the destination of data flow.
Semantics
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 execution of the loop begins by copying the values of the loopVariableInput pins to the loop variables as their initial values. After the execution of the subactions, the values of the
bodyOutput pins are copied to the loop variables. After completion of the loop execution, the loop variables are copied to the loop outputs.
[1] (Inserted after step [1] of the loop action execution as specified in Chapter 11, Common::Actions.) The values
on the loopVariableInput pins are copied into the loop variables.
[2] (Inserted after step [4] of the loop action execution as specified in Chapter 11, Common::Actions.) The values
of the loop variables are copied to the result output pins.
[3] (Inserted after step [5] of the loop action execution as specified in Chapter 11, Common::Actions.) When the
body subactions have completed execution, the values on the bodyOutput value denotations are copied to the values of the loop variables.
MapAction
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
The ordered external input pins of the MapAction. Each pin holds a collection,
all of which must have the same number of elements. The subaction is applied to
each slice of the collections concurrently.
3-413
MapAction
The ordered external output pins of the MapAction. On completion of execution,

each pin holds a collection, all of which have the same number of elements as the
argument collections. These values are available externally to the action.
An action to be executed once for each slice of the argument collections. During
each execution of the subaction, one element value from each input collection is
copied to the corresponding subinput pin on an execution of the subaction.
subinput: OutputPin[1..*]
A list of internal output pins of the map action, equal in number to the number of
argument pins. During each execution of the subaction, a value from the same
element position of each argument collection is copied to the corresponding subinput pin. The subinput pins are available within the subaction but not outside of
it.
A list of internal output pins of the map action, equal in number to the number of
result pins. On completion of an execution of the subaction, each suboutput pin
has a value computed by the subaction. The value of each suboutput pin becomes
the value of the corresponding result pin at the position in the collection from
which the subinput values were taken from the argument collections.
Constraints
[1] The number of argument pins and the number of subinput pins must be equal.
[2] The number of suboutput pins and the number of result pins must be equal.
Runtime constraints
[1] All of the values on argument pins must be collections of the same size and shape.
Semantics
[1] When all the control and dataflow prerequisites of the map action have been satisfied, it begins execution. The
argument values must all be collections of the same size and shape, otherwise the model is ill formed and its subsequent behavior is undefined.
[2] An execution of the subaction 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 subaction execution corresponding to
the position in the collections.
[3] The subordinate action executions execute concurrently. When a subordinate action execution completes, it has
produced values on its designated suboutput pins (if any).
[4] When all of the subordinate action executions have completed, the output collections are created. Each collection
has the same size and shape (ordered or unordered) as the input collections. For each position in the argument
collections, the value of the element at that position in each result collection is copied from the value of the corresponding suboutput pin from the execution of the subaction for that position.The output collections are placed
on the output pins of the map action and its execution is complete.
Notation
None.
Examples
None.
3-414
Rationale
Applying a computation concurrently to a collection of values is one of the most common programming tasks, and its
representation as a concurrent map goes back to Lisp 1.5. If it were expressed sequentially, it would be difficult, if not
impossible, for an optimizer to extract the inherent parallelism. The map action also avoids the need to model the iteration mechanisms.
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.
Description
qualifier values, as required. This requires more than one piece of data, namely, the 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.
Attributes
None.
Associations
qualifier : Attribute [1..1]
Attribute representing the qualifier for which the value is to be specified.
Input pin from which the specified value for the qualifier is taken.
Constraints
[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.

Semantics
Notation
None.
Examples
None.
Rationale
QualifierValue is introduced to indicate which inputs are for which link end qualifiers.
3-415
ReadLinkObjectEndAction

QualifierValue is new in UML 2.0
ReadLinkObjectEndAction
ReadLinkObjectEndAction retrieves an end object from a link object.
Description
This action reads the object on an end of a link 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.
Attributes
None.
Associations
end : AssociationEnd [1..1]
Link end to be read.
(Specialized from Action:input) Gives the input pin from which the link object is
obtained.
Constraints
[1] The association of the association end must be an association class.
self.end.Association.oclIsKindOf(AssociationClass)
[2] The ends of the association must not be static.

self.end.association.end->forall(oclIsKindOf(NavigableEnd) implies isStatic = #false)
[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.

[5] The type of the result output pin is the same as the type of the association end.
self.result.type = self.end.type

Semantics
TBD.
Notation
None.
Examples
None.
Rationale
ReadLinkObjectEndAction is introduced to navigate from a link object to its end objects.
3-416

ReadLinkObjectEndAction is new in UML 2.0.
ReadLinkObjectQualifierAction
ReadLinkObjectEndAction retrieves a qualifier end value from a link object.
Description
This action reads a qualifier value on an end of a link object. The association end to retrieve the qualifier from is
given statically, and the link object to read is provided on the input pin at run time.
Attributes
None.
Associations
qualifier : Attribute [1..1]
The attribute representing the qualifier to be read.
(Specialized from Action:input) Gives the input pin from which the link object is
obtained.
Constraints
[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 not be static.

self.qualifier.associationEnd.association.end->forall(oclIsKindOf(NavigableEnd) implies isStatic = #false)
[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.

[6] The type of the result output pin is the same as the type of the qualifier attribute.
self.result.type = self.qualifier.type

Semantics
This action assumes qualifier attributes have multiplicity 1..1.
Notation
None.
Examples
None.
3-417
ReadExtentAction
Rationale
ReadLinkObjectQualifierAction is introduced to navigate from a link object to its end objects.
ReadLinkObjectQualifierAction is new in UML 2.0
ReadExtentAction
Description
ReadExtentAction is a primitive action that retrieves the current instances of a classifier.
Attributes
None.
Associations
classifier : Classifier [1..1]
The classifier whose instances are to be retrieved.
The runtime instances of the classifier.
Constraints
[1] The type of the result output pin is the classifier.
[2] The multiplicity of the result output pin is 0..*.
self.result.multiplicity.is(0,#null)
Semantics
The extent of a classifier is the set of all instances of a classifier that exist at any one time.
Semantic Variation Point
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, an execution engine typically manages only a limited subset of the total set of instances of
any classifier and may manage multiple distributed extents for any one classifier. It is not formally specified which
managed extent is actually read by a ReadExtentAction.
Notation
None.
Examples
None.
Rationale
ReadExtentAction is introduced to provide access to the runtime instances of a classifier.
ReadExtentAction has been newly introduced in UML 2.0.
3-418
ReadIsClassifiedObjectAction
ReadIsClassifiedObjectAction is a primitive action that determines whether a runtime object is classified by a given
classifier.
Description
This action tests the classification of an object against a given class. It can be restricted to testing direct instances.
Attributes
isDirect : Boolean [1..1]
Indicates whether the classifier must directly classify the input object. The
default value is false.
Associations
classifier : Classifier [1..1]
The classifier against which the classification of the input object is tested.
Holds the object whose classification is to be tested. (Specializes Action.input.)
After termination of the action, will hold the result of the test. (Specializes
Action.output.)
Constraints


[4] The type of the output pin is Boolean

self.result.type = Boolean
Semantics
The action returns true if the input object is classified by the specified classifier. It returns true if the isDirect attribute
is false and the input object is classified by the specified classifier, or by one of its (direct or indirect) descendents.
Otherwise, the action returns false.
Notation
None.
Examples
None.
Rationale
ReadisClassifiedObjectAction is introduced for run-time type identification.
ReadisClassifiedObjectAction has been newly introduced in UML 2.0.
3-419
ReclassifyObjectAction
ReclassifyObjectAction
ReclassifyObjectAction is a primitive action that changes which classifiers classify an object.
Description
ReclassifyObjectAction adds given classifier to an object and removes given classifiers from that object . Multiple
classifiers may be added and removed at a time.
Attributes
isReplaceAll : Boolean [1..1] Specifies whether existing classifiers should be removed before adding the new
classifiers. The default value is false.
Associations
Holds the object to be reclassified. (Specializes Action.input.)
newClassifier : Classifier [0..*] A set of classifiers to be add to the classifiers of the object.
oldClassifiers : Classifier [0..*]A set of classifiers to be removed from the classifiers of the object.
Constraints
[1] None of the new classifiers may be abstract.
not self.newClassifier->exists(isAbstract = true)


Semantics
After the action completes, the input object is classified by its existing classifiers and the new classifiers given to
the action; however, the old classifiers given to the actions do not any longer classify the input object. 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 an atomic step, so that attribute values and links are not lost during the reclassification, when the old and new classifiers have attributes and associations in common.
Neither adding a classifier that duplicates an already existing classifier, nor removing a classifier that is not classifying the input object, has any effect. Adding and removing the same classifiers has no effect.
If isReplaceAll is true, then the existing classifiers are removed before the new classifiers are added, except if the
new classifier already classifies the input object, in which case this classifier it is not removed. If isReplaceAll is
false, then adding an existing value has no effect.
It is an error, if any of the new classifiers is abstract or if all classifiers are removed from the input object.
Notation
None.
Examples
None.
Rationale
ReclassifyObjectAction is introduced to change the classifiers of an object.
3-420

ReclassifyObjectAction has been newly introduced in UML 2.0.
ReduceAction
The reduce action applies an associative binary subaction repeatedly to adjacent pairs of slices from the input argument collections, until the (common working) list of slices is reduced to a single slice of scalar values, which together
constitute the output result 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 conflict in
accessing shared memory values, 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 irrelevant, in that
any ordering produces the same result value. However, some associative operations are not symmetric. For example,
the matrix multiplication 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 binary and associative. If the subaction is not associative,
the result will be unpredictable. Each of the two inputs to the subaction is a slice from the argument collections. For
example, to sum all the balances for a customers 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 single value from the single input argument collection, which in this
case is the account balance of each input. In this case, the output is a single value, a sum of balances. When the reduce
action has several input collections, then one value from each pair of subaction inputs comes from each input collection.
For input collections of size n, the reduce action executes the subaction executes n-1 times. The output of the
subaction conceptually replaces the two input slices in the collection of tuples, reducing the size of the collections by
one, so the subaction can be applied repeatedly to pairs of slices until a single slice remains. The values of the final
slice are placed on the result output pins of the overall reduce action as scalars. In other words, the reduce action
serves to reduce the rank of the input values from collections to single values by repeated application of a binary
function. The type of a result values is identical to the type of the elements of the corresponding input collections.
The subaction may access values from outside the reduce action; such values will be fixed for all the concurrent
subaction executions during a single execution of the reduce action (but they might differ on some subsequent execution of the overall reduce action). No output pins of the subaction are available outside the reduce action
The isUnordered attribute is an assertion 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. If this assertion is in fact untrue, the
result of the computation will be unpredictable and nonrepeatable.
Attributes
isUnordered: Boolean
If true, it indicates an assertion that the slices of values may be given to the successive executions of the subaction in any order. This value should be true 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 value is true but the computation in fact
does depend on execution order, the model is ill-formed and the result of the
computation is unpredictable and nonrepeatable. If the collections are unordered,
then the iteration order is automatically unordered and this flag has no further
effect.
3-421
ReduceAction
Associations
The external inputs of the reduce action, a list of collections, all of the same size
and shape. Different pins may contain collections of different types of elements.
leftSubinput: OutputPin [1..*] A list of internal output pins of the reduce action, whose number is the same as
the number of argument pins and the number of result pins. On each execution of
the subaction, the leftSubinput and rightSubinput pins hold the values of two
adjacent slices from the intermediate collection of slices.
rightSubinput: OutputPin[1..*] A list of internal output pins of the reduce action, whose number is the same as
the number of argument pins and the number of result pins. On each execution of
the subaction, the leftSubinput and rightSubinput pins hold the values of two
adjacent slices from the intermediate collection of slices.
result: RuntimeInstance [1..*] The external outputs of the reduce action, a list of values, the number of which is
equal to the number of argument collections. After the completion of execution
of the reduce action, each pin has the value equal to the value of the corresponding suboutput pin at the completion of the final execution of the subaction. The
type of each element will be the same as the type of elements contained in the
corresponding argument collection.
subaction: Action
An action that is executed repeatedly on adjacent pairs of slices on a temporary

list of collections. The initial list of collections is copied from the arguments.
Each execution reduces the size of the collections by one until only a single element remains in each collection.
A nonempty list of available output pins owned by the subaction that represents
the results of executing the subaction. The number of pins must equal the number
of arguments, results, and subinputs. 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.
Constraints
[1] The number of argument pins, result pins, subinput pins, and suboutput pins must all be the same.
[2] The effect of executing the subaction on lists of values must be associative.
Runtime constraints
[1] The size of the argument collections must all be equal and it must be greater than zero.
Semantics
When all control flow and data flow prerequisites of a reduce action are satisfied, the execution of the reduce action
begins. The list of collections on the argument pins is conceptually copied to a temporary working list of collections
that accumulates intermediate results of the action. The original input collections are not modified by the action.There
is no requirement that such a working store be manifest in an implementation.
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-422
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.
When a subaction 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.
The selection of adjacent pairs of slices 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.
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 on access to shared
memory values, the result will be insensitive to execution order and deterministic. If, the subaction also 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.
If the subaction is nonassociative, if there is execution conflict, or if the isUnorderd assertion is incorrect, then
the result of execution of the reduce action will be unpredictable and nonrepeatable. The reduce action is not meant to
be used in such situations and its semantics are explicitly disavowed if such models are constructed.
Notation
None.
Examples
None.
Rationale
There is a frequent need to reduce a set or list to a single value that summarizes some property of the entire set. In the
common case of associative operations, any sequential representation of the algorithm greatly overspecifies the computation. The reduce metaoperator was introduced in APL but has important benefits for optimizers and provers.
StartObjectStateMachineAction
Description
StartObjectStateMachineAction is a primitive action that puts the state machine that is the classifier behavior of an
object in its top state, if it has not been so already.
Attributes
None.
3-423
StartObjectStateMachineAction
Associations
Holds the object on which to start the state machine. (Specializes Action.input.)
Constraints
None.
Semantics
When the StartObjectStateMachineAction is invoked, it puts the state machine that is the classifier behavior of the
input object into its top state. If that state machine already is in the top state, or has been in the top state earlier, this
action has no effect.
Notation
None.
Examples
None.
Rationale
StartObjectStateMachineAction is introduced to start the state machine of a newly created object.
StartObjectStateMachineAction has been newly introduced in UML 2.0.
3-424
21 Complete::Activities
Chapter 21. Complete::Activities

The Complete::Activities package describes the full semantics and notations for activities constructs introduced in
Chapter 12, Common::Activities.
Activities
(from Common_
Common
Behaviors
(from Common)
Kernel
(from Foundation)
Activities
Figure 21-46. Dependencies of the Complete::Activities package
InvocationNode
(from Activities)
InvocationNode
isSynchronous : Boolean = true
isMultipleInvocat ion : Boolean = false
0.. 1
+multiplicity
Multiplicity
(f rom Ke rne l)
Figure 21-47. Decompositions
425
ObjectFlow
(f ro m Ac ti vi ti es)
0..1
Behavior
(from Acti vi ties)
ObjectFlow
*
+selection
0..1
+transformation
effect : ObjectFlowEffectKind
isMulticast : Boolean = false
isMultireceive : Boolean = false
<<enu meration>>
ObjectFlowEffectKind
create
read
update
delete
ActivityEdge
(from Acti vi ties)
{ default is 1 }
ValueSpecification
+weight
ActivityEdge
(from Kernel )
0..1
Figure 21-48. Flows
Obj ectNode
(f ro m Ac ti vi ties )
{ default is null }
Obj ect Node
ordering : ObjectNodeOrderingKind = FIFO
1
+u pperBound
ValueSpecification
(from Kernel)
*
+inState
0..1
+select ion
0..1
State
Behavior
Parameter
(from StateM achines)
(from Acti vi ties)
(from Com m onBehavior)
Parameter
isStream : Boolean [1] = false
isException : Boolean [1] = false
Figure 21-49. Object Nodes
426
JoinNode
(from Acti vi ti es)
JoinNode
ValueSpecification
(from Kernel )
+joi nSpec
{default is "and"}
Figure 21-50. Controls
ActivityGroup
InterruptibleActivityRegion +region
+interruptingEdge ActivityEdge
*
0..1
[group]
ActivityEdge
0.. 0
+region
[ group]
[edgeContent s]
ActivityNode
+contents
[ nodeContents]
Figure 21-51. Interruptible regions
427
Generalization
(from Kernel)
Classifier
(from Kernel)
Activity
[specific]
[generalization]
[general]
[specialization]
ActivityGeneralization
kind : Activit yGeneralizationKi nd [0..1]
<<enumeration>>
ActivityGeneralizationKind
RedefinableElement
(from Kernel)
strictContentInheritance
invocationContentInheritance
unrestrictedContentnheritance
traceCompatibleContentInheritance
Act ivit yEdge
ActivityNode
+replacedNode
[redefinedElement]
+replacedEdge
[redefinedElement]
Figure 21-52. Generalization
InvocationNode
(from Activities)
InvocationNode
[owner]
0..1
+localPrecondition
[ownedElement]
Constraint
(f ro m Kernel)
*
+localPostcondition
[ owner]
[ownedElement]
*
0..1
Figure 21-53. Local pre/postconditions
428
Activity
NamedElement
(from K ernel)
Parameter
+parameterInSet
+param eterSet
ParameterSet
0.. *
1..*
Figure 21-54. Parameter sets
CentralBufferNode
DataStoreNode
Figure 21-55. Data stores
Activity
Activities are a kind of behavior that specifies the sequence and conditions for the invocation of other behaviors.
Description
Complete activities include interruptible regions and generalization.
Attributes
None.
Associations
[generalization] : ActivityGeneralizationA more general activity from which this inherits. Specialized from Classifier:generalization. See ActivityGeneralization.
Stereotypes
None.
Tagged Values
None.
Constraints
None.
429
ActivityEdge
Semantics
If a single copy of the activity is used for all invocations, the modeler must consider additional interactions between
tokens in complete activities. Tokens may reach bottlenecks waiting for tokens ahead of them to move downstream,
they may overtake each other due to the selection algorithm used in object node buffers, or due to variations in the
execution time of invoked behaviors, and most importantly, may abort each other with constructs such as activity
final, exception outputs, and interruptible regions.
A new activity copy for each invocation reduces token interaction, but complete activities add functionality increase
interaction. For example, streaming outputs create tokens to be handled by the rest of the activity. In these cases,
modelers must consider the same token interaction issues as using a single activity copy for all invocations.
Activities as classifiers can also be generalized in complete activities. See ActivityGeneralization for the kinds of
constraint that generalization can place on activities, and for notation.
An additional kind of grouping is added in complete activities. See InterruptibleActivityRegion.
None.
Notation
See intermediate notation.
Presentation Option
See intermediate presentation options.
Style Guidelines
Examples
See intermediate examples.
Rationale
ActivityEdge
An activity edge is a directed connection between two activity nodes.
Description
Complete edges add support for controlling token flow, can be replaced in generalization, and be contained in interruptible regions.
Attributes
weight : ValueSpecification [1..1] = 1Number of objects consumed from the source node on each traversal.
Associations
region : InterruptibleActivityRegion [0..1]Region that the edge can interrupt.
replacedEdge : ActivityEdge [0..*]Inherited edges replaced by this edge in a specialization of the activity.
430
ActivityEdge
Stereotypes
None.
Tagged Values
None.
Constraints
None.
Semantics
Any number of tokens can pass along the edge, in groups at one time, or individually at different times. The weight
attribute dictates the minimum number of tokens that must traverse the edge at the same time. It is a value specification evaluated every time a new token becomes nominated at the source. It must evaluate to a positive integer or null,
and may be a constant, that is, a LiteralInteger or a LiteralNull. When the minimum number of tokens become nominated, all the tokens at the source begin the candidacy process at once. The guard must evaluate to true for each token.
If the guard fails for any of the tokens, and this reduces the number of candidate tokens to less than the weight, then
all the tokens fail to become candidates. A null weight means that all the nominated tokens at the source enter the
candidacy process. This can be combined with a join to take all of the tokens at the souce when certain conditions
hold. See examples in Figure 21-57. A weaker but simpler alternative to weight is grouping information into larger
objects so that a single token carries all necessary data. See additional functionality for guards at DecisionNode.
Other rules for when tokens may be passed along the edge depend the kind of edge and characteristics of its source
and target. See the children of ActivityEdge and ActivityNode. The rules may be optimized to a different algorithm as
long as the effect is the same. For example, if the target is an object node that has reached its upper bound, no token
can be passed. The implementation can omit unnecessary weight evaluations until the downstream object node can
accept tokens.
Edges can be named, by inheritance from RedefinableElement, which is a NamedElement. However, edges are not
required to have unique names within an activity. The fact that Activity is a Namespace, inherited through Behavior,
does not affect this, because the containment of edges is through ownedElement, the general ownership metaassociation for Element that does not imply unique names, rather than ownedMember.
Edges inherited from more general activities can be replaced. See RedefinableElement for more information on overriding inherited elements, and Activity and ActivityGeneralization for more information on activity generalization.
See variations at children of ActivityEdge and ActivityNode.
Notation
Complete activities add the filled arrowhead notation used in presentation option for ParameterUsageNode. The
weight of the edge many be shown in curly braces that contain the weight. The weight is a value specification that is
431
ActivityEdge
a positive integer, which may be a constant. When regions have interruptions, a lightning-bolt style activity edge
expresses this interruption. (See InterruptibleActivityRegion for more detail.)
{weight=n}
{weight=null}
Activity edge for region interruptions
With edge weight

(where n is a value specification)
Figure 21-56. Activity edge notation.
Presentation Option
Style Guidelines
Examples
The figure below illustrates three examples of using the weight attribute. The Cricket example uses a constant weight
to indicate that a cricket team cannot be formed until eleven players are present. The Task example uses a non-constant weight to indicate that an invoice for a particular job can only be sent when all of its tasks have been completed.
The proposal example depicts an activity for placing bids for a proposal, where many such bids can be placed. Then,
when the bidding period is over, the Award Proposal Bid activity reads all the bids as a single set and determines
which vendor to award the bid.
{weight=no_of_job_tasks}
{weight=11}
Cricket
Player
Form
Cricket
Team
Task
[completed]
Send
Job
Invoice
Ready
to award
bid
Award
Bid
Bid
arrives
Bids for
Proposal
{weight=all}
Figure 21-57. Activity edge examples.
432
Rationale
A kind of generalization used for activities.
Description
An activity generalization is used to generalize activities according to their nodes and edges or according to their features as classifiers.
Attributes
kind : ActivityGeneralizationKind [0..1]The kind of activity generalization.
Associations
[general] : Activity
Specilized from Generalization to apply only to activities.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] If kind is strictContentInheritance then no node or edge in the specialized activity can be replaced.
[2] If kind is invocationContentInheritance then no invocation the specialized activity can be replaced.
Semantics
Activities are classifiers and may participate in a generalization hierarchy corresponding. The kinds of activity generalization are:
Supersetting of runtime executions. Since the instances of an activity-as-classifier are the executions of its activity, the executions of an activity like Fill Order , for example, will be a superset of the executions of a more specialized activity such as Fill Priority Order. See Figure 21-58. This meaning always applies, so need not be specified in
the kind attribute.
Strict content inheritance of both nodes and edges. The activity inherits all the nodes and edges of the supertype
activity, then specializes the model by adding nodes and edges. For example, the Fill Order activity might consist of
nodes a1, a2, a3 and edges e1 and e2; while its Fill Priority Order subtype consists of a1, a2, a3, and a4, and edges e1,
e2, and e3. This is indicated with the kind value strictContentInheritance.
Strict content inheritance of invocation nodes only. Similar to option 2 except that only the invocation nodes
must be preserved in inheritance, not the control nodes or edges. Instead, edges can be modified, for example, to add
control nodes, or guards and weights on edges can be modified to change flow. See replacedEdge on ActivityEdge.
This is indicated with the kind value invocationContentInheritance.
Loose content inheritance. Similar to option 3 except that nodes and edges can both be replaced in specialized
activities. See replacedNode and replacedEdge on ActivityNode and ActivityEdge respectively. This is indicated with
the kind value unrestrictedContentnheritance.
433
Trace-compatible content inheritance. a form of inheritance that restricts modifications in specialized activities
to those that do not invalidate runtime execution traces defined by the supertype activity. This is indicated with the
value traceCompatibleContentInheritance.
None.
Notation
Activity generalization is shown using the generalization symbol from class diagrams applied to the round-cornered
rectangle notation. The kind of generalization is shown as a keyword on the generalization symbol. See Figure 21-58.
Presentation Option
None.
Style Guidelines
Examples
An example of activity generalization is shown below.
Fill
Order
strictContentInheritance
Fill
Priority
Order
Figure 21-58. Activity generalization example.
Rationale
Activity generalizations explicitly models the kind of generalization rather than using a semantic variation.
ActivityGeneralization is new to UML 2.0.
The datatype ActivityGeneralizationKind is an enumeration with possible values strictContentInheritance, invocationContentInheritance, unrestrictedContentnheritance, and traceCompatibleContentInheritance.
ActivityNode
An activity node is a point in the flow of an activity connected by activity edges.
434
ActivityParameter
Description
Complete nodes can be replaced in generalization and be contained in interruptible regions.
Attributes
None.
Associations
region : InterruptibleActivityRegion [0..*] Interruptible regions containing the node.
replacedNode : ActivityNode [0..*]Inherited nodes replaced by this node in a specialization of the activity.
Stereotypes
None.
Tagged Values
None.
Constraints
None.
Semantics
Nodes inherited from more general activities can be replaced. See RedefinableElement for more information on overriding inherited elements, and Activity for more information on activity generalization. Other than these functionalities, an activity node is only a point in an activity at this level of abstraction. See children of ActivityNode for
additional semantics.
None.
Notation
See intermediate notation.
Presentation Option
Style Guidelines
Examples
See intermediate examples.
Rationale
ActivityParameter
An activity parameter is an object node for inputs and outputs to activities.
435
ActivityParameter
Description
Complete activity parameters inherit support for streaming and exceptions from Parameter (in Complete Activities).
Attributes
None.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
None.
See Activity.
Semantics
See intermediate semantics.
None.
Notation
The figure below shows annotations for streaming and exception activity parameters, which are same as for parameter usage nodes.
{stream}
Activity name
...
...
...

Presentation Option
See presentation option for ParameterUsageNode when parameter is streaming. This can be used for activity parameters also.
436
DataStoreNode
Style Guidelines
Examples
In the example below, production materials are streaming in to feed the ongoing printed ciruit board fabricaton. At the
end of the activity, computers are quality checked. Computers that do not pass the test are exceptions.
{stream}
Rejected
Computers
Produce
Printed-Circuit
Boards
Production
Materials
Assemble
Computers
PrintedCircuit
Boards
Test
Computers
Assembled
Computers
Accepted
Computers
Figure 21-60. Example of activity parameters for streaming and exceptions.

Rationale
DataStoreNode
A data store node is a central buffer node for non-transient information.
Description
A data store keeps all tokens that enter it, copying them when they are elected to move downstream. Incoming tokens
containing a particular object replace any tokens in the object node containing that object.
Attributes
None.
Associations
None
Stereotypes
None.
Tagged Values
None.
Constraints
None.
437
InterruptibleActivityRegion
Semantics
Tokens elected to move downstream are copied so that tokens appear to never leave the data store. If a token containing an object is elected to move into a data store , and there is a token containing that object already in the data store,
then the elected token replaces existing one. Selection and transformation behavior on outgoing edges can be
designed to get information out of the data store, as if a query were being performed. For example, the selection
behavior can identify an object to retrieve and the transformation behavior can get the value of an attribute on that
object. Selection can also be designed to only succeed when a downstream invocation has control passed to it, thereby
implementing the pull semantics of earlier forms of data flow.
None.
Notation
The data store notation is a special case of the object node notation, using the label datastore.
datastore
name
[state]
Figure 21-61. Data store node notation.
Presentation Option
Style Guidelines
Examples
The figure below is an example of using a data store node.
Hire
Employee
datastore
Personnel
database
Review
Employee
Assign
Employee
Rank
Employees
Figure 21-62. Data store node example.

Rationale
Data stores are introduced to support earlier forms of data flow modeling.
Data stores are new in UML 2.0.
An interruptible activity region is a grouping that supports termination of tokens flowing in the portions of an activity.
438
Description
A region contains activity nodes. When a token leaves an interruptible region via edges designated by the region as
interrupting edges, all tokens and behaviors in the region are terminated.
Attributes
None.
Associations
contents : ActivityNode [0..*] The nodes in the region.
interruptingEdge : ActivityEdge [0..*].The edges leaving the region that will abort other tokens flowing in the
region.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] Interrupting edges of a region must have their source node in the region and their target node outside the region in
the same activity containing the region.
Semantics
The region is interrupted when a token traverses an interrupting edge. At this point the interrupting token has left the
region and is not terminated.
Interruption does not happen in parallel with other tokens traversing non-interrupting edges that have sources in the
region and targets outside the region. If a non-interrupting edge is in the process of passing a token from a source
node in the region to target node outside the region, then the token arrives at the target as normal even if in interruption occurs during the traversal.
Do not use an interrupting region if it is not desired to abort all flows in the region in some cases. For example, if the
same copy of an activity is being used for all its invocations, then multiple streams of tokens will be flowing through
the same activity. In this case, it is probably not desired to abort all tokens just because one leaves the region. Arrange
for separate invocations of the activity to use separate copies of the activity when employing interruptible regions, so
tokens from separate invocations will not affect each other.
None.
439
Notation
An interruptible activity region is notated by a dashed, round-cornered rectangle drawn around the nodes contained
by the region. An interrupting edge is notation with a lightning-bolt activity edge.
Figure 21-63. InterruptibleActivityRegion notation with interrupting edge.

Presentation Option
An option for notating an interrupting edge is an zig zag adornment on a straight line.
Figure 21-64. InterruptibleActivityRegion notation with interrupting edge.
440
InvocationNode
Style Guidelines
Examples
The first figure below illustrates that when an order cancellation request is madeonly while receiving, filling, or
shipping) ordersthe Cancel Order behavior is invoked.
Order
cancel
request
[order
rejected]
Fill
Order
Receive
Order
Cancel
Order
Ship
Order
Close
Order
[order
accepted]
Send
Invoice
Make
Payment
Accept
Payment
Invoice
Figure 21-65. InterruptibleActivityRegion example.

Rationale
Interruptible regions are introduced to support more flexible non-local termination of flow.
Interruptible regions in activity modeling are new to UML 2.0.
InvocationNode
An invocation node is the use of a behavior within an activity.
Description
Complete invocations add support for multiple and asynchronous invocations, and local pre/postconditions.
Attributes
invocationMultiplicity : Multiplicity [0..1]Limits the number of parallel invocations of the behavior. This attribute is
ignored if the isMultipleInvocation attribute is false.
isMultipleInvocation : Boolean [1..1] = false
Tells whether the behavior is applied in parallel to each element in a
set taken as input.
isSynchronous : Boolean [1..1] = true

not.
Tells whether the invocation waits for the invoked behavior to return or
441
InvocationNode
Associations
localPrecondition : Constraint [0..*]
Constaint that must be satisfied when invocation is started.
localPostcondition : Constraint [0..*]
Constaint that must be satisfied when invocation is finished.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] If an invocation is asynchronous, then it may have no output parameter usages and all outgoing edges must be
control flows
[2] If an invocation is multiple and synchronous, then its behavior can have at most one output. If there is an output,
then it must provide a set, and the parameter usage for the output must have isSet = true.
Semantics
A synchronous invocation completes when its behavior completes. An asynchronous invocation completes when its
behavior is started, or at least ensured to be started at some point. When an asynchronous invocation is done, the flow
continues regardless of the status of the invoked behavior. For example, the containing activity may complete even
though the invoked behavior is not finished. This is why asynchronous invocation is not the same as using a fork to
invoke the behavior followedby a flow final. A forked behavior still needs to finish for the containing activity to finish. If it is desired to complete the invocation, but have some outputs provided later when they are needed, then use a
fork to give the invocation its own flow line, and rejoin the outputs of the invocation to the original flow when they
are needed.
Local preconditions and postconditions are constraints that must hold when the invocation starts and finishes, respectively. They hold only at the point in the flow that they are specified, not globally for other invocations of the behavior at other places in the flow or on other diagrams. Compare to pre and postconditions on Behavior (in Activities).
See semantic variations below for their effect on flow.
The isMultipleInvocation attribute determines whether the behavior might be executed multiple times in parallel,
depending on runtime inputs. If the invocation is multiple, then the invocation should receive one input, which is a set
of lists of actual arguments for the behavior. The number of elements in the set at runtime determines the number of
parallel executions of the behavior. If the invocation is synchronous, it completes when all behaviors are done. Otherwise, it completes when all behaviors are started, or ensured to be started. If there is an output parameter usage, the
invoked behavior must have a return parameter, and the results of the behavior invocations are collected into a set that
is put on the object node as a single token. The invoked behaviors are not necessarily executed in parallel, but may be.
If the input is an empty set or the null token, then the invocation behaves as if it had no behavior. No semantics is
defined for input sets with fewer or more elements than the number allowed by the invocationMultiplicity attribute. If
the invocation is not multiple, the behavior is invoked exactly once.
How local pre and postconditions are enforced is determined by the implementation. For example, violations may
detected at compile time or runtime. The effect may be an error that stops the execution or just a warning, and so on.
Since local pre and postconditions are modeler-defined constraints, violations do not mean that the semantics of the
invocation is undefined as far as UML goes. They only mean the model or execution trace does not conform to the
modelers intention.
See variations in ActivityEdge and ObjectNode.
442
InvocationNode
Notation
If the invocation is multiple, the multiplicity is shown in the upper right of the rectangle. Asynchronous invocations
may be indicated by the keyword <<asychronous>> in the invocation rectanlge. Local pre and postconditions are
shown as notes attached to the invocation with the keywords localPrecondition and localPostcondition, respectively. Global pre and postconditions for an entire activity are indicated within the activity border, as illustrated
below.
localPrecondition
constraint
multiplicity
name
<<asynchronous>>
name
name
localPostcondition
constraint
Figure 21-66. Invocation nodes
Presentation Option
Style Guidelines
Examples
Specify Trip Route below can result in multiple flight segments, each of which must be booked separately. The Book
Flight invocation will invoke the Book Flight behavior multiple times, once for each flight segment in the set passed
to BookFlight.
Specify
Trip
Route
Book
Flight
Figure 21-67. Examples of invocation nodes.
443
IJoinNode
The example below illustrates local pre and postcondition for the invocation of a drink dispensing machine.
locaPrecondition
A drink is selected that
the vending machine contains.
Dispense
Drink
localPostcondition
The vending machine dispensed
the drink that is selected.
Figure 21-68. Example of invocation node for an action behavior and local pre/postcondition specifications.
Rationale
IJoinNode
A join node is a control node that synchronizes multiple flows.
Description
Complete join nodes have a boolean value specification using the names of the incoming edges to specify the conditions under which the join will emit a token.
Attributes
None.
Associations
joinSpec : ValueSpecification [1..1] A specification giving the conditions under which the join will emit a token.
Default is and.
Stereotypes
None.
Tagged Values
None.
Constraints
None.
Semantics
If the join specification evaluates to true, tokens are nominated on the outgoing edge according to the join rules of the
following join rules:
444
1.
2.
IJoinNode
If all the incoming candidate tokens are control tokens, then one control token is nominated along the outgoing
edge.
If some are control tokens and other data tokens, then only the data tokens are nominated.
No joining of tokens is necessary if there is only one incoming edge, but it is not a useful case. The reserved string
and used as a join specification is equivalent to a specification that requires at least one candidate token along each
incoming edge. It is the default. The join specification is evaluated whenever a new token becomes a candidate on
any incoming edge. The evaluation is not interrupted by any new tokens becoming candidates during the evaluation,
nor are concurrent evaluations started when new tokens become candidates during an evaluation.
If any tokens are nominated on the outgoing edge, they must be accepted or rejected for traversal before the join specification can be evaluated again. If they are rejected for traversal, the nominations are withdrawn. The join specification may contain the names of the incoming edges to refer to whether a token was a candidate on that edge at the time
the evaluation started.
None.
Notation
Join specifications are shown near the join node, as shown below.
{joinSpec = ...}
...
Join node (with flows

and a join specification)
Figure 21-69. Join node notations.

Presentation Option
Style Guidelines
Examples
The example below illustrates how a join specification can be used to ensure that both a drink is selected and the correct amount of money has been inserted before the drink is dispensed. Names of the incoming edges are used in the
join specification to refer to whether tokens are available on the edges.
{joinSpec =
A and B
and the total coin value
inserted is >= drink price}
Select
Drink
Insert
Coin
A
B
Dispense
Drink
Figure 21-70. Join node example.
445
ObjectFlow
Rationale
ObjectFlow
An object flow is an activity edge that can have objects or data passing along it.
Description
Complete object flows add support for modeling the effects of behaviors, multicast/receive, and token selection from
object nodes and transformation of tokens.
Attributes
effect : ObjectFlowEffectKind [0..*]Specifies the effect that the immediately upstream or downstream invocation has on the objects flowing along the edge.
isMulticast : Boolean [1..1] = falseTells whether the objects in the flow are passed by multicasting.
isMultireceive : Boolean [1..1] = falseTells whether the objects in the flow are gathered from respondants to
multicasting.
Associations
selection : Behavior [0..1]
Selects tokens from a source object node.
transformation : Behavior [0..1]Changes or replaces data tokens flowing along edge.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] An edge with constant weight may not target an object node, or lead to an object node downstream with no intervening invocations, that has anupper bound less than the weight.
[2] A transformation behavior has one input parameter and one output parameter. The input parameter must be the
same as or a supertype the type of object token coming from the source end. The output parameter must be the
same or a subtype of the type of object token expected downstream. The behavior cannot have side effects.
[3] An object flow may have a selection behavior only if has an object node as a source.
[4] A selection behavior has one input parameter and one output parameter. The input parameter must be a bag of
elements of the same as or a supertype the type of source object node. The output parameter must be the same or
a subtype of the type of source object node. The behavior cannot have side effects.
[5] isMulticast and isMultiReceive cannot both be true.
[6] Only object flows with invocations at one end or the other may have effects. Only object flows with invocations
on the target end may have a delete effect. Only object flows with invocations on the souce end may have create
effect.
446
ObjectFlow
Semantics
If a transformation behavior is specified, then each candidate for the target node is passed to the behavior, and the output of the behavior is given to the target node for consideration. Because the behavior is used during the election process, it may be run many times on the same token before the token passes the entire election process and traverses the
edge. This means the behavior cannot have side effects. It may not modify objects, but it may for example, navigate
from one object to another, get an attribute value from an object, or replace a data value with another.
If a selection behavior is specified, then it is used to nominate a token to the edge from the source object node, rather
than using object nodes ordering. It has the same semantics as selection behavior on object nodes. See ObjectNode.
See application at DataStoreNode.
Multicasting and receiving is used in conjunction with partitions to model flows between behaviors that are the
responsibility of objects determined by a publish and subscribe facility. To support execution the model must be
refined to specify the particular publish/subscribe facility employed. This is illustrated in the Figure 21-74.
None.
Notation
Selection behavior is specified with the keyword selection placed in a note symbol, and attached to the appropriate
objectFlow symbol as illustrated in the figure below.
selection
selection
specification
selection
selection
specification
Figure 21-71. Specifying selection behavior on an Object flow.

Specifying the effect that the behavior of the invocations have on the objects flowing on the edge can be represented
by placing the effect in braces near the edge leading to the affected object node. Since flows from invocations to pins
are elided, the effect is shown next to the pin.
{output
effect}
{input
effect}
{output
effect}
{input
effect}
Figure 21-72. Specifying effect that invocations have on objects.

Presentation Option
Style Guidelines
Examples
In the figure below, two examples of selection behavior are illustrated. The example on the left indicates that the
orders are to be shipped based or order priorityand those with the same priority should be filled on a first-in/firstout (FIFO) basis. The example on the right indicates that the result of a Close Order activity produces closed order
447
ObjectFlow
objects, but the Send Customer Notice activity requires a customer object. The selection, then, speficies that a query
operation that takes an Order evaluates the customer object via the Order.customer:Party association. At the bottom
of the figure, an example depicts a Place Order activity which creates orders and Fill Order activity which reads these
placed orders for the purpose of filling them.
selection
FIFO within
Order Priority
Fill
Order
Order
[Filled]
transformation
Order.customer
Order
[Filled]
Close
Order
Ship
Order
Place
Order
Order
[Placed]
{create}
Order
[Closed]
Customer
Send
Customer
Notice
Order
[Placed]
{read}
Fill
Order

In the example below, the Requests for Quote (RFQs) are sent to multiple specific sellers (i.e. is multicast) for a quote
response by each of the sellers. Some number of sellers then respond by returing their quote response. Since multiple
responses can be received, the edge is labeled for the multiple-receipt option. Publish/subscribe and other brokered
mechanisms can be handled using the multicast and multireceive mechanisms. Note that the swimlanes are an important feature for indicating the subject and source of this.
Buyer
Seller
multicast
Request
for Quote
RFQs
Award
Quote
Quote
Responses
Place
Quote
multireceive
Figure 21-74. Specifying multicast and multireceive on the edge.

Rationale
Object flow is introduced to model the flow of data and objects in an activity.
Explicitly modeled object flows are new in UML 2.0. They replace the use of (state) Transition in UML 1.4 activity
modeling.
448
The datatype ObjectFlowEffectKind is an enumeration with possible values create, read, update, and delete.
ObjectNode
An object node is an abstract activity node that is part of defining object flow in an activity.
Description
Complete object nodes add support for token selection, limit on the number of tokens, and specifying the state
required for tokens.
Attributes
ordering : ObjectNodeOrderingKind [1..1] = FIFOTells whether and how the tokens in the object node are
ordered for selection to traverse edges outgoing from the object node.
upperBound : ValueSpecification [1..1] = NullThe maximum number of tokens allowed in the node. Objects
cannot flow into the node if the upper bound is reached.
Associations
inState : State [0..*]
The required states of the object available at this point in the activity.
selection : Behavior [0..1]
Selects tokens for outgoing edges.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] The upper bound must be equal to the upper bound of nearest upstream and downstream object nodes that do not
have intervening invocation nodes.
[2] If an object node has a selection behavior, then the ordering of the object node is ordered, and vice versa.
[3] A selection behavior has one input parameter and one output parameter. The input parameter must be a bag of
elements of the same as or a supertype the type of object node. The output parameter must be the same or a subtype of the type of object node. The behavior cannot have side effects.
Semantics
An object node may not contain more tokens than its upper bound. The upper bound must be a positive LiteralInteger
or a LiteralNull. An upper bound that is a LiteralNull means the upper bound is unlimited. See ObjectFlow for additional rules regarding when objects may traverse the edges incoming and outgoing from an object node.
The ordering of an object node specifies the order in which tokens in the object node are nominated to the outgoing
edges for traversal. This can be set to require that tokens do not overtake each other as they pass through the node
(FIFO), or that they do (LIFO or modeler-defined ordering). Modeler-defined ordering is indicated by an ordering
value of ordered, and a selection behavior that determines what token to nominate to the edges. The selection behavior takes all the tokens in the object node as input and chooses a single token from those. It is executed whenever a
token is to be nominated to an edge. Because the behavior is used during the election process, it may be run many
times on the same token before the token passes the entire election process and traverses the edge. This means the
449
ObjectNode
behavior cannot have side effects. The selection behavior of an object node is overriden by any selection behaviors on
its outgoing edges. See ObjectFlow. Overtaking due to ordering is distinguished from the case where separate invocations of the activity are handled by separate copies of the activity. In this case, the tokens have no interaction with
each other, because they flow through separate copies of the activity. See Activity.
None.
Notation
A name labeling the node indicates the type of the object node. The name can also be qualified by a state or states,
which is to be written within brackets below the name of the type. Object nodes whose instances are sets of the
name type are indicated with the set keyword above the node name. Upper bounds and ordering other than the
defaults are notated in braces underneath the object node.
name
[state, state ...]
name
name
Object node for

tokens containing
objects in specific
states
{upperBound = 2}
{ordering =LIFO}
Object node
with a limited
upper bound
Object node
with ordering
other than FIFO
Figure 21-75. Object node notations.

tSelection behavior is specified with the keyword selection placed in a note symbol, and attached to an ObjectNode
symbol as illustrated in the figure below.
selection
selection
specification
name
Figure 21-76. Specifying selection behavior on an Object node.

Presentation Option
Style Guidelines
Examples
See examples at ObjectFlow and children of ObjectNode.
450
ObjectNodeOrderingKind
Rationale
ObjectNodeOrderingKind
The datatype ObjectNodeOrderingKind is an enumeration with possible values unordered, ordered, LIFO, and FIFO.
Parameter (in Activities)

Parameter is extended when used with complete activities.
Description
Parameters are extended in complete activities to add support for streaming, exceptions, and parameter sets.
Attributes
isException : Boolean [1..1] =falseTells whether an output parameter may emit a value to the exclusion of the
other outputs.
isStream : Boolean [1..1] = falseTells whether an input parameter may accept values while its behavior is executing, or whether an output parameter post values while the behavior is executing.
parameterSet : ParameterSet [0..*]
The parameter sets containing the parameter. See ParameterSet.
Associations
None.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] A parameter cannot be a stream and exception at the same time.
[2] A input parameter cannot be an exception.
[3] Reentrant behaviors cannot have stream parameters.
Semantics
isException applies to output parameters. An output posted to an exception excludes outputs from being posted to
non-stream outputs and other exception outputs of the behavior. A token arriving at an exception output parameter of
an activity aborts all flows in the activity. Any objects previously posted to non-stream outputs never leave the activity. Streaming outputs posted before any exception are not affected. Use exception parameters on activities only if it
is desired to abort all flows in the activity. For example, if the same copy of an activity is being used for all its invocations, then multiple streams of tokens will be flowing through the same activity. In this case, it is probably not desired
to abort all tokens just because one reaches an exception. Arrange for separate invocations of the activity to use separate copies of the activity when employing exceptions, so tokens from separate invocations will not affect each other.
451
ParameterSet
In addition to the execution rules given at InvocationNode, these rules also apply to invoking a behavior with streaming parameters:
All non-stream inputs must arrive for the behavior to be invoked. If there are only stream inputs, then at least one
must arrive for the behavior to be invoked.
All inputs must arrive for the behavior to finish, that is, for all inputs must arrive for non-stream outputs to be
posted and control edges traversed out of the invocation of the behavior.
Either all non-stream outputs are posted when an activity is finished, or one of the exception outputs is.
The execution rules above provide for the arrival of inputs after a behavior is started and the posting of outputs before
a behavior is finished. These are stream inputs and outputs. Multiple stream input and output tokens may be consumed and posted while a behavior is running. Since an activity is a kind of behavior, the above rules apply to invoking an activity, even if the invocation is not from another activity. A reentrant invocation cannot have streaming
inputs because there are potentially multiple executions of the behavior going at the same time, and it is ambiguous
which execution should receive streaming tokens.
If a parameter usage node for a non-stream parameter has reached its upper bound, then the behavior cannot finish
until an object is removed from the parameter usage node by flowing downstream.
See semantics of InvocationNode and ActivityParameter.
None.
Notation
See notation at ParameterUsageNode and ActivityParameter. The notation in class diagrams for exceptions and
streaming parameters on operations has the keywords exception or stream in the property string. See notation for
Operation.
Presentation Option
Style Guidelines
Examples
See examples at ParameterUsageNode and ActivityParameter.
Rationale
Parameter (in Activities) is extended to support invocation of behaviors by activities.
Parameter (in Activities) is new in UML 2.0.
ParameterSet
Parameter sets provide alternative sets of inputs and outputs that a behavior may use.
Description
An parameter set acts as a complete set of inputs and outputs to a behavior, exclusive of other parameter sets on the
behavior.
452
ParameterSet
Attributes
None.
Associations
parameterInSet : Parameter [1..*]
Parameters in the parameter set.
Stereotypes
None.
Tagged Values
None.
Constraints
[1] The parameters in a parameter set must all be inputs or all be outputs of the same parameterized entity, and the
parameter set is owned by that entity.
[2] If a behavior has input parameters that are in a parameter set, then any inputs that are not in a parameter set must
be streaming. Same for output parameters.
Semantics
A behavior with input parameter sets can only accept inputs from parameters in one of the sets per execution. A
behavior with output parameter sets can only post outputs to the parameters in one of the sets per execution. The
semantics described at InvocationNode and ActivityParameter apply to each set separately.
None.
Notation
Multiple object flows entering or leaving an invocation are typically treated as and conditions. However, sometimes one group of flows are permitted to the exclusion of another. This is modeled as parameter set and notated with
rectangles surronding one or more parameter usages. The notation in the figure below expresses a disjunctive normal
form where one group of and flows are separated by or groupings. For input, when one group or another has a
complete set of input flows, the activity may begin. For output, based on the internal processing of the behavior, one
group or other of output flows may occur.
Figure 21-77. Alternative input/outputs using parameter sets notation.
453
ParameterUsageNode
Presentation Option
None.
Style Guidelines
Examples
In the figure below, the Ship Item activity begins whenever it receives a bought item or a made item. The diagram on
the left uses a decision diamond; the one on the left uses parameter sets to express the same notion. The example at
the bottom of the figure is a similar simplification of the Trouble Ticket example earlier.
Buy
Item
Ship
Item
Make
Item
Using parameter sets to express or invocation
[cannot
reproduce
problem]
[recorded]
Record
Problem
Correct
Problem
Reproduce
Problem
[else]
[not recorded]
[can
reproduce
problem]
[duplication
of another
problem]
[known
problem
and solution]
Communicate
ID Problem
and
Resolution
Verify
Resolution
Results
[else]
Audit and
Record
Trouble Ticket example using parameter sets.

Figure 21-78. Example of alternative input/outputs using parameter sets.
Rationale
Parameter sets provide a way for behaviors to direct token flow in the activity which invokes those behaviors.
ParameterSet is new in UML 2.0.
ParameterUsageNode
A parameter usage node is an object node for inputs and outputs to invocations.
454
ParameterUsageNode
Description
Complete parameter usage nodes support parameters extended for complete activities.
Attributes
None.
Associations
None
Stereotypes
None.
Tagged Values
None.
Constraints
[1] The type (including isSet), upper bound, and ordering of the parameter usage node must be compatible with the
type, upper multiplicity, and ordering of the parameter it uses.
See constraints on ObjectFlow.
Semantics
A parameter usage node refers to a parameter that accepts tokens from the invocation or provides tokens to it. The
used parameter is from the behavior invoked by the immediately downstream or upstream invocation node. Weight
can be set on the object flow edges going from a parameter usage to an invocation to control how many tokens are
taken into each invocation of the behavior. See InvocationNode, ActivityParameter, and ObjectNode.
None.
Notation
Whether an parameter usage is for a streaming parameter or not is notated with a text annotations near the parameter
usage: {stream} or {nonstream}. See figure below. The notation is the same even if the notation is a standalone
parameter usage. Non-stream is the default where the notation is omitted.
{stream}
{stream}
name
[state]
name
[state]
name
{stream}
Input and output parameter usage node ,
stand-alone style, streaming on both ends
Input parameter usage node ,

pin-style, streaming
{stream}
Figure 21-79. Stream parameter usage node notations.
455
ParameterUsageNode
Parameter usage nodes for exception parameters are indicated with a small triangle annotating the source end of the
edge that comes out of the exception parameter usage node. The notation is the same even if the notation uses a standalone parameter usage. See figure below.
Output parameter usage node , pin style, exception
Input and output parameter usage node , standalone style, exception

Figure 21-80. Exception parameter usage node notations.
See ObjectNode for other notations applying to parameter usage nodes, with examples for parameter usage nodes
below.
Presentation Option
Additional emphasis may be added or streaming parameters by using a graphical notation instead of the textual
adornment. Parameter usages notated apart from invocations can be combined with solid arrow lines to indicate
streaming. Parameter usages notated in the pin style can be shown as filled rectangles. When combined with the
option above, the small arrows are shown in white.
name
[state]
name
[state]
name
[state]
Input and output parameter usage node ,
stand-alone style, streaming on both ends
Input parameter usage node ,


Figure 21-81. Stream parameter usage node notations, with filled arrows and rectangles.
Style Guidelines
Examples
In the example below Order Filling is a continuous behavior that periodically emits (streams out) filled-order objects,
without necessarily concluding as an activity. The Order Shipping behavior is also a continuous behavior that period-
456
ParameterUsageNode
ically receives filled-order objects as they are produced. Order Shipping is invoked when the first order arrives and
does not terminate, processing orders as they arrive.
Order
Filling
{stream}
Order
Shipping
Order
[Filled]
Order
Filling
{stream}
Order
[Filled]
Order
[Filled]
{stream}
{stream}
Order
Shipping
Figure 21-82. Parameter usage examples.

Examples of exception notation for parameter usages is shown at the top of the figure below. Accept Payment normally completes with a payment as being accepted and the account is then credited. However, when something goes
wrong in the acceptance process, an exception can be raised that the payment is not valid, and the payment is rejected.
Send
Rejection
Accept
Payment
Accept
Payment
Credit
Account
Rejected
Payment
Send
Rejection
Accepted
Payment
Credit
Account
Figure 21-83. Exception parameter usage node examples.

The figure below shows two examples of selection behavior. Both examples indicate that orders are to be shipped
based or order priorityand those with the same priority should be filled on a first-in/first-out (FIFO) basis.
Order
[Filled]
Fill
Order
Order
[Filled]
Fill
Order
Ship
Order
Ship
Order
Order
[Filled]
selection
FIFO within
Order Priority
selection
FIFO within
Order Priority

Rationale
457
ParameterUsageNode
458
22 Complete::Associations
Chapter 22. Complete::Associations

The Associations subpackage of the Structure package specifies the AssociationClass construct as well as extensions
of the AssociationEnd construct.
Kernel
(from Foundation)
Associations
Figure 22-85. Dependencies of the Complete::Associations package
Associations.fm Version 2 beta R1
459

Attribute
(from Kernel)
Attribute
AssociationEnd
(from Kernel)
+qualifier
[ownedElement]
*
+assoc iationEnd
AssociationEnd
{ordered}
Class
(from Kernel)
0.. 1
As sociation
(from Kernel)
AssociationClass
Figure 22-86. The AssociationClass class and its relationships to other classes, and the extended definition of
AssociationEnd.
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 to any of the classifiers.
Description
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 both an Association and a Class.
Attributes
Associations
Constraints
[1] An AssociationClass cannot be defined between itself and something else.
self.allConnections->forAll ( ar |
ar.type <> self
and
ar.type.allParents ()-> excludes ( self )
and
ar.type.allChildren () -> excludes ( self ) )
460
AssociationClass
[1] The operation allConnections results in the set of all AssociationEnds of the Association.
allConnections : Set ( AssociationEnd );
allConnections = self.end->union ( self.allParents ().end )
Semantics
An association may be refined to have its own set of features; that is, 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 an association class is a combination of the semantics of an ordinary association and of a
class.
An association class is both a kind of association and kind of a class. Both of these constructs are classifiers and
hence have a set of common properties, like being able to have features, having a name etc. As these properties are
inherited from the same construct (Classifier), they will not be duplicated. Therefore, an association class has only
one name, and has the set of features that are defined for classes and for associations. The constraints defined for class
and for association also are applicable for association class, which implies for example that the attributes of the association class, the ends of the association class, and the opposite ends of associations connected to the association class
must all have distinct names. Moreover, the specialization and refinement rules defined for class and association are
also applicable to association class.
Note: It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at each end , i.e. from the instance point of view, the multiplicity of the associations ends are
1.
Notation
An association class is shown as a class symbol attached to the association path by a dashed line. The association path
and the association class symbol represent the same underlying model element, which has a single name. The name
may be placed on the path, in the class symbol, or on both, but they must be the same name.
Logically, the association class and the association are the same semantic entity; however, they are graphically
distinct. The association class symbol can be dragged away from the line, but the dashed line must remain attached to
both the path and the class symbol.
Person
Job
person
1..*
company
Company
Job
salary
Figure 22-87. An AssociationClass is depicted by an association symbol (a line) and a class symbol (a box)
connected with a dashed line. The diagram shows the association class Job which is defined between the two classes
Person and Company.
461
AssociationEnd (extended)

There is no change with respect to UML 1.4.
AssociationEnd (extended)
Association end is extended to be able to have qualifiers.
Description
The AssociationEnd construct from Core::Constructs::Associations is extended to be able to own Attributes which
serve as qualifiers.
Associations
qualifier : Attribute
An optional list of qualifier Attributes for the end. If the list is empty, then the Association
is not qualified.
The association is a specialization of the ownedElement association from Element to Element.

Semantics
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.
Note: 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: 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.
Notation
A qualifier is shown as a small rectangle attached to the end of an association path between the final path segment
and the symbol of the classifier that it connects to. The qualifier rectangle is part of the association path, not part of
the classifier. The qualifier is attached to the source end of the association.
The multiplicity attached to the target end denotes the possible cardinalities of the set of target instances selected
by the pairing of a source instance and a qualifier value.
The qualifier attributes are drawn within the qualifier box. There may be one or more attributes shown one to a
line. Qualifier attributes have the same notation as classifier attributes, except that initial value expressions are not
meaningful.
462
It is permissible (although somewhat rare), to have a qualifier on each end of a single association.
A qualifier may not be suppressed.
Bank
Chessboard
accountNo
rank : Rank
file : File
1
1
0..1
Square
Person
Figure 22-88. Qualified associations.

Style Guidelines
The qualifier rectangle should be smaller than the attached class rectangle, although this is not always practical.
Attribute is extended to be able to act as qualifiers of association ends.
Description
Atttribute from Core::Constructs::Attributes is extended so that it can be aggregated in an AssociationEnd where the
Attribute is to act as a qualifier of the AssociationEnd.
Associations
associationEnd : AssociationEnd [ 0..1 ]

Designates the optional AssociationEnd that owns a qualifier attribute.
The association is a specialization of the owner association from Element to Element.
463
464
23 Complete::ComponentDeployments
Chapter 23. Complete::ComponentDeployments

The ComponentDeployments subpackage of the Complete package specifies a set of constructs that can be used to
model advanced deployment aspects of components. In particular, this package extends the basic deployment constructs defined in Common::Deployment with the concepts of deployment specification and component assembly.
Kernel
(from Foundation)
Components
(from Common)
Deployments
(from Common)
Component
Deployments
Figure 23-89. Dependencies of the Complete::ComponentDeployments package
ComponentDeployments.fm Version 2 beta R1September 9, 2002 11:31 am
465
+assembledComponent
ComponentDeployment
Deployment
(from Deployments)
+conf ig ured Co mpo ne nt
Component
0..1
+d eployment
(from Components)
+implementedComponent
[implementedElement]
+deploymentSpecification
[ownedMember]
(from Deployments)
+container
0..1
*
0..1
DeploymentSpecification
*
0..1
+deployment Descriptor
[implementingArtifact]
deploymentLocation : String
executionLocation : String
*
0..1
+executableArtifact
Artifact
(from Deployments)
0..1
+content
+executableArtifact
0..1
[implementingArtifact]
[co nf igure dCo mp one nt ]

+configuredAssembly
0..1
+implementedAssembly
ComponentAssembly
0..1
+assembly
*
Cla ss ifier
(from Kernel)
Aut onomo us El ement

(from Kernel)
Figure 23-90. The deployment of Components to ExecutionEnvironments based on DeploymentSpecifications.
ComponentAssembly
A ComponentAssembly is the definition of a specific grouping of Components, with the intention of deploying
that group as a unit.
Description
In the metamodel, a ComponentAssembly is a subclass of AutonomousElement that has an association to one or
more component definitions.
A ComponentAssembly has one or more implementingArtifacts that are deployed to Node instances, optionally
subject to values specified in a deploymentDescriptor based on a DeploymentSpecification.
Attributes
Associations
executableArtifact : Artifact [0..1]

The executable Artifacts that implement the ComponentAssembly and that are
deployed to a Node.
assembledComponent: Component [*]

The set of compoents that are being grouped together.
466
ComponentDeployment
Constraints
Semantics
When components are deployed they are often grouped together. This can be achieved through the definition of an
over arching component, but in some cases an explicit parent component is undesired. In the cases where a peer-topeer level grouping of components is required, a component assembly is used.
Notation
A ComponentAssembly is notated as a rectangle with two compartments. The top-most compartment contains the
name of the assembly, and optionally a keyword assembly. The bottom compartment lists the contained components.
The following changes from UML 1.x have been made: ComponentAssembly is not defined in UML 1.4.
ComponentDeployment
A component deployment is the deployment of an executable component artifact to an execution environment,
optionally parameterized through the properties specified in a deployment specification.
Description
In the metamodel, ComponentDeployment is a subtype of Deployment.
Attribute
Associations
specification : deploymentSpecification [*]

The specification of properties that parameterize the execution of an Artifact.
This association is redefined from the association ownedmember between
Namespace and NamedElement.
Constraints
Semantics
Notation
The following changes from UML 1.x have been made: An association to DeploymentSpecification has been made
explicit component deployment.
467
A deployment specification specifies a set of properties which determine execution parameters of a component
artifact that is deployed on a node. A deployment specification can be aimed at a specific type of container. An
artifact that reifies or implements deployment specification properties is a deployment descriptor.
Description
In the metamodel, a DeploymentSpecification is a subtype of Classifier. It defines a set of deployment properties
that are specific to a certain Container type. An instance of a DeploymentSpecification with specific values for
these properties may be contained in a deploymentDescriptor Artifact.
Attributes
deploymentLocation : String
The location where an Artifact is deployed onto a Node. This is typically a 'directory' or 'memory address'.
executionLocation : String
The location where a component Artifact executes. This may be a local or remote
location.
Associations
deploymentDescriptor : Artifact [*]

The Artifact that contains the properties of a DeploymentSpecification. This may
be the executable artifact itself, or a separate Artifact.
container : ExecutionEnvironment [0..1]The type of Container that a DeploymentSpecification complies with.
Constraints
Semantics
The deployment specification element is expected to be extended in specific component profiles. Typical standard
tagged values that a profile might add to deployment specification are:
concurrencyMode with tagged values {thread, process, none}.
executionMode with tagged values {local, remote, none}.
transactionMode with tagged values {transaction, nestedTransaction, none}.
Notation
A DeploymentSpecification is graphically displayed as a classifier rectangle that is annotateded to a component artifact that is deployed on a container.
468
deployment spec
deployment spec
Name
Name
execution: thread
transaction : true
execution: execKind
transaction : Boolean
Figure 23-91. A DeploymentSpecification for an artifact (specification and instance levels).
:AppServer1
artifact
ShoppingApp.ear
artifact
ShoppinCart.jar
artifact
Order.jar
{component = SCart}
{component = Order}
deployment spec
ShoppingAppdesc.xml
deployment spec
Orderdesc.xml
Figure 23-92. DeploymentSpecifications related to the artifacts that they parameterize.
469
As a notation option, the properties of a deployment specification may also be annoted on an artifact directly in the
form of a list of {property = value} strings.
:AppServer
artifact
Order.jar
{component = Order}
{deployment = D:\bin}
{execution = thread, session}
Figure 23-93. A DeploymentSpecification for an artifact.

The following changes from UML 1.x have been made: DeploymentSpecification does not exist in UML 1.4.
470
24 Complete::Generalizations
Chapter 24. Complete::Generalizations

The Generalizations package provides mechanisms for modeling generalization relationships. In particular, it supports the following modeling techniques:
multiple partitioning of subtypes
partitioning attributes, where the partitions can be constrained to be complete or disjoint
defining power types
The Generalizations package is a subpackage of the Complete package, as depicted in Figure 24-94. It specializes several classes from the Kernel package (Classifier, Generalization and AutonomousElement), as illustrated in
Figure 24-95.
Kernel
(from Foundation)
Generalizations
Figure 24-94. Dependencies of the Complete::Generalizations package
Generalizations.fm Version 2 beta R1
471
+ s pec ific
Clas s ifier
(from K ernel)
+ generaliz ation
+ general
+ s pec ializ ation
Clas s ifier
0..1
G eneraliz ation
(from K ernel)
G eneraliz ation
A utonom ous E lem ent

(from K ernel)
+ pow erty pe
+ generaliz ation
G eneraliz ationS et
0..*
+ pow erty peE x tent
is C overing : B oolean
is D is joint : B oolean
*
+ G eneraliz ationS et
Figure 24-95. The classes defined in the Generalizations package.
472
In this package, Classifier is specialized to include an association to GeneralizationSet.
Description
The Classifier construct from Foundation :: Kernel :: Generalizations is specialized to include an association to GeneralizationSet. In this association, an instance of Classifier is designated to be the power type for a particular GeneralizationSet.
Attributes
Associations
powertypeExtent : GeneralizationSet
Designates the GeneralizationSet of which the associated Classifier is a power
type.
Constraints
[1] The Classifier that maps to a GeneralizationSet may neither be a specific nor a general Classifier in any of the
Generalization relationships defined for that GeneralizationSet. In other words, a power type may not be an
instance of itself nor may its instances also be its subclasses.
Semantics
The notion of power type was inspired by the notion of power set. A power set is defined as a set whose instances are
subsets. In essence, then, a power type is a class whose instances are subclasses. The powertypeExtent association
relates a Classifier with a set of generalizations which a) have a common specific Classifier, and b) represent a subclass partitioning of that class.
For example, the Bank Account Type classifier could have a powertype association with a GeneralizationSet. This
GeneralizationSet could then associate with two Generalizations where the class (i.e., general Classifier) Bank
Account has two specific subclasses (i.e., Classifiers): Checking Account and Savings Account. Checking Account
and Savings Account, then, are instances of the power type: Bank Account Type. In other words, Checking Account
and Savings Account are both: instances of Bank Account Type, as well as subclasses of Bank Account. (For more
explanation and examples, see Examples in the GeneralizationSet section, below.)
Notation
See GeneralizationSet section, below.
Examples
See GeneralizationSet section, below.
Changes from UML 1.4
In UML 1.4, the powertypeExtent associated with the Generalization class. With the introduction of GeneralizationSet, the powertypeExtent association was changed to map to GeneralizationSet, instead.
473
Generalization (extended)
In this package, Generalization is specialized to include an association to GeneralizationSet.
Description
The Generalization construct from Foundation :: Kernel :: Generalizations is specialized to include an association to
GeneralizationSet. In this association, an instance of Generalization is designated a being a member of a particular
GeneralizationSet.
Attributes
Associations
generalizationSet
Designates a set in which instances of Generalization is considered members.
Constraints
[1] Every Generalization associated with a given GeneralizationSet must have the same general Classifier. That is, all
Generalizations for a particular GeneralizationSet must have the same superclass.
Semantics
Each Generalization is a binary relationship that relates a specific Classifier to a more general Classifier (i.e., a subclass). Each GeneralizationSet conatins a particular set of Generalization relationships that collectively describe the
way in which a specific Classifier (or class) may be partitioned. The generalizationSet associates those instances of a
Generalization with a particular GeneralizationSet.
For example, one Generalization could relate Person as a general Classifier with a Female Person as the specific Classifier. Another Generalization could also relate Person as a general Classifier, but have Male Person as the specific
Classifier. These two Generalizations could be associated with the same GeneralizationSet, because they specify one
way of partitioning the Person class. (For more detail, see Semantics in GeneralizationSet, below)
Notation
A generalization is shown as a line with an hollow triangle as an arrowhead between the symbols representing the
involved classifiers. The arrowhead points to the symbol representing the general classifier. When these relationships
are named, that name designates the GeneralizationSet to which the Generalization belongs. Each GeneralizationSet
has a name (which it inherits since it is a subclass of PackableElement). Therefore, all Generalization relationships
with the same GeneralizationSet name are part of the same GeneralizationSet. This notation form is depicted in a),
below.
When two or more lines are drawn to the same arrowhead, as illustrated in b) below, the specific Classifiers are part
of the same GeneralizationSet. When diagrammed in the way, the lines do not need to be labeled separately; instead
the generalization set need only be labeled once. The labels are optional because the GeneralizationSet is clearly designated.
Lastly in c) below, a GeneralizationSet can be designated by drawing a dashed line across those lines with separate
arrowheads that are meant to be part of the same set, as illustrated at the bottom of the figure below. Here, as with b),
474
the GeneralizationSet may be labeled with a single name, instead of each line labeled separately. However, such
labels are optional because the GeneralizationSet is clearly designated.
another
Generalization Set
one Generalization Set

generalization
set name-1
generalization
set name-1
generalization
set name-2
a) GeneralizationSet sharing same general Classifier using the same generalization relationship names.
one
Generalization
Set
generalization
set name-1
another
Generalization Set
generalization
set name-1
generalization
set name-2
generalization
set name-2
another
Generalization Set
one Generalization Set
b) GeneralizationSet designation by subtypes sharing a common generalization arrowhead.
one
Generalization
generalization
Set
set name-1
generalization
set name-2
another
Generalization Set
c) GeneralizationSet sharing same general Classifier using the dashed-line notation.

Figure 24-96. GeneralizationSet designation notations.
475
Examples
In the illustration below, the Person class can be specialized as either a Female Person or a Male Person. Furthermore,
Persons can be specialized as an Employee. Here, Female Person or a Male Person of Person constitute one GeneralizationSet and Manager another. This illustration employs the notation forms depicted in the diagram above.
Person
Person
gender
Female
Person
gender
gender
employment
status
Male
Person
Female
Person
Employee
employment
status
Employee
Male
Person
Person
employment
status
gender
Female
Person
Person
Male
Person
Employee
Female
Person
Male
Person
Employee
Figure 24-97. Multiple subtype partitions (GeneralizationSets) example.

Changes from UML 1.4
In UML 1.4, the Generalization class had an attribute named discriminator. The purpose of this field was to define a
set of Generalization relationships using a common name. The GeneralizationSet performs the same essential function while providing the set with attributesas well as a name on the set instead of each Generalization. Any name
associated with a particular Generalization, then, is implied by its association with a GeneralizationSet.
476
GeneralizationSet
GeneralizationSet
A GeneralizationSet is an AutonomousElement (from Foundation :: Kernel :: PackagingNamespaces) whose
instances define partitioned sets of Generalization relationships.
Description
Each Generalization is a binary relationship that relates a specific Classifier to a more general Classifier (i.e., a subclass). Each GeneralizationSet defines a particular set of Generalization relationships that describe the way in which
a specific Classifier (or superclass) may be partitioned. For example, a GeneralizationSet could define a partitioning
of the class Person into two subclasses: Male Person and Female Person. Here, the GeneralizationSet would associate
two instances of Generalization. Both instances would have Person as the specific classifier, however one Generalization would involve Male Person as the general Classifier and the other would involve Female Person as the general
classifier. In other words, the class Person can here be said to be partitioned into two subclasses: Male Person and
Female Person. Person could also be partitioned into North American Person, Asian Person, European Person, or
something else. This partitioning would define a different GeneralizationSet that would associate with three other
Generalization relationships. All three would have Person as the specific Classifier; only the general classifiers would
differ: i.e., North AmericanPerson, Asian Person, and European Person.
Attributes
isCovering : Boolean
Indicates (via the associated Generalizations) whether or not the set of specific
Classifiers are covering for a particular general classifier. When isCovering is
true, every instance of a particular general Classifier is also an instance of at least
one of its specific Classifiers for the GeneralizationSet. When isCovering is false,
there are one or more instances of the particular general Classifier that are not
instances of at least one of its specific Classifiers defined for the GeneralizationSet. For example, Person could have two Generalization relationships each with a
different specific Classifier: Male Person and Female Person. This GeneralizationSet would be covering because every instance of Person would be an instance
of Male Person or Female Person. In contrast, Person could have a three Generalization relationships involving three specific Classifiers: North AmericanPerson,
Asian Person, and European Person. This GeneralizationSet would not be covering because there are instances of Person for which these three specific Classifiers do not apply. The first example, then, could be read: any Person would be
specialized as either being a Male Person or a Female Personand nothing else;
the second could be read: any Person would be specialized as being North American Person, Asian Person, European Person, or something else.
isDisjoint : Boolean
Indicates whether or not the set of specific Classifiers in a Generalization relationship have instance in common. If isDisjoint is true, the specific Classifiers for
a particular GeneralizationSet have no members in common; that is, their intersection is empty. If isDisjoint is false, the specific Classifiers in a particular GeneralizationSet have one or more members in common; that is, their intersection is
not empty. For example, Person could have two Generalization relationships,
each with the different specific Classifier: Manager or Staff. This would be disjoint because every instance of Person must either be a Manager or Staff. In contrast, Person could have two Generalization relationships involving two specific
(and non-covering) Classifiers: Sales Person and Manager. This GeneralizationSet would not be disjoint because there are instances of Person which can be a
Sales Person and a Manager.
Associations
generalization [1]
Designates the instances of Generalization which are members of a given GeneralizationSet.
477
powertype [2]
GeneralizationSet
Designates the Classifier that is defined as the power type for the associated GeneralizationSet.
Constraints
[1] Every Generalization associated with a particular GeneralizationSet must have the same general Classifier.
[2] The Classifier that maps to a GeneralizationSet may neither be a specific nor a general Classifier in any of the
Generalization relationships defined for that GeneralizationSet. In other words, a power type may not be an
instance of itself nor may its instances be its subclasses.
Semantics
The generalizationSet association designates the partition to which the Generalization link belongs. All of the Generalization links that share a given general Classifier are divided into disjoint sets (that is, partitions) using the generalizationSet association. Each partition represents an orthogonal dimension of specialization of the general Classifier.
As mentioned above, in essence, a power type is a class whose instances are subclasses of another class. Power types,
then, are metaclasses with an extra twist: the instances are also be subclasses. The powertype association relates a
classifier to the instances of that classifierwhich are the specific classifiers identified for a GeneralizationSet. For
example, the Bank Account Type classifier could associate with a Generalization relationship that has specific classifiers of Checking Account and Savings Account. Here, then, Checking Account and Savings Account are instances of
Bank Account Type. Furthermore, if the Generalization relationship has a general classifier of Bank Account, then
Checking Account and Savings Account are also subclasses of Bank Account. Therefore, Checking Account and
Savings Account are both instances of Bank Account Type and subclasses of Bank Account. (For more explanation
and examples, see Examples in the Generalization section, below.)
Notation
The notation to express the grouping of Generalizations into GeneralizationSets were presented in the Notation section of Generalization, above. To indicate whether or not a generalization set is covering and disjoint, each set should
be labeled with one of the constraints indicated below.
{complete, disjoint} - Indicates the generalization set is covering and

its specific Classifiers have no common instances
{incomplete, disjoint} - Indicates the generalization set is not covering and
its specific Classifiers have no common instances*
{complete, overlapping} - Indicates the generalization set is covering and
its specific Classifiers do share common instances
{incomplete, overlapping} - Indicates the generalization set is not covering and
its specific Classifiers do share common instances
*Default is {incomplete, disjoint}
Figure 24-98. Generalization set constraint notation.
478
GeneralizationSet
Graphically, the GeneralizationSet constraints are placed next to the sets, whether the common arrowhead notation is
employed of the dashed line, as illustrated below.
{Generalization
Set constraint-1}
{Generalization
Set constraint-2}
GeneralizationSet constraint when sharing common generalization arrowhead
{Generalization
Set constraint-3}
{Generalization
Set constraint-4}
GeneralizationSet constraint using dashed-line notation

Figure 24-99. GeneralizationSet constraint notation.
Power type specification is indicated by placing the name of the powertype Classifierpreceded by a colonnext
the GeneralizationSet graphically containing the specific classifiers that are the instances of the power type. The illus-
479
GeneralizationSet
tration below indicates how this would appear for both the shared arrowhead and the dashed-line notation. for
GeneralizationSets.
general
classifier
powertype
classifier-1
: powertype classifier-1
specific
classifier-1
powertype
classifier-2
specific
classifier-2
specific
classifier-3
Powertype specification when sharing common generalization arrowhead
general
classifier
powertype
classifier-1
specific
classifier-1
powertype
classifier-2
specific
classifier-2
specific
classifier-3
Power type specification using dashed-line notation

Figure 24-100. power type notation.
Examples
Partitioning and Partitioning Constraints.

In the illustration below, the Person class can be specialized as either a Female Person or a Male Person. Because this
partitioning, or GeneralizationSet, is constrained to be complete and disjoint, each instance of Person must either be a
Female Person or a Male Person; that is, it must be one or the other and not both. (Therefore, Person is an abstract
class because a Person object may not exist without being either a Female Person or a Male Person.) Furthermore,
Persons can be specialized as an Employee. The generalization set here is expressed as {incomplete, disjoint}, which
means that instances of Persons can be partitioned as Employees or some other unnamed collection that consists of all
non-Employee instances. In other words, Persons can either be an Employee or in the complement of Employee, and
not both. Taken together, the diagram indicates that a Person may be 1) either a Male Person or Female Person, and 2)
480
GeneralizationSet
an Employee or not. When expressed in this manner, it is possible to partition the instances of a classifier using a disjunctive normal form (DNF).
Person
{complete,
disjoint}
A complete partition
indicating that a Person
may be subtyped as either
a Female Person or a
Male Person.
Female
Person
{incomplete,
disjoint}
Employee
Male
Person
An incomplete partition
indicating that a Person
can also be an Employee
or not.
Figure 24-101. Multiple subtype partitions (generalization sets) and constraint examples.
Power types
Grouping the objects in our world by categories, or classes, is an important technique for organizations. For instance,
one of the ways botanists organize trees is by species. In this way, each tree we see can be classified as an American
elm, sugar maple, apricot, saguaroor some other species of tree. The class diagram below expresses that each Tree
Species classifies zero or more instances of Tree, and each Tree is classified as exactly one Tree Species. For example, one of the instances of Tree could be the tree in your front yard, the tree in your neighbors backyard, or trees at
your local nursery. Instances of Tree Species, such as sugar maple and apricot. Furthermore, this figure indicates the
relationships that exist between these two sets of objects. For instance, the tree in your front yard might be classified
as a sugar maple, your neighbors tree as an apricot, and so on. This class diagram expresses that each Tree Species
classifies zero or more instances of Tree, and each Tree is classified as exactly one Tree Species. It also indicates that
each Tree Species is identified with a Leaf Pattern and has a general location in any number of Geographic Locations.
For example, the saguaro cactus has leaves reduced to large spines and is generally found in southern Arizona and
northern Sonora. Additionally, this figure indicates each Tree has an actual location at a particular Geographic Location. In this way, a particular tree could be classified as a saguaro and be located in Phoenix, Arizona.
Lastly, this diagrams illustrates that Tree is subtyped as American Elm, Sugar Maple, Apricot, or Saguaroor something else. Each subtype, then, can have its own specialized properties. For instance, each Sugar Maple could have a
yearly maple sugar yield of some given quantity, each Saguaro could be inhabited by zero or more instances of a Gila
Woodpecker, and so on. At first glance, it would seem that a modeler should only use either the Tree Species class or
the subclasses of Treesince the instances of Tree Species are the same as the subclasses of tree. In other words, it
seems redundant to represent both on the same diagram. Furthermore, having both would seem to cause potential diagram maintenance issues. For instance, if botanists got together and decided that the American elm should no longer
be a species of tree, the American Elm object would then be removed as an instance of Tree Species. To maintain the
integrity of our model in such a situation, the American Elm subtype of Tree must also be removed. Additionally, if a
new species were added as a subtype of Tree, that new species would have to be added as an instance of Tree Species.
The same kind of situation exists if the name of a tree species were changedboth the subtype of Tree and the
instance of Tree Species would have to be modified accordingly.
As it turns out, this seemis redunadancy is not a redundancy semantically (although it may be implemented that way).
different modeling approaches depicted above are not really all that different. In reality, the subtypes of Tree and the
instances of Tree Species are the same objects. In other words, the subtypes of Tree are instances of Tree Species.
Furthermore, the instances of Tree Species are the subtypes of Tree. The fact that an instance of Tree Species is called
sugar maple and a subtype of Tree is called Sugar Maple is no coincidence. The sugar maple instance and Sugar
Maple subtype are the same object. The instances of Tree Species areas the name impliestypes of trees. The subtypes of Tree areby definitiontypes of trees. While Tree may be partitioned in various ways (based on size or
age, for example), in this example it is partitioned on the basis of species. Therefore, the integrity issue mentioned
481
GeneralizationSet
above is not really an issue here. Deleting the American Elm subtype from the Tree partition does not require also
deleting the corresponding Tree Species instance, because the American Elm subtype and the corresponding Tree
Species instance are the same object. Figures 23.4 and 23.5 depict another way of thinking about this. .
trees
tree species 1
Tree
Species
Tree
*
{disjoint,
incomplete}
: Tree Species
Sugar
Maple
*
actual
location
general
locations
leaf
pattern
Geographic
Location
Leaf
Pattern
Apricot
American
Elm
Saguaro
Figure 24-102. Power type example and notation.
As established above, the instances of Classifiers can also be Classifiers. (This is the stuff that metamodels are made
of.) These same instances, however, can also be specific classifiers (i.e. subclasses) of another classifier. When this
occurs, we have what is called a power type. Formally, a power type is a classifier whose instances are also subclasses
of another classifier
In the examples above, Tree Species is a power type on the Tree type. Therefore, the instances of Tree Species are
subtypes of Tree. This concept applies to many situations within many lines of business. The figure below depicts
other examples of power types. The name on the generalization set beginning with a colon indicates the power type.
In other words, this name is the name of the type of which the subtypes are instances.
Diagram (a) in the figure below, then, can be interpreted as: each instance of Account is classified with exactly one
instance of Account Type. It can also be interpreted as: the subtypes of Account are instances of Account Type. This
means that each instance of Checking Account can have its own attributes (based on those defined for Checking
Account and those inherited from Account), such as account number and balance. Additionally, it means that Checking Account as an object in its own right can have attributes, such as interest rate and maximum delay for withdrawal.
(Such attributes are sometime referred to as class variables, rather than instance variables.) The example (b) depicts a
vehicle-modeling example. Here, each Vehicle can be subclassed as either a Truck or a Car or something else. Furthermore, Truck and Car are instances of Vehicle Type. In (c), Disease Occurrence classifies each occurrence of dis-
482
GeneralizationSet
ease, e.g. my chicken pox and your measles. Disease Classification is the power type whose instances are classes such
as Chicken Pox and Measles.
:Account Type
:Vehicle Type
(a) Bank account/account type example
(b) Vehicle/vehicle type example
: Telephone Service Category
: Disease Classification
(a) Disease Occurrence/Disease Classification example
(b) Telephone service example
Figure 24-103. Other power type examples.

Labeling partitions with the power type becomes increasingly important when a type has more than one power type.
The figure below is one such example. Without knowing which partition contains Policy Coverage Types and which
Insurance Lines, clarity is compromised. This figure depicts an even more complex situation. Here, a power type is
expressed with multiple partitions. For instance, a Policy can be subtyped as either a Life, Health, Property/Casualty,
or some other Insurance Line. Furthermore, a Property/Casualty policy can be further subtyped as Automobile,
483
GeneralizationSet
Equipment, Inland Marine, or some other Property/Casualty line of insurance. In other words, the subtypes in the partitions labeled Insurance Line are all instances of the Insurance Line power type.
Policy Coverage
1
Type
issued policies
*
coverage type
{disjoint, complete}
:Policy Coverage Type
insurance line
1
Policy
issued policies
Insurance
Line
{disjoint, complete}
:Insurance Line
Group
Policy
Life
Policy
Individual
Policy
Health
Policy
Property/
Casualty Policy
Figure 24-104. Other power type examples.

Power types are a conceptual, or analysis, notion. They express a real-world situation. Implementing, however, them
may not be easy and efficient. To implement power types with a relational database would mean that the instances of
a relation could also be relations in their own right. In object-oriented implementations, the instances of a class could
also be classes. However, if the software implementation can not directly support classes being objects and vice
versa, redundant structures must be defined. In other words, unless youre programming in Smalltalk or CLOS, the
designer must be aware of the integrity problem of keeping the list of power type instances in sync with the existing
subclasses. Without the power type designation, implementors would not be aware that they need to consider keeping
the subclasses in sync with the instances of the power type; with the power type indication, the implementor knows
that a) an data integrity situation exists, and b) how to manage the integrity situation. For example, if the Life Policy
instance of Insurance Line were deleted, the subclass called Life Policy can no longer exist. Or, is a new subclass of
Policy were added, a new instance must also be added to the appropriate power type.

GeneralizationSet did not exist in UML 1.x. It is a replacement for the discriminator in the Generalization class.
484
25 Complete::InformationFlows
Chapter 25. Complete::InformationFlows

The InformationFlows package provides mechanisms for specifying exchanges of information between active
entities of a system at a high level of abstraction. Information flows describe circulation of information in a system in
a general manner. They do not specify the nature of the information (type, initial value), nor the mechanisms by
which this information is conveyed (message passing, signal, common data store, parameter of operation, etc.). They
also do not specify sequences or any control conditions. It is intended that, while modeling in detail, representation
and realization links will be able to specify which model element implements the specified information flow, and how
the information will be conveyed.
The InformationFlows package depends on the Foundation::Kernel package.
Kernel
(from Foundation)
InformationFlows
Figure 25-105. Dependencies of the Complete::InformationFlows package
InformationFlows.fm Version 2 beta R1
485
Classifier
+conveyed
(f rom Kernel)
Relationship
isAbstract : Boolean = false 1..*

isLeaf : Boolean = false
+represented
(f rom Kernel)
*
+realization
+abstraction
*
+representation
InformationItem
*
InformationFlow
Figure 25-106. InformationFlows metamodel
InformationFlow
Description
An "Information Flow" specifies that one or several information items circulate from its sources to its targets.
Attributes
None.
Associations
realization : Relationship [*] : determines which Information Channels will realize the specified flow
conveyed : Classifier [1..*] : specifies the information items that may circulate on the current information flow.
Constraints
[1] the sources and targets of the information flow can only be of the following kind : Actor, Node, Use Case, Artifact, Class, Subsystem, Component, Port, Part, Interface, Package, and InstanceSpecification except when its
classifier is a relationship (i.e. it represents a link).
Note: Package is still under discussion. Is subsystem is sufficient? Packages, if used as a source or target
of an information flow, represents all instances of the contained or imported classifiers. One aspect is that a
partition can represent a package, and it should be consistent
[2] The sources and targets of the information flow must conform with the sources and targets or conversely the target and sources of the realization relationships, if any.
486
InformationItem
[3] An information flow can only convey classifiers that are allowed to represent an information item. (see constraints on InformationItem)
Semantics
An information flow is an abstraction of a communication of an information item from its sources to its targets. It is
used to abstract the communication of information between entities of a system. Sources or targets of an information
flow designate sets of objects that can send or receive the conveyed information item.
As a shorthand, one can directly specify that an information flow conveys a more concrete classifier than Information Item, such as for example a class.
Notation
An information flow is represented as a dependency, with the keyword <<flow>>.
E m p lo ye e
< < flo w > >
p ro d u c t
C u s to m e r
< < flo w > >
Com pany
wage
Figure 25-107. Example of information flows conveying information items

InformationFlow does not exist in UML 1.4.
InformationItem
An information Item is an abstraction of all kinds of information that can be exchanged between objects. It is a kind
of classifier intended for representing information at a very abstract way, which is not instanciable.
One purpose of Information Items is to be able to define preliminary models, before having taken detailed modeling
decisions on types or stuctures. One other purpose of information items and information flows is to abstract complex
models by a less precise but more general representation of the information exchanged betwen active parts of a system.
Attributes
Associations
represented : Classifier [*] : determines the UML classifiers that will specify the structure and nature of the information. An information item represents all its represented classifiers.
Constraints
[4] The sources and targets of an information item (its related information flows) must designate subsets of the
sources and targets of the representation information item, if any.The Classifiers that can realize an information
item can only be of the following kind : Class, Subsystem, Interface, InformationItem, Signal, Component.
487
InformationItem
[5] An informationItem has no feature, no generalization, and no associations.

[6] It is not instanciable
Semantics
"Information" as represented by an information item encompasses all sorts of data, events, facts that are exploited
inside the modeled system. For example, the information item "wage" can represent a Salary Class, or a bonus Class
(see example Figure 25-109). An information Item does not specify the structure, the type or the nature of the represented information. It specifies at an abstract level the elements of information that will be exchanged inside a system. More accurate description will be provided by defining the classifiers represented by information item.
Information items can be decomposed into more specific information item, using representation links between them.
This gives the ability to express that in specific contexts (specific information flows) a specific information is
exchanged.
Information Items cannot have properties, or associations. Specifying these detailed informations belongs to the
represented classifiers.
Notation
Being a classifier, an information item can be represented as a name inside a rectangle. The keyword information,
or the black triangle icon on top of this rectangle indicates that it is an information item.
< < in f o r m a t io n > >
wage
wage
Figure 25-108. Information Item represented as a classifier

Representation links between a classifier and a representation item are represented as dependencies with the keyword representation.
travel
document
<<representation>>
passport
<<representation>>
fly ticket
wage
Salary
<<representation>>
Bonus
<<representation>>
Figure 25-109. Examples of representation notation

An information item is usually represented attached to an information flow, or to an information channel realizing an information flow. When it is attached to an information flow (see Figure 25-107) its name is displayed close to
the information flow arrow. When it is attached to an information channel, a black triangle on the information channel
indicates the direction (source and target) of the realized information flow conveying the information itemp, and its
name is displayed close to that triangle. In the example Figure 25-111, two associations are realizing informations
flows. The black triangle indicates that an information flow is realized, and the information item name is displayed
close to the triangle.
488
InformationItem
The example Figure 25-110 shows the case of information items represented on connectors. When several information items having the same direction are represented, only one triangle is shown, and the list of information item
names, separated by a comma is presented.
The name of the information item can be prefixed by the names of the container elements, such as a container
information flow, or a container package or classifier, separated by a colomn.
b, d
m 1 :m y C 1
m 2 :m y C
Figure 25-110. Information item attached to connectors.
E m p lo y e e
e m p lo y e r
C u s to m e r
p r o v id e r
*
p ro d u c t
C om pany
*
wage
0 ..1
Figure 25-111. Information Items attached to associations
489
InformationItem
490
26 Complete::Models
Chapter 26. Complete::Models

The Models subpackage of Complete defines the Model construct that is available for organizing and managing
coherent sets of model elements. In this section it is necessary to distinguish between the physical system being
modeled (i.e., the subject of the model) and the elements that represent the physical system in a model.
Kernel
(from Foundation)
Models
Figure 26-112. Dependencies of the Complete::Models package
Models.fm Version 2 beta R1
491
26 Complete::Models
Package
(from Kernel)
Model
viewpoint : String
Figure 26-113. The Model class defined in the Models package.
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.
Description
The Model construct is defined as a Package. It contains a (hierarchical) set of elements that together describe the
physical system being modeled. A Model may also contain a set of elements that represents the environment of the
system, typically Actors, together with their interrelationships, such as Associations and Dependencies
Attributes
viewpoint : String [*]
The name of the viewpoint that is expressed by a model (This name may refer to
a profile definition).
Associations
Constraints
Semantics
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.
Thus, a model is an abstraction of a physical system. It specifies the physical system from a certain vantage
point (or viewpoint), i.e. for a certain category of stakeholders, e.g. 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, i.e. within the given level of
abstraction and vantage point, are represented in the model. Furthermore, it describes the physical system only
once, i.e. there is no overlapping; no part of the physical system is captured more than once in a model.
492
26 Complete::Models
Model
A model owns or imports all the elements needed to represent a physical system completely according to the
purpose of this particular model. The elements are organized into a containment hierarchy where the top-most package or subsystem represents the boundary of the physical system. It is possible to have more than one containment
hierarchy within a model, i.e. 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 elements describing relevant parts of the systems 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
elements and the elements representing the physical system may be associated with each other.
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. Typically different models are complementary and
defined from the perspectives (viewpoints) of different system stakeholders. 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.
Models can have refinement or mapping dependencies between them. These are typically decomposed into
dependencies between the elements contained in the models. 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.
Notation
A model is notated using the ordinary package symbol (a folder icon) 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.
A model is notated as a package, using the ordinary package symbol with the keyword model placed above the
name of the model.
Examples
Client tier
Business
tier
Data tier
Figure 26-114. Three models representing parts of a system.
493
26 Complete::Models
Model
model
OrderEntry
Analysis
Model
Design
Model
Figure 26-115. Two views of one and the same physical system collected in a container model.
There is no change with respect to UML 1.4.
494
27 Complete::ProtocolStateMachines
Chapter 27. Complete::ProtocolStateMachines

State machines can be used to express the behavior of an object, as described in the Chapter 19, Common::StateMachines. This chapter is focused on the use of state machines to express a usage protocol. Protocol state machines
express the legal transitions that a classifier can trigger. The state machine notation is a convenient way to define a
lifecycle for objects, or an order of the invocation of its operation. Because protocol state machines do not preclude
any specific behavioral implementation, and inforces legal usage scenarios of classifiers, interfaces and ports can be
associated to this kind of state machines.
Ports
(from Common)
StateMachines
(from Common)
Components
(from Common)
ProtocolState
Machines
Figure 27-116. Dependencies of the Complete::ProtocolStateMachines package
ProtocolStateMachines.fm Version 2 beta R1September 9, 2002 11:31 am
495

+specificMachine [source, owner]
Port
(from Ports)
Port
StateMachine
(from StateMachines)
1
+conformance
[ ownedElement]
0..1
+protocol
1
Interface
0..1
0..1
+generalMachine [ target ]
+ownedBehavior
[feature, ownedMember, ownedBehavior]
0..1
+specifyingStateMachine
[ ownedBehavior]
Interface
(from Interfaces)
ProtocolConformance
ProtocolStateMachine
0..1
Component
(from Components)
Figure 27-117. Protocol state machines
Operat ion
+referred
Transition
*
Transit ion
0..1
0..1
+postCondition [ownedElement]
0..1
State
State
+preCondition [guard]
Constraint
(from Kernel)
0..1
+stateInvariant
[ownedElement]
0.. 1
0..1
Figure 27-118. Constraints
Interface is defined as a specialization of the general Interface, adding an association to a protocol state machine.
Description
Since an interface specifies conformance characteristics, it does not own detailed behavior specifications. Instead,
interfaces may own a protocol state machine that specifies event sequences and pre/post conditions for the operations
and receptions described by the interface.
Associations
ownedBehavior: ProtocolStateMachine [0..1]

References a protocol state machine specifying the legal sequences of the invoca-
496
Port
tion of the behavioral features described in the interface. (Specializes Classifier.feature, Namespace.ownedMember, and BehavioredClassifier.ownedBehavior.)
Semantics
Interfaces can specify behavioral constraints on the features using a protocol state machine (see ProtocolStateMachine on page 501). A classifier realizing an interface must comply with the protocol state machine owned by the
interface.
Interfaces can own a protocol state machine.
Port
Port is defined as a specialization of the general Port, adding an association to a protocol state machine.
Associations
protocol: ProtocolStateMachine [0..1]

References an optional protocol state machine which describes valid interactions
at this interaction point.
Semantics
The protocol references a protocol state machine (see ProtocolStateMachine on page 501) that describes valid
sequences of operation and reception invocations that may occur at this port.
ProtocolConformance
Description
Protocol state machines can be redefined into more specific protocol state machines, or into behavioral state
machines. Protocol conformance declares that the specific protocol state machine specifies a protocol that conforms
to the general state machine one, or that the specific behavioral state machine abide by the protocol of the general
protocol state machine.
A protocol state machine is owned by a classifier. The classifiers owning a general state machine and an associated specific state machine are generally also connected by a generalization or a realization link.
Associations
specificMachine: StateMachine [1] :

Specifies the state machine which conforms to the general state machine.
generalMachine: ProtocolStateMachine [1] :

Specifies the protocol state machine to which the specific state machine conforms.
Constraints
[1] The general state machine must be a protocol state machine.
497
ProtocolTransition
Semantics
Protocol conformance means that every rule and constraint specified for the general protocol state machine (state
invariants, pre and post conditions for the operations referred by the protocol state machine) apply to the specific protocol or behavioral state machine.
In most cases, there are relationships between the classifier being the context of the specific state machine and
the classifier being the context of the general protocol state machine. Generally, the former specializes or realizes the
later. It is also possible that the specific state machine is a behavioral state machine that implements the general protocol state machine, both state machines having the same class as a context.
ProtocolTransition
Description
A protocol transition specifies a legal transition for an operation. Transitions of protocol state machines have the following information: a pre condition (guard), one triggering event, and a post condition. Every protocol transition is
associated to zero or one operation (referred BehavioralFeature) that belongs to the context classifier of the protocol
state machine.
The protocol transition specifies that the associated (referred) operation can be called for an instance in the origin
state under the initial condition (guard), and that at the end of the transition, the destination state will be reached
under the final condition (post).
Associations
\referred: Operation[0..*]
This association refers to the associated operation. It is derived from the operation of the trigger call event when applicable.
postCondition: Constraint[0..1] Specifies the post condition of the transition which is the condition that should
be obtained once the transition is triggered. This post condition is part of the post
condition of the operation connected to the transition.
preCondition: Constraint[0..1] Specifies the precondition of the transition. It specifies the condition that should
be verified before triggering the transition. This guard condition added to the
source state will be evaluated as part of the precondition of the operation refered
by the transition if any.
Constraints
[1] A protocol transition always belongs to a protocol state machine.
container.belongsToPSM()
[2] A protocol transition never has associated actions.

effect->isEmpty()
[3] If a protocol transition refers to an operation (i. e. has a trigger call event corresponding to an operation), then that
operation should apply to the context classifier of the state machine of the protocol transition.
[1] The operation belongsToPSM () checks if the region belongs to a protocol state machine
context Region::belongsToPSM () : Boolean
result = if not stateMachine->isEmpty() then
oclIsTypeOf(ProtocolStateMachine)
else if not state->isEmpty() then
state.container.belongsToPSM ()
else false
498
ProtocolTransition
Semantics
No "effect" action
The effect action is never specified. It is implicit, when the transition has a call event: the effect action will be the
operation specified by the call event. It is unspecified in the other cases, where the transition only defines that a given
event can be received under a specific state and pre-condition, and that a transition will lead to another state under a
specific post condition, whatever action will be made through this transition.
Unexpected event reception
The interpretation of the reception of an event in an unexpected situation (current state, state invariant, and pre-condition) is a semantic variation point: the event can be ignored, rejected or differed, an exception can be raised, or the
application can stop on an error. It corresponds semantically to a pre-condition violation, for which no predefined
behavior is defined in UML.
Unexpected behavior
The interpretation of an unexpected behavior, that is an unexpected result of a transition (wrong final state or final
state invariant, or post condition) is also a semantic variation point. However, this should be interpreted as an error of
the implementation of the protocol state machine.
Equivalences to pre and post conditions of operations
The protocol transition can always be translated into pre and post conditions of the associated operation.
For example, the transition in Figure 27-119 specifies that:
1.
2.
the operation "m1" can be called on an instance when it is in the state S1 under the condition C1,
when m1 is called in the state S1 under the condition C1, then the final state S2 must be reached under the condition C2.
This can be translated into the following pre and post conditions of the operation m1:
[C1]m1/[C2]
S1
S2
Figure 27-119. Example of a protocol transition associated to the "m1" operation

Operation m1()
Pre: S1 is in the configuration state and C1
Post: if the initial condition was S1 is in the configuration state and C1 then S2 is in the configuration state and C2.
Operations referred by several transitions
[C1]m1/[C2]
S1
S2
[C3]m1/[C4]
S3
S4
Figure 27-120. Example of several transitions referring to the same operation
499
ProtocolTransition
In a protocol state machine, several transitions can refer to the same operation as illustrated below. In that case, all pre
conditions and post conditions will be combined in the operation pre condition as below:
Operation m1()
Pre: S1 is in the configuration state and C1
or
S3 is in the configuration state and C3
Post:
if the initial condition was S1 is in the configuration state and C1

then S2 is in the configuration state and C2
else
if the initial condition was S3 is in the configuration state and C3
then S4 is in the configuration state and C4
A protocol state machine specifies all the legal transitions for each operation refered by its transitions. This means
that for any operation refered by a protocol state machine, the part of its precondition relative to legal initial or final
state is completely specified by the protocol stat machine.
Unreferred Operations
If an operation is not referred by any transition of a protocol state machine, then the operation can be called for any
state of the protocol state machine, and does not change the current state.
Using events in protocol state machines
Apart from the operation call event, events are generally used for expressing a dynamic behavior interpretation
of protocol state machines. An event which is not a call event can be specified on protocol transitions.
In this case, this specification is a requirement to the environment external to the state machine : it is legal to
send this event to an instance of the context classifier only under the conditions specified by the protocol state
machine.
Just like call event, this can also be interpreted in a dynamic way, as a semantic variation point.
Notation
The usual state machine notation applies (see "transition"). The difference is that no actions are specified for protocol
transitions, and that post conditions can exist. Post conditions have the same syntax as guard conditions, but appear at
the end of the transition syntax.
[pre condition] event/[post condition]
Figure 27-121. Protocol transition notation
500
State (extended)
State (extended)
Description
The states of protocol state machines are exposed to the users of their context classifiers. A protocol state represents
an exposed stable situation of its context classifier: when an instance of the classifier is not processing any operation,
users of this instance can always know its state configuration.
Associations
stateInvariant: Constraint [0..1]Specifies conditions that are always true when this state is the current state. In
protocol state machines, state invariants are additional conditions to the preconditions of the outgoing transitions, and to the postcondition of the incoming transitions.
Constraints
[1] A Protocol state (state belonging to a protocol state machine) has no entry or exit or do activity actions.
entry->isEmpty() and
exit->isEmpty() and
doActivity->isEmpty()
[2] Protocol states cannot be deep or shallow history pseudo states.

if oclIsTypeOf(Pseudostate) then (kind <> #deepHistory) and (kind <> #shallowHistory)
Notation
The two differences that exist for state in protocol state machine, versus states in behavioral state machine, are as follow : Several features in behavioral state machine do not exist for protocol state machines (entry, exit, do); States in
protocol state machines can have an invariant. The textual expression of the invariant will be represented by placing
it after or under the name of the state, surrounded by square braquets.
Ty ping
P asswo rd
[invariant expr]
Figure 27-122. State with invariant - notation
In addition to expressing the behavior of a part of the system, state machines can also be used to express the usage
protocol of part of a system. These two kinds of state machines are referred here as behavioral state machines and
protocol state machines.
Behavioral state machines are described in Chapter 19, Common::StateMachines.
Description
A protocol state machine is always defined in the context of a classifier. It specifies which operations of the classifier
can be called in which state and under which condition, thus specifying the allowed call sequences on the classifiers
operations. A protocol state machine presents the possible and permitted transitions on the instances of its context
classifier, together with the operations which carry the transitions. In this manner, an instance lifecycle can be created
for a classifier, by specifying the order in which the operations can be activated and the states through which an
instance progresses during its existence.
501
Attributes
Associations
conformance: ProtocolConformance[*] : Conformance between protocol state machines.
Constraints
[1] A protocol state machine must only have a classifier context, not a behavioral feature context
[2] All transitions of a protocol state machine must be protocol transitions.
let stateHaveOnlyProtocolTransition : subvertex->select(s : State |
s.contents.transitions.oclIsTypeOf(ProtocolTransition) and
s.contents.stateHaveOnlyProtocolTransition)
region.stateHaveOnlyProtocolTransition and
region.transitions.oclIsTypeOf(ProtocolTransition)
[3] If two ports are connected, then the protocol state machine of the required interface (if defined) must be conformant to the protocol state machine of the provided interface (if defined).
Semantics
Protocol state machines help defining the usage mode of the operations and receptions of a classifier by specifying:
in which context (under which states and pre conditions) they can be used
if there is a protocol order between them
what result is expected from their use
Using pre and post conditions on operations is a technique well suited for expressing such specifications. However,
pre and post conditions are expressed at the operation level, and therefore do not provide a synthetic overview at the
classifier level. Protocol state machines provide a global overview of the classifier protocol usage, in a simple formal
representation. Protocol state machines may not express all the pre- and postconditions of operations. In that case,
additional pre- or postconditions can be added at the operation level. Formally, the pre condition of an operation will
be the addition (logical "and") of the constraint defined as pre condition of the operation, if any, to the constraint
deduced from the protocol state machine if any. The same applies to the post condition of an operation.
The protocol state machine defines all allowed transitions for each operation. The protocol state machine must
represent all operations that can generate a given change of state for a class. Those operations that do not generate a
transition are not represented in the protocol state machine.
Protocol state machines constitute a means to formalize the interface of classes, and do not express anything
except consistency rules for the implementation or dynamics of classes.
Protocol state machine interpretation can vary from:
1.
2.
Declarative protocol state machines that specify the legal transitions for each operation. The exact triggering
condition for the operations is not specified. This specification only defines the contract for the user of the context classifier.
Executable protocol state machines, that specify all events that an object may receive and handle, together with
the transitions that are implied. In this case, the legal transitions for operations will exactly be the triggered transitions. The triggering call event specifies the effect action, which is the call of the associated operation.
The representation for both interpretations is the same, the only difference being the direct dynamic implication that
the interpretation 2 provides.
Elaborated forms of state machine modeling such as compound transitions, sub-statemeachines, composite states
and concurrent regions can also be used for protocol state machines. For example, concurrent regions make it possi-
502
ble to express protocol where an instance can have several active states simultaneously. Sub-state machines and compound transitions are used as in behavioral state machines for factorizing complex protocol state machines.
A classifier may have several protocol state machines. This happens frequently, for example, when a class inherits several parent classes having protocol state machine, when the protocols are orthogonal. An alternative to multiple
protocol state machines can always be found by having one protocol state machine, with sub-state machines in concurrent regions.
Notation
The notation for protocol state machine is very similar to the one of behavioral state machines. The keyword {protocol} placed close to the name of the state machine differentiates graphicaly protocol state machine diagrams.
.
Door {protocol}
[doorWay->isEmpty] Close/
opened
closed
create/
open/
lock/
unlock/
locked
Figure 27-123. Protocol state machine - notation
503
504
28 Complete::Subsystems
Chapter 28. Complete::Subsystems

The Subsystems subpackage of the Complete package specifies the subsystem construct that is used to define architectural units within complex systems. These are typically software systems, but may also be hardware systems or
organizational systems. In particular, the package specifies how a complex system can be broken down recursively
into smaller subsystems, and eventually into instantiable components and other executable classifiers.
A subsystem is characterized by partitioning its elements into specification elements and realization elements.
The specification elements within a subsystem are those that are boundary elements to any external clients that interact with that subsystem. The realization elements constitute the internal elements that implement the specified functionality but do not interact with external elements directly.
Kernel
(from Foundation)
Components
(from Common)
Subsystems
Figure 28-124. Dependencies of the Complete::Subsystems package
Subsystems.fm Version 2 beta R1
505
Component
(from Components)
Subsystem
0..1
0..1
[memb er]
+specificationElement
{ default value:
instantiation = indirect}
[memb er]
+realizationElement
Autono mousElemen t
(from Kernel)
{ for every realizationElement there are

(optionally) one or more Realization
Dependencies from realizationElements to it either at the element level or the feature level }
Figure 28-125. The Subsystem class.
Subsystem
A subsystem is a grouping of model elements that represents a behavioral unit in a system. A subsystem is a kind of
component, and as such it has an explicit interface in terms of ports and can be plugged into a system by means of
connectors. In addition, a subsystem is a wider organizational unit for general model elements. The model elements
of a subsystem are partitioned into specification and realization elements, where the former are realized through mapping relationships by the latter. For instance, a set of use cases or activities that are contained within a subsystem as
its specification elements may be realized by a set of interactions that are realization elements.
Description
In the metamodel, Subsystem is a subclass of Component. As such it may have a set of public Features in the form of
Ports that are typed by Interfaces. It also has internal Parts and Connectors. A Subsystem has specificationElements
and realizationElements which are AutonomousElements contained within the Subsystems namespace. The default
value for the instantiation attribute inherited from Component is indirect: a Subsystem is most commonly not
instantiated directly at execution time.
506
Subsystem
Attributes
Associations
specificationElement : AutonomousElement [*]

The elements that define the external specification of the Subsystem as visible to
clients of the Subsystem. These typically are constituted of Interfaces and Behavior specifications., e.g. protocol State Machines, Activities.
The association is a specialization of the member association between
realizationElement : AutonomousElement [*]

The elements that define the internal implementation of the Subsystems specification. These elements are nbormally not visible to external clients of the Subsystem.
The association is a specialization of the member association between
Constraints
[1] For every specificationElement there are (optionally) one or more DelegationConnectors to realizationElements,
or there are Realization Dependencies from realizationElements to it. These Dependencies are defined between
the AutonomousElements themselves or between their Features or ownedMembers.
[2] Any Interface that is the type of a Port, and any protocol StateMachine of a Subsystem are specificationElements
of that Subsystem and are owned or imported by its namespace.
[3] Any Classifier that is the type of a Part, and any Associations that are the type of a Connector of a Subsystem are
realizationElements of that Subsystem and are owned or imported by its namespace.
Semantics
The purpose of the subsystem construct is to provide a grouping mechanism for specifying a behavioral unit of a system. A subsystems contained elements have more cohesion and interaction with other elements within the same subsystem, and less with elements in external subsystems. The contents of a subsystem are defined by its element
ownership and element import associations defined by the subsystems namespace.
A subsystem exposes an interface in terms of elements that are visible from the outside. As a kind of component,
such an interface can be specified in terms of ports and interfaces and optionally protocol state machines to specify
dynamic constraints on the interface. The realization of those interfaces is specified by connectors between the external interfaces and internal classes. As a subsystem, the definition of an interface is extended to more general specification elements that can be any packageable element. For instance, in addition to a set of interfaces, a subsystem
may define a set of use cases as its specification elements.
The specification elements are used for giving an abstract specification of the behavior offered by the realization
elements. Since the subsystem itself typically 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 collection of realization elements
model the interior of the behavioral system unit. 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 correspondence between the specification and the realization of a subsystem can be specified in several
ways, including connectors and realize dependencies. An example of the former are interfaces implemented by
internal classes. An example of the latter is where the realization of a set of use cases may be one or more collaborations with associated interactions. A stimulus received by an instance of a use case corresponds to an instance conforming to one of the classifier roles in the collaboration receiving that stimulus.
There are two ways of communicating with a subsystem, either by sending stimuli to the subsystem itself (indicated by instantiation = direct) to be re-directed to the proper recipient inside the subsystem, or by sending stimuli
507
Subsystem
directly to the recipient inside the subsystem (indicated by instantiation = indirect or instantiation = none). Note
that all behavior specified for the subsystem is performed by instances contained in the subsystem instances, not by
the subsystem instances themselves.
In the case of direct instantiation, an association is defined with the subsystem itself or its direct ports to enable
stimuli sending. In the second case, communicating with a subsystem by sending stimuli directly to instances within
the subsystem may require that the classifiers of these instances are available within the senders namespace through
importing.
A subsystem can have generalizations to other subsystems. This means that the public and protected elements in
the contents of a subsystem 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. This may not be true for abstract subsystems.
Notation
A subsystem is notated by a component classifier symbol, with the usage of a fork symbol placed in the upper right
corner of the large rectangle. The name of the subsystem is placed within the large rectangle. Optionally, especially if
contents of the subsystem are shown within the large rectangle, the subsystem name is placed in a separate header
compartment.
The large rectangle has two lower compartments, one for each of the subsets representing specification elements
and realization elements. These are usually shown by dividing the rectangle by a vertical line, with the specification
elements in the left hand side compartment, and the realization elements in the right hand side compartment. The
compartments may be labeled with the keywords specification and realization respectively, to avoid potential
ambiguity.
subsystem
Security Management
realization
specification
VerifyAccess
[use case]
Capability
DefineAccess
[use case]
Read Log
[use case]
User
Registration
GainAccess
[interaction]
IntruderDetection
[activity]
Figure 28-126. Example notation of a subsystem with specification and realization elements.
A subsystem that is not contained in any other subsystem, may be labeled with the keyword system.
The mapping from the realization part to the specification part may be optionally made explicit by using Realization or Connector arrows. 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.
508
28.2 Diagrams
The fork symbol may be replaced or complemented by the keyword subsystem placed above the name of the subsystem.
One or more of the compartments may be collapsed or 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.
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.
Examples
To be added.
The following changes from UML 1.x have been made: Subsystems are a kind of Components such that, if desired,
they can have well-defined interfaces and can be wired together in the context of components and other subsystems.
28.2. Diagrams
In UML 2.0, Subsystems are modeled on Static Structure diagrams, showing graphs of interacting subsystems with
dependencies or connectors between.
509
28.2 Diagrams
510
28.2 Diagrams
511
28.2 Diagrams
512
29 Complete::Templates
Chapter 29. Complete::Templates

The Templates subpackage of the Structure package specifies how Classifier can be parameterized with Classifier,
ValueSpecification and Feature template parameters.
Kernel
(from Foundation)
Dependencies
(from Basic)
Templates
Figure 29-127. Dependencies of the Complete::Templates package
Templates.fm Version 2 beta R1
513
Clas s ifier
Nam edE lem ent
(fro m K e rn e l )
(fro m K e rn e l )
+ default
+ t em plateP ar amet er
[ownedMem b er]
+ form al
[ sour c e]
Cl as s i fier
1
+ derivation
[ownedE lem ent]
0.. 1
0.. *
0..1
+ deri vedCl ass i fier

[owner, c lient]
P aram eterableE leme nt
+ ac tual
[target]
+ tem plate
[s upplier]
0..1
+ binding
[owne dE lem ent]
Derivation
B i ndi ng
1..*
Dependenc y
Relations hip
(fro m De p e n d e n ci e s)
(fro m K e rn e l )
Figure 29-128. Classifier with template parameters and bindings.
P aram eterableElem ent
Cl as si fier
V alueSpec ification
A t tribute
Part
Operation
0..1
+typeCons traint
V alueSpec ification
Attribute
Part
Operation
(fro m K e rn e l)
(from Ke rn el )
(fro m In te rna l S t ru cture )
(from K e rn el )
Figure 29-129. Template parameters
514
An attribute template parameter represents an attribute defined in the namespace enclosing the derived classifier.
Constraints
[1] A binding of an attribute template parameter must be to an attribute.
[2] If template parameter constraints apply, then the type of the actual attribute must be of the same type as the formal attribute template parameter.
Semantics
An attribute template parameter is within the template classifier a representative for an (actual) attribute defined in
the namespace enclosing the derived classifier, and can be used as such.
Binding
A binding represents the binding between a formal and actual parameter as part of a derivation. The actual parameter
must of the same kind as the formal parameter, e.g. the actual parameter for a classifier template parameter must be a
classifier.
Associations
formal: ParameterableElement The formal template parameter that is bound by this binding.
actual: ParameterableElement The actual element for the formal of this binding.
Constraints
[1] The actual parameter must of the same kind as the formal parameter, e.g. the atual parameter for a classifier template parameters must be a classifier. As classifier template parameter is abstract, the constraint applies to the
concrete classifier template parameters. e.g. the actual parameter to a class template parameter must be a class
and the actual parameter to a signal template parameter must be a signal.
Semantics
A derived classifier will be specified by the model elements of the template classifier, with each formal template
parameter replaced by the corresponding actual parameter as specified in the binding.
Classifier is extended so that it may have template parameters, be a derived classifier, and so that it may be a template
parameter. A classifier with template parameters is called a template classifier, while a classifier as template parameter is called a classifier template parameter.
Template parameters and derivation applied to the abstract Classifier imply that they also apply to the following
kinds of Classifiers: Class, Component, Collaboration, Datatype, Interface, all kinds of Behavior and Signal.
Associations
templateParameter : ParameterableElement [0..*]

The elements that are template parameters to this template Classifier.
derivation: Derivation [0.. 1]
An eventual derivation, implying that the owning classifier is a derivation of the

template classifier of the derivation.
515
Constraints
[1] Classifier with template parameters and derivation applies to the following kinds of classifiers: Class, Collaboration, Component, Datatype, Interface, Signal and all kinds of Behaviors. As Classifier with Derivation is
abstract, each Derivation yields a concrete Classifier of the same kind as the concrete template Classifier, e.g. a
Class can only be derived from a template Class and a Collaboration can only be derived from a template Collaboration.
[2] Classifier as template parameter applies to the following kinds of classifier: Class, Component, Datatype, Interface, different kinds of Behaviors and Signal.
Semantics
A classifier template is a classifier that is parameterized over classifiers, values and features.
A template parameter is defined in the namespace of the template classifier, but the template parameter represents a model element which is defined in the context of the derivation
A classifier can be a derivation of a template classifier. This is represented by the derived classifier having a derivation.
A classifier template can only be used to derive classifiers, i.e. it cannot be used as the type of a feature or as a
general classifier in a generalization.
A derived classifier is an ordinary classifier and can be used in models where a classifier may be used, i.e. a
derived class can be used as the type of a features and a derived collaboration can be used to define a collaboartion
occurrence. A derived classifier can be used directly as e.g. the type of a feature, that is if only one feature has this
derived classifier as type, there is no reason to define a derived classifier and then use this as the type.
A classifier as a template parameter can in the template classifier be used as any other classifier defined in the
namespace of the template classifier, e.g. as the type of features. In a classifier derived from the template classifier,
any use of the template classifier will be the use of the actual classifier.
If template parameter constraints appply, then the actual classifier is constrained as follows:
if the classifier template parameter has a generalization, then an actual classifier must have generalization with
the same general classifier
if the classifier template parameter has a substitution, then an actual classifier must have a substitution with the
same contract
if the classifier template parameter has neither a generalization nor a substitution, then an actual classifier can be
any classifier.
If template parameter constraints do not appply, then an actual classifier can be any classifier.
Notation
A small dashed rectangle is superimposed on the upper right-hand corner of the rectangle for the template classifier.
The dashed rectangle contains a parameter list of formal template parameters. The list must not be empty, although it
might be suppressed in the presentation. The name, attributes, operations and internal structure of the template classifier appear as normal in the corresponding compartments.
The template parameter list may be comma-separated template-parameters, or it may be one per line.
template-parameter ::= [ { parameter-kind }] {parameter [: constraint] [:: default]
parameter-kind ::=
class | component | type | interface |signal |value |operation |attribute |part |class |
parameter ::= parameter-name | operation-name ( parameter-list )
516
Derivation
constraint ::= [{contract }] classifier-name

default ::= classifier-name | expression | attribute-name | part-name | operation-name
If the parameter-kind is omitted, then parameter-kind is class.
The classifier-name of constraint designate the type constraint of the parameter. The contract option only
applies to classifier template parameter, and indicates that the actual parameter
must be a classifier that may substitute the classifier designated by the classifiername. A classifier template parameter with a constraint but without contract
indicates that the actual classifier must be a specialization of the classifier designated by the classifier-name.
The expression in default is a string designating an Expression for a default value that is used when the corresponding actual parameter is omitted in a binding.
Derivation
A classifier can be derived from a template classifier by replacing formal template parameters with actual parameters.
Associations
template : Classifier [1]
The template classifier being the basis for the derivation.
binding : Binding [1..*]
The bindings of this derivation
Constraints
[1] The template Classifier must have template parameters.
Semantics
A derived classifier will have all the model elements of the template classifier, with each formal template parameter replaced by the corresponding actual parameter as specified in the bindings of the derivation. Although a derived
classifier will have all these model elements, only the classifier with the expression of the derivation is part of the
model.
It is a semantic variation point
if all formal parameters are bound as part of a derivation (complete binding), or
if only a subset may be bound (partial binding).
In case of complete binding, the derived classifier may add template parameters, and these template parameters
can be actual parameters of the derivation. In case of partial binding, the unbound template parameters are template
parameters of the derived classifier.
A derived classifier may have properties in addition to those fof the template classifier. In this case the derived
classifier is defined to be a specialization of an anonymous general classifier represented by the derivation.
Notation
A derived classifier has the same graphical notation as a classifier. The name compartment contains a string with the
following syntax:
classifier-name: classifier-expression
where classifier-expression is defined to be:
517
template-classifier-name < {template-parameter-binding}* >

Here template-parameter-binding has the following syntax:
template-parameter-name :: actual-template-parameter
The syntax of actual-template-parameter depends upon the kind of parameter:
classifier template parameter: classifier name
value specification template parameter: expression string
attribute template parameter: attribute name
part template parameter: part name
operation template parameter: operation name
When a derived classifier is used directly as the type of an attribute, then <classifier expression> acts as the type of
the attribute in the notation for an attribute:
[visibility] [/] name [: type] [multiplicity] [= default] [{ property-string }]

When a derived classifier is used directly as the type of a part, then classifier-expression acts as the classname of the
part in the notation for a part:
{{ [ name ] : classname } | name } [ [ multiplicity ] ]
The derivation is metamodeled in the same way as generalization, i.e. the derived classifier has a derivation.
While UML 1.4 has model element in general having template parameters, here only classifiers can have template
parameters.
An operation template parameter represents an operation defined in the namespace enclosing the derived classifier.
Constraints
[1] The default parameter must be an operation with a signature in terms of parameters that is compatible with the
signature of the formal operation.
[2] The actual operation must have a signature in terms of parameters that is compatible with the signature of the formal operation.
Semantics
Within a template classifier an operation template parameter may be used as any other operation defined in an enclosing namespace. In a derived classifier such a call will be a call to actual operation.
ParameterableElement
A parameterable element is an element that can be a template parameter. A formal template parameter represents
another element of the same kind. As part of a derivation, a binding relates a formal template parameter to an
actual element defined in the namespace enclosing the derived classifier.
518
Part (extended)
Associations
default: ParameterableElement [0..1]
A possible default actual parameter for a template parameter.
Constraints
[1] The default parameter must of the same kind as the formal parameter, e.g. the default for for classifier template
parameter must be a classifier.
Semantics
As a representative of another element, a template parameter is meaningful only within the template (it may not be
used in other parts of the model).
In addition to the constraint that an actual parameter must be of the same kind as the formal parameter, each kind
of template parameter may have a specified constraint. How this is defined and the rules for when an actual parameter
fulfills the constraint is specified separately for each kind of template parameter.
In general, however, it is a semantic variation point if template parameter constraints apply or not:
If template parameter constraints apply, then within the template classifier a template parameter can only be used
according to its constraint, e.g. an operation template parameter can only be
called with actual parameters matching the constraint in terms of the signature
constraint of the operation template parameter. Applying constraints will imply
that a derived classifier is well-formed if the template classifier is well-formed
and if actual parameters comply with the formal parameter constraints.
If template parameter constraints do not apply, then within the template classifier a template parameter can be
used without being constrained, e.g. an operation template parameter will have
no signature in terms of parameters and it can be called with arbitrary actual
parameters. Not applying constraints provides more flexibility, but some actual
template parameters may not yield a well-formed derived classifier.
Notation
See notation for Classifier.
This corresponds more or less to the TemplateParameter of UML 1.4.
Part (extended)
A part template parameter represents a part defined in the namespace enclosing the derived classifier.
Constraints
[1] The default parameter must be a part.
[2] If constraints aplly, then the actual part must have a type that is the same or a subtype of the type of the formal
part template parameter.
Semantics
As the representative of a part in the namespace enclosing the derived classifier, a part template parameter can within
the template classifier be used as such. It it therefore only possibleto create objects in the set represented by the part,
it is not possible to connect part template parameters.
519
ValueSpecification (extended)
A value specification template parameter represents a value specification that is provided as part of a derivation. The
actual parameter is a value specification
Associations
typeConstraint : Classifier [0.. 1]The Classifier being the type constraint of the va template parameter.
Constraints
[1] If template parameter constraints apply, then the actual parameter must be a kind of value specification that has
the same type as the type constraint. An actual parameter may thus either be an expression or a literal specification, as long as the type is the same as the constraint type.
Semantics
A value specification template parameter can within the template classifier be used as a value specification. As part of
a derivation, the actual value specification is provided as a specification, i.e. in case the actual is an expression, the
expression it is not called. All occurrences within the template classifier of the value specification template parameter
will in the derived classifier be occurrences of the actual value specification.
Examples
T, {value} k : Integer
FA rray
c ontents : T [0..k ]
< < bind> > < T::A ddres s , k ::3>
FA rray < T:: P oint, k ::3>
A ddres s Lis t
Figure 29-130. Class FArray with unconstrained class template parameter T and avalue parameter k of type Integer
520
C a rE n g in e :E n g in e , v a lu e n :In te g e r
C ar
e :C a rE n g in e
d w :W h e e l[n + 1 ]
Figure 29-131. Class Car with class template parameter CarEngine constraint to be a subclass of Engine and a value
template parameter constrained to be of type Integer
D ie s e lC a r: C a r
< C a rE n g in e :: D ie s e lE n g in e , n :: 2 >
Figure 29-132. Derived Class

Note
Classifier templates as defined above cover parameterized Classes, Component, Datatypes, Collaborations and different kinds of Behavior (as Behavior is a kind of Classifier). This note clarifies what template parameters imply for
these different kinds of Classifiers, and it further relates to similar concepts in 1.4.
Class -, Component -and Datatype templates correspond parameteriezed classes/types in other languages. Most
programmming languages only provide types as template parameters, and some provide value template parameters.
These correspond to Class/Component/Datatype and ValueSpecification template parameters. The new things in
UML2.0 are the feature template parameters.
A Collaboration template will typically have the types of it parts as class template parameters. Consider the Collaboration in Figure 29-133.
Observer
Observer : SlidingBarIcon
Subject : CallQueue
Figure 29-133.
521
This Collaboration can be derived from a Collaboration template of the form found in Figure 29-134, by means
of the derivation in . We have here used that the default kind of template parameter is a class, i.e. SubjectType and
ObserverType are class template parameters
SubjectType, ObserverType
ObserverPattern
Observer : ObserverType
Subject : SubjectType
Figure 29-134. A Collaboration template, defining a observer pattern
Observer
ObserverPattern<Subject :: CallQueue, Observer :: SlidingBarIcon>
Figure 29-135. Observer derived from ObserverPattern
If the presentation option in is preferred,
Subject
CallQueue
queue: List of Call
source: Object
waitAlarm: Alarm
capacity: Integer
SlidingBarIcon
Observer
Observer
reading: Real
color: Color
range: Interval
Observer.reading = length (Subject.queue)

Observer.range = (0 .. Subject.capacity)
Figure 29-136. Presentation option for Collaborations
then the corresponding Collaboration template and derivation will be as in Figure 29-137 and Figure 29-138
(with a tentative syntax for binding).
522
SubjectType, ObserverType
SubjectType
ObserverType
Subject
ObserverPattern
Observer
Observer.reading = length (Subject.queue)

Observer.range = (0 .. Subject.capacity)
Figure 29-137. Presentation option applied toCollaboration template
Subject
CallQueue
queue: List of Call
source: Object
waitAlarm: Alarm
capacity: Integer
Observer
Observer: ObserverPattern
SlidingBarIcon
reading: Real
color: Color
range: Interval
Figure 29-138. Derived Collaboration with a tentative syntax

Note that the note attached to the ObserverPattern assumes that Observer has attributes reading and range. This is
not expressed in Figure 29-137. The Collaboration template is still a valid template, however, it will only be possible
to check that this note is in fact possible for a derived Collaboration. If it is desirable to check this already for the Collaboration template (and ensure that this holds for any derived Collaboration), then SubjectType and ObserverType
are given constraints by means of two classes, e.g. SubjectSignature and ObserverSignature. The class template
parameter SubjectType is then defined to have SubjectSignature either as a contract (in which case any claas with this
contract can be an actual parameter) or as a super class, in which case any subclass of SubjectSignature can be an
actual parameter. Similar for ObserverType.
A derived Collaboration is not the same as a CollaborationOccurrence, in fact parameterized Collaborations (and
derivation) can not express what CollaborationOccurrences can. Consider the Sale Collaboration in Figure 29-139. It
is defined by means of two Parts (Buyer and Seller) representing roles in this collaboration.
523
Sale
Buyer
Seller
Figure 29-139. The SaleCollaboration

The two CollaborationOccurrences wholesale and retail in Figure 29-140 can not be defined as derived Collaborations.
BrokeredSale
wholesale:
Sale
broker
Buyer
Seller
Seller
producer
retail:
Sale
Buyer
consumer
Figure 29-140.
A derived Collaboration is a Collaboration, while a CollaborationOccurrence is not. A CollaborationOccurrence

is defined by means of RoleBindings, binding Parts in a Collaboration (here Buyer and Seller) to Parts in another
classifier (here broker, produce and consumer in NrokeredSale) with the semantics that the interaction described in
Sale will occur between broler, producer and consumer. Binding eventual Buyer and Seller part template parameters
(of a Sale Collaboration template) to broker and producer would just provide that the Parts broker and producer are
visible within the derived Sale Collaboration. And anyway, even if Sale had two Part template parameters Buyer and
Seller, it could not use these for defining an internal structure as is the case in Figure 29-139. Parameters, by the very
nature, represent elements that are defined outside a Collaboration template and can therefore not be parts of an
internal structure of the Collaboration template.
524
Part IV. Diagrams

This part describes the diagrams types that are used to present UML. UML diagrams are graphs containing nodes,
connected by paths. As is shown in Figure 29-141, there are two major kinds of diagram types: structural diagrams
and behavioral diagrams.
Structural diagrams show the static structure of the objects in a system, including their classifiers, internal structure, and relationships to other entities. The classifiers that can be shown in a structural diagram include classes, components, interfaces, nodes, and data types. The elements in a structural diagram represent the meaningful concepts of
an application, and may include abstract, real-world and implementation concepts. For example, a structural diagram
for an airline reservation system might include classifiers that represent seat assignment algorithms, tickets, and a
credit authorization service.
Structural diagrams do not show the details of dynamic behavior, which are illustrated by behavioral diagrams.
However, they may show relationships to the behaviors of the classifiers exhibited in the structural diagrams.
Structural diagrams may be further classified into several other kinds, where the classification is based on the
predominant structure in the diagram: class diagrams, component diagrams, component deployment diagrams,
deployment diagrams, internal structure diagrams, and package diagrams. For example, a structural diagram that consists mostly of classes is called a class diagram. However, the notational boundaries between the various kinds of
structural diagrams are not strict; it is common to mix different types of structures in the various kinds of structural
diagrams. For example, a component diagram may emphasize components but it may also show implementation
classes associated with the components. Likewise, a package diagram may emphasize packages, but it may also show
components and classes that are grouped by the packages.
Behavioral diagrams show the dynamic behavior of the objects in a system, including their methods, collaborations, activities and state histories. The dynamic behavior of a system can be described as a series of changes to the
system over time. Behavioral diagrams can be further classified into several other kinds: activity diagrams, interaction diagrams, protocol state machine diagrams, state machine diagrams and use case diagrams.
D ia g ra m
B e h a v io ra l
D ia g ra m
S tru c tu ra l
D ia g ra m
Com ponent
D e p lo ym e n t
D ia g ra m
C la s s D ia g ra m
C om ponent
D ia g ra m
D e p lo ym e n t
D ia g ra m
In te rn a l
S tru c tu re
D ia g ra m
P ro to c o l S ta te
M a c h in e
D ia g ra m
Ac tiv ity
D ia g ra m
P ackage
D ia g ra m
In te ra c tio n
D ia g ra m
S equence
D ia g ra m
Use Case
D ia g ra m
S ta te M a c h in e
D ia g ra m
C o m m u n ic a tio n
D ia g ra m
Figure 29-141. The major kinds of structural and behavioral diagrams.

The purpose of each diagram type and the graphic contents of each diagram are described in the following chapters.
Part-Diagrams.fm Version 2 beta R1
525
29 Diagrams
Part-Diagrams.fm Version 2 beta R1
526
30 Activity Diagrams - Common
30.1 Description
Chapter 30. Activity Diagrams - Common

Activity diagrams depict behavior using a control and data-flow model. See Chapter 12, Common::Activities. This
chapter outlines the graphic elements that may be shown in activity diagrams, and provides cross references where
detailed information about the semantics and concrete notation for each element can be found. It also furnishes examples that illustrate how the graphic elements can be assembled into diagrams.
30.1. Description
The focus of activity modeling is the sequence and conditions for coordinating lower-level behaviors, rather than
which classifiers own those behaviors. These are commonly called control flow and object flow models. The behaviors coordinated by these models can be initiated because other behaviors finish executing, because objects and data
become available, or because events occur external to the flow. See the Activity on page -236 metaclass for more
introduction and semantic framework.
The following sections describe the graphic nodes and paths that may be shown in activity diagrams.
30.2. Graphic Nodes

The graphic nodes that can be included in structural diagrams are shown in Table 1.
Table 1: Graphic nodes included in activity diagrams
NODE TYPE
NOTATION
ActivityFinal
REFERENCE
See ActivityFinal on page -247.
ActivityNode
See ActivityInvocation, ControlNode, and ObjectNode.
See ActivityNode on page -251.
ControlNode
See DecisionNode, FinalNode,

ForkNode, InitialNode, JoinNode, and MergeNode.
See ControlNode on page -265.
See DecisionNode on page -266.
...
DecisionNode
FinalNode
FlowFinal
See ActivityFinal and FlowFinal.
See FinalNode on page -269.

See FlowFinal on page -270.
ActivityDiagrams-Common.fm Version 2 beta R1September 9, 2002 11:33 am
527
30.3 Graphic Paths

NODE TYPE
NOTATION
See ForkNode on page -272.
...
ForkNode
REFERENCE
InitialNode
See InitialNode on page -273.
InvocationNode
See InvocationNode on page -274.

name
See JoinNode on page -280.

...
JoinNode
See MergeNode on page -281.
...
MergeNode
ObjectNode
See ObjectNode on page -285 and its children.
30.3. Graphic Paths

The graphic paths that can be included in structural diagrams are shown in Table 2.
PATH TYPE
ActivityEdge
REFERENCE
See ControlFlow and ObjectFlow.
See ActivityEdge on page -244.
528
30.4 Other Graphical Elements

PATH TYPE
REFERENCE
ControlFlow
See ControlFlow on page -263.
ObjectFlow
See ObjectFlow on page -283.
30.4. Other Graphical Elements

Activity diagrams have graphical elements for containment. These are included in Table 3.
NOTATION
TYPE
REFERENCE
Activity
See Activity on page -236.

Activity name
...
...
See ActivityPartition on page -255.

Partition Name
ActivityPartition
...
(Partition Name)
invocation
529

TYPE
NOTATION
REFERENCE
See IterationActivityGroup on page -278.
testAtBegin/End
condition
structured
See StructuredActivityGroup on page

-292.
530
30.5 Examples
30.5. Examples
The following are examples of activty diagrams.
Design Part
Design
Engineer
ID Part
Requirement
Standard
Part Search
Use
Part
[part not
found]
[part provided]
Standards
Engineer
Provide
Required
Part
[else]
Design
Engineer
Standards
Engineer
Clarify
Requirements
[part
found]
Expert
part
search
[part
found]
[async]
Assign
standards
engineer
[async]
Specify
part mod
workflow
Review
Requirements
Schedule
part mod
workflow
[part not
found]
Review
Schedule
[cancel]
[reschedule]
[OK]
[async]
[async]
Provide
addtl part
mod info
Execute
part mod
workflow
[accept]
Research
production
possibility
[reject]
Figure 30-142. Part design workflow based on example from the Workflow Process Definition RFP
531
30.6 Changes from UML 1.x
Trouble Ticket
[cannot
reproduce
problem]
[recorded]
Record
Problem
Correct
Problem
Reproduce
Problem
[else]
[not recorded]
[can
reproduce
problem]
[duplication
of another
problem]
[known
problem
and solution]
Communicate
ID Problem
and
Resolution
Results
Verify
Resolution
[else]
Audit and
Record
Figure 30-143. Trouble ticket workflow based on example from the Workflow Process Definition RFP.
[order
rejected]
Fill
Order
Receive
Order
Ship
Order
Close
Order
[order
accepted]
Send
Invoice
Make
Payment
Accept
Payment
Invoice
Figure 30-144. Order processing example.
30.6. Changes from UML 1.x

Data flow is notated with a solid line.
Graphic nodes have small sub nodes attached on the sides for depicting inputs and outputs.
Round-sided rectangles are replaced with a round-cornered rectangle.
Chevron control icons are replaced with pentagons.
532
533
534
31 Activity Diagrams - Complete
31.1 Description
Chapter 31. Activity Diagrams - Complete

Activity diagrams depict behavior using a control and data-flow model. See Chapter 12, Common::Activities and
Chapter 21, Complete::Activities. This chapter outlines the graphic elements that may be shown in complete activity diagrams, and provides cross references where detailed information about the semantics and concrete notation for
each element can be found. It also furnishes examples that illustrate how the graphic elements can be assembled into
diagrams.
31.1. Description
The following sections describe the graphic nodes and paths that may be shown in complete activity diagrams.
31.2. Graphic Nodes

NODE TYPE
DataStore
NOTATION
<<datastore>>
REFERENCE
See DataStoreNode on page -437 .
31.3. Graphic Paths

There are no new graphic paths in complete activities.
31.4. Other Graphical Elements

Activity diagrams have graphical elements for containment. These are included in Table 5.
TYPE
NOTATION
REFERENCE
See InterruptibleActivityRegion on page
-438.
ActivityDiagrams-Complete.fm Version 2 beta R1September 9, 2002 11:33 am
535

TYPE
ParameterSet
NOTATION
REFERENCE
See ParameterSet on page -452.
536
31.5 Examples
31.5. Examples
The following are examples of activty diagrams.
Design Part
Design
Engineer
ID Part
Requirement
Standard
Part Search
Use
Part
[part not
found]
[part provided]
Standards
Engineer
Provide
Required
Part
[else]
Design
Engineer
Standards
Engineer
Clarify
Requirements
[part
found]
Expert
part
search
[part
found]
[async]
Assign
standards
engineer
[async]
Specify
part mod
workflow
Review
Requirements
Schedule
part mod
workflow
[part not
found]
Review
Schedule
[cancel]
[reschedule]
[OK]
[async]
[async]
Provide
addtl part
mod info
Execute
part mod
workflow
[accept]
Research
production
possibility
[reject]
Figure 31-145. Part design workflow based on example from the Workflow Process Definition RFP
537
Trouble Ticket
[cannot
reproduce
problem]
[recorded]
Record
Problem
Correct
Problem
Reproduce
Problem
[else]
[not recorded]
[can
reproduce
problem]
[duplication
of another
problem]
[known
problem
and solution]
Communicate
ID Problem
and
Resolution
Results
Verify
Resolution
[else]
Audit and
Record
Figure 31-146. Trouble ticket workflow based on example from the Workflow Process Definition RFP.
[order
rejected]
Fill
Order
Receive
Order
Ship
Order
Close
Order
[order
accepted]
Send
Invoice
Make
Payment
Accept
Payment
Invoice
Figure 31-147. Order processing example.

Data flow is notated with a solid line.
Graphic nodes have small sub nodes attached on the sides for depicting inputs and outputs.
Round-sided rectangles are replaced with a round-cornered rectangle.
Chevron control icons are replaced with pentagons.
538
539
540
32 Class Diagrams
32.1 Description
Chapter 32. Class Diagrams

Class diagrams show the static structure of the classifiers in a system. This chapter outlines the graphic elements that
may be shown in class diagrams, and provides cross references where detailed information about the semantics and
concrete notation for each element can be found. It also furnishes examples that illustrate how the graphic elements
can be assembled into diagrams.
32.1. Description
Class diagrams show the static structure of the classifiers in a system, including their internal structure and relationships to other entities. The following sections describe the graphic nodes and paths that may be shown in class diagrams.
32.2. Graphic Nodes

The graphic nodes that can be included in class diagrams are shown in Table 6.
Table 6: Graphic nodes included in class diagrams
NODE TYPE
NOTATION
Class
REFERENCE
See Class (extended) on page 13-297.
ClassName
Class template
See Classifier (extended) on page 14-303

T, {value} k:Integer
FArray
contents: T [0..k]
Interface
See Interface on page 7-122.

InterfaceName
<<interface>>
InterfaceName
ClassDiagrams.fm Version 2 beta R1
541
32 Class Diagrams
32.3 Graphic Paths

NODE TYPE
NOTATION
Instance
Instancename :
ClassName
REFERENCE
See The Instances diagram on page 1-67. (Note
that instances of any classifier can be shown by
prefixing the classifier name by the instance name
followed by a colon and underlining the complete
name string.)
32.3. Graphic Paths

The graphic paths that can be included in class diagrams are shown in Table 7.
PATH TYPE
NOTATION
REFERENCE
Aggregation
(shared aggregation)
See Aggregation on page 1-50.
Association
See Association on page 1-52.
Composition
(composite
aggregation)
See Aggregation on page 1-50.
Dependency
See Dependency on page 6-116.
Generalization
See Generalization on page 1-34.
Realization
See Realization on page 6-118.
542
32 Class Diagrams
32.4 Examples
32.4. Examples
The following are typical examples of class diagrams.
cart
client
ShoppingCart
Customer
customerOrder
cartOrder
1
1..*
0..1
OrderHeader
0..*
1
Account
accountOrder
1..*
order
{xor}
organizationOrder
account
Organization
client
ite
m
*
LineItem
serviceItem
service
productItem
{xor}
product
Service
Product
Figure 32-148. Example class diagram that shows classes and their relationships.

TBD
543
32 Class Diagrams
544
33 Component Diagrams
33.1 Description
Chapter 33. Component Diagrams

This chapter outlines the graphic elements that may be shown in component diagrams, and provides cross references
where detailed information about the semantics and concrete notation for each element can be found. It also furnishes
examples that illustrate how the graphic elements can be assembled into diagrams.
33.1. Description
Component diagrams show the definition of components, in terms of the externally visible interfaces exposed via its
ports, and their internal structure consisting of classifiers used as its parts.
The following sections describe the graphic nodes and paths that may be shown in component diagrams.
33.2. Graphic Nodes

The graphic nodes that can be included in component diagrams are shown in Table 8.
Table 8: Graphic nodes included in component diagrams
NODE TYPE
NOTATION
Component
REFERENCE
See Component on page 4-24.
<<component>>
ComponentName
ComponentName
Interface
See Interface on page 48-64.

InterfaceName
<<interface>>
InterfaceName
ComponentDiagrams.fm Version 2 beta R1September 9, 2002 11:33 am
545
33.2 Graphic Nodes

NODE TYPE
Component
implements
Interface
Component
has provided
Port (typed by
Interface)
Component
uses Interface
NOTATION
REFERENCE
See Interface.
component
Name
See Port.
component
Name
See Interface.
component
Name
Component
has required
Port (typed by
Interface)
Component
has complex
Port (typed by
provided and
required Interfaces)
See Port.
component
Name
See Port.
component
Name
546
33.3 Graphic Paths
33.3. Graphic Paths

The graphic paths that can be included in component diagrams are shown in Table 9.
PATH TYPE
NOTATION
REFERENCE
Association
See Association on page 10-50.
Dependency
See Dependency on page 26-201.
Generalization
Assembly connector
See AssemblyConnector.
Delegation
connector
See DelegationConnector.
Realization
See ....
33.4. Examples
The following are typical examples of component diagrams.
547
33.4 Examples
Store
OrderEntry
delegate
Person
:Order
OrderEntry
:Customer
Person
OrderableItem
Account
delegate
OrderableItem
Account
:Product
Figure 33-149. Example component diagram that shows an internal or white-box view of a hierarchical component that uses other
components as parts of its internal assembly.
component
:BackOrder
Person
component
Person
:Order
OrderEntry
component
:Customer
Person
Client
component
:Organization
Figure 33-150. Example component collaboration diagram that shows components that are wired together via provided and
required interfaces.
548

TBD
549
550
551
552
34 Component Deployment Diagrams
34.1 Description
Chapter 34. Component Deployment Diagrams

This chapter outlines the graphic elements that may be shown in component deployment diagrams, and provides
cross references where detailed information about the semantics and concrete notation for each element can be found.
It also furnishes examples that illustrate how the graphic elements can be assembled into diagrams.
34.1. Description
Component Deployment diagrams extend the basic Deployment diagrams, by adding the deployment specification
aspects specific to deploying components in execution environments.
The following sections describe the graphic nodes and paths that may be shown in component deployment diagrams.
34.2. Graphic Nodes

The graphic nodes that can be included in deployment diagrams to specify component deployment aspects are shown
in Table 10. These nodes are in addition to the nodes and paths defined for basic Deployment diagrams.
Table 10: Graphic nodes included in deployment diagrams
NODE TYPE
NOTATION
Deployment
specification
REFERENCE
See Deployment Specification.
deployment spec
Name
Deployment
specification with properties

deployment spec
Name
execution: execKind
transaction : Boolean
Deployment
specification with property
values

deployment spec
Name
execution: thread
transaction : true
ComponentDeployDiagrams.fm Version 2 beta R1September 9, 2002 11:33 am
553
34.3 Graphic Paths

NODE TYPE
Artifact with
annotated
deployment
properties
NOTATION
REFERENCE
See Artifact.
artifact
ArtifactName
{execution=thread,
transaction =true}
34.3. Graphic Paths

The graphic paths that can be included in component deployment diagrams are shown in Table 11. These paths are in
PATH TYPE
Dependency
NOTATION
REFERENCE
See Dependency on page 26-201. In Component
Deployment diagrams, the dependency arrow is
optionally used to represent the metamodel associations between (i) a Deployment Specification
(instance) and a Component (instance), and (ii)
between an Execution Environment (instance) and
a Deployment Specification (instance).
addition to the paths defined for basic Deployment diagrams.
34.4. Examples
The following are typical examples of deployment diagrams.
:AppServer
artifact
Order.jar
{component = Order, LineItem}
{deployment location = D:\bin}
{execution = thread}
{transaction = true}
Figure 34-151. A DeploymentSpecification for an artifact : the deployment properties are annotated in braces on the artifcat.
554
:AppServer1
artifact
ShoppingApp.ear
artifact
ShoppinCart.jar
artifact
Order.jar
{component = SCart}
{component = Order}
deployment spec
ShoppingAppdesc.xml
deployment spec
Orderdesc.xml
Figure 34-152. DeploymentSpecifications for nested and composite Artifacts.

Component Deployment diagrams are new to UML 2.0. They extend basic Deployment Diagrams with component
deployment specification aspects.
555
556
35 Deployment Diagrams
35.1 Description
Chapter 35. Deployment Diagrams

This chapter outlines the graphic elements that may be shown in deployment diagrams, and provides cross references
35.1. Description
Deployment diagrams show the definition of Nodes and the Artifacts that are deployed on them. They are based on
general Static Structure diagrams, extended with deployment elements.
The following sections describe the graphic nodes and paths that may be shown in deployment diagrams.
35.2. Graphic Nodes

The graphic nodes that can be included in deployment diagrams are shown in Table 13.
NODE TYPE
NOTATION
Artifact
REFERENCE
See Artifact
artifact
ArtifactName
Node
See Node. Has keyword options device and

execution environment.
NodeName
Artifact
deployed on
Node
See Deployment
artifact
ArtifactName
{location = node}
Node with
deployed Artifacts
See Deployment
Node
artifact
ArtifactName
DeploymentDiagrams.fm Version 2 beta R1September 9, 2002 11:33 am
557
35.3 Graphic Paths

NODE TYPE
Node with
deployed Artifacts
NOTATION
REFERENCE
See Deployment (alternative, textual notation)
execution env
NodeName
artifact1
artifact2
artifact3
35.3. Graphic Paths

The graphic paths that can be included in deployment diagrams are shown in Table 14.
PATH TYPE
NOTATION
REFERENCE
Association
See Association on page 10-50. Used to model

communication paths between Nodes.
Dependency
See Dependency on page 26-201. Used to model

general dependencies. In Deployment diagrams,
this notation can optionally be used to depict the
following metamodel associations: (i) the relationship between an Artifact and the model element(s)
that it implements, and (ii) the deployment of an
Artifact (instance) on a Node (instance).
Generalization
Instantiation
See see Instances. Optionally used to model the

general instantiation between instances and their
type - in deployment diagrams applicable to Node
instances and Artifact instances.
35.4. Examples
The following are typical examples of deployment diagrams.
558
35.4 Examples
:AppServer1
artifact
ShoppinCart.jar
artifact
Order.jar
{component = SCart}
{component = Order}
Figure 35-153. A set of deployed component artifacts on a Node.
:AppServer
:DBServer
container
:J2EEServer
Order.jar
OrderSchema.ddl
ItemSchema.ddl
ShoppingCart.jar
Account.jar
Product.jar
BackOrder.jar
Service.jar
Figure 35-154. Notation for a (nested) node and a communication path between nodes.
559
component
Order
artifact
Order.jar
Figure 35-155. A visual representation of the implements relationship between artifacts and components.

Deployment diagrams are compatible with those from UML 1.x.
560
561
562
Chapter 36. Interaction Diagrams

Interaction diagrams come in different variants. The most common variant is the Sequence Diagram (Sequence Diagrams on page 36-563) that focuses on the Message interchange between a number of Lifelines. Communication
Diagrams (Communication Diagrams on page 36-569) show interactions through an architectural view where the
arcs between the communicating Lifelines are decorated with description of the passed Messages and their sequencing. Interaction Overview Diagrams (Interaction Overview Diagrams on page 36-572) are a variant of Activity
Diagrams that define interactions in a way that promotes overview of the control flow.
36.1. Sequence Diagrams

The most common kind of Interaction Diagram is the Sequence Diagram, which focuses on the Message interchange
between a number of Lifelines.
Description
Sequence Diagrams describes Interactions focusing on the sequencing of Messages and their corresponding Event
Occurrences on Lifelines. The Interactions that are described by Sequence Diagrams are described in Chapter 8,
Basic::Interactions.
Graphic Nodes
Table 14: Graphic nodes included in sequence diagrams
NODE TYPE
NOTATION
Frame
REFERENCE
The notation shows a rectangular frame around the
diagram with a name in a compartment in the
upper left corner. See Interaction on page 8-140.
s d U s e rA c c e s s
Lifeline
See Lifeline on page 8-145

User
InteractionDiagrams.fm Version 2 beta R1September 9, 2002 11:32 am
563
36 Interaction Diagrams
36.1 Sequence Diagrams

NODE TYPE
NOTATION
ActionOccurrence / Activation /
Suspension
ob2:C2
REFERENCE
See ActionOccurrence on page 8-132. See also
Lifeline on page 8-145 and ExecutionOccurrence on page 8-138
See InteractionOccurrence on page 8-143.

ref
CombinedFragment
See CombinedFragment on page 8-132

alt
Coregion
See explanation under parallel in CombinedFragment on page 8-132
Stop
See ///to be referenced ///
564
Graphic Paths
The graphic paths between the graphic nodes are given in Table 15
Table 15: Graphic paths included in sequence diagrams
NODE TYPE
NOTATION
Message
Card Out()
doit(z)()
REFERENCE
Messages come in different variants depending on
what kind of Message they convey. Here we show
an asynchronous message, a call and a reply. These
are all complete messages. See Message on page
8-146.
doit(z)()
Lost Message
Found Message
GeneralOrdering
lost
Lost messages are messages with known sender,

but the reception of the message does not happen.
See Message on page 8-146
found
Found messages are messages with known

receiver, but the sending of the message is not
described within the specification. See Message
on page 8-146
See GeneralOrdering on page 8-139
565
Examples
sd N
sd M
s[u]:B
s[k]:B
s[u]:B
m3()
s[k]:B
m3()
m1()
m3()
m2()
m2()
m3()
ref
N
{x==2}
Lifeline
Interactions
Coregion
Class
ref
ref
(Event)
Constraint
Internal structure
Part
s:B[*]
*
Figure 36-156. Sequence Diagrams where two Lifelines refer to the same set of Parts (and Internal Structure)
The sequence diagrams shown in Figure 36-156 shows a scenario where r sends m1 to s[k] (which is of type B),
and s[k] sends m2 to s[u]. In the meantime independent of s[k] and s[u], r may have sent m3 towards the InteractionOccurrence N through a gate. Following the m3 message into N we see that s[u] then sends another m3 message to
s[k]. s[k] then sends m3 and then m2 towards s[u]. s[u] receives the two latter messages in any order (coregion). Having received these messages, we state an invariant on a variable x (most certainly owned by s[u] ).
In order to explain the mapping of the notation onto the metamodel we have pointed out areas and their corresponding metamodel concept in Figure 36-157. Let us go through the simple diagram and explain how the metamodel
is built up. The whole diagram is an Interaction (named N). There is a formal gate (with implicit name in_m3) and
two Lifelines (named s[u] and s[k] ) that are contained in the Interaction. Furthermore the two Messages (occurrences) both of the same type m3, implicitly named m3_1 and m3_2 here, are also owned by the Interaction. Finally
there are the three EventOccurrences.
We have omitted in this metamodel the objects that are more peripheral to the Interaction model, such as the Part
s and the class B and the connector referred by the Message.
566
Interaction
sd N
Lifeline
s[u]:B
Message
s[k]:B
m3()
(receiving)EventOccurrence
m3()
(formal) Gate
EventOccurrence
Interaction N
Gate in_m3 Lifeline s[u]

Lifeline s[k]
EventOccurrence
?m3 on s[u]
EventOccurrence
!m3 on s[u]
Message
m3_1:m3
Message
m3_2:m3
EventOccurrence
?m3 on s[k]
Figure 36-157. Metamodel elements of a sequence diagram
567
sd M filter {not t,r}
Z
s()
mystate
assert filter {q, v}

q()
{Y.p == 15}
v
Figure 36-158. Filter, assert with State Invariants

In Figure 36-158 we have an Interaction M which considers message types other than t and r. This means that if
this Interaction is used to specify a test of an existing system and when running that system a t or an r occurs, these
messages will be ignored.
The State invariant given as a state mystate will be evaluated at runtime directly prior to whatever event occurs
on Y after mystate. This may be the reception of q as specified within the assert-fragment, or it may be an event
that is specified to be insignificant by the filters.
The assert fragment is combined with a filter fragment to mean that we expect a q message to occur. Any occurrences of messages other than v and q will be ignored in a test situation. The state invariant given in curly brackets
will be evaluated prior to the next event occurrence after that on Y.
568
Internal Structure and corresponding Collaboration Occurrence
E
ref
collaboration W
ref
w1:W
y
*
**
-x
-y
b
*
binding Parts
sd P
sd Q
a
ref
w1.Q
m1()
m2()
Figure 36-159. Describing collaborations and their binding
36.2. Communication Diagrams

A Communication Diagram is a kind of Interaction Diagram that shows how communicating Lifelines are augmented
with descriptions of passed Messages and their sequencing.
Description
Communication Diagrams focus on the interaction between Lifelines where the architecture of the internal structure
and how this corresponds with the message passing is central. The sequencing of Messages is given through a
sequence numberering scheme. The Interactions that are described by Communication Diagrams are described in
Chapter 8, Basic::Interactions.
Communication Diagrams may also include Interaction references.
569
36.2 Communication Diagrams
Graphical Nodes
Communication diagram nodes are shown in Table 16.
Table 16: Graphic nodes included in communication diagrams
NODE TYPE
NOTATION
Frame
REFERENCE
Lifeline

s[u]:B
Graphic Paths
Graphic paths of communication diagrams are given in Table 17
Table 17: Graphic paths included in communication diagrams
NODE TYPE
NOTATION
Message
REFERENCE
See Message on page 8-146. and Sequence
expression on page 36-571
1a m1()
570
Examples
Lifeline
cd M
Message
with
Sequence
number
1a m1()
Message
s[k]:B
2
3(
)
2(
1b
)
uses
uses
s[u]:B
ref
3:N
Figure 36-160. Communication diagram
Note: The example above will be corrected and updated in the next revision.
Sequence expression
The sequence-expression is a dot-separated list of sequence-terms followed by a colon (:).
sequence-term . . . . :
Each term represents a level of procedural nesting within the overall interaction. If all the control is concurrent,
then nesting does not occur. Each sequence-term has the following syntax:
[ integer | name ] [ recurrence ]
The integer represents the sequential order of the Message within the next higher level of procedural calling.
Messages that differ in one integer term are sequentially related at that level of nesting. Example: Message 3.1.4 follows Message 3.1.3 within activation 3.1. The name represents a concurrent thread of control. Messages that differ in
the final name are concurrent at that level of nesting. Example: Message 3.1a and Message 3.1b are concurrent within
activation 3.1. All threads of control are equal within the nesting depth.
The recurrence represents conditional or iterative execution. This represents zero or more Messages that are executed depending on the conditions involved. The choices are:
* [ iteration-clause ]an iteration
[ guard ]a branch
An iteration represents a sequence of Messages at the given nesting depth. The iteration clause may be omitted
(in which case the iteration conditions are unspecified). The iteration-clause is meant to be expressed in pseudocode
or an actual programming language, UML does not prescribe its format. An example would be: *[i := 1..n].
A guard represents a Message whose execution is contingent on the truth of the condition clause. The guard is
meant to be expressed in pseudocode or an actual programming language; UML does not prescribe its format. An
example would be: [x > y].
571
36.3 Interaction Overview Diagrams
Note that a branch is notated the same as an iteration without a star. One might think of it as an iteration restricted
to a single occurrence.
The iteration notation assumes that the Messages in the iteration will be executed sequentially. There is also the
possibility of executing them concurrently. The notation for this is to follow the star by a double vertical line (for parallelism): *||.
Note that in a nested control structure, the recurrence is not repeated at inner levels. Each level of structure
specifies its own iteration within the enclosing context.
36.3. Interaction Overview Diagrams

Interaction Overview Diagrams define Interactions (described in Chapter 8, Basic::Interactions) through a variant
of Activity Diagrams (described in Chapter 12, Common::Activities) in a way that promotes overview of the control flow.
Description
Interaction Overview Diagrams focus on the overview of the flow of control where the nodes are Interactions or
InteractionOccurrences. The Lifelines and the concrete Messages are not appearing on this overview level.
Graphic Nodes
Interaction Overview Diagrams are specialization of Activity Graphs that represent Interactions
Interaction Overview Diagrams differ from Activity Diagrams in some respects.
1.
2.
3.
4.
5.
6.
In place of ObjectNodes of Activity Diagrams, Interaction Overview Diagrams can only have either (inline)
Interactions or InteractionOccurrences. Inline Interaction diagrams and InteractionOccurrences are considered
special forms of ActivityInvocations.
Alternative Combined Fragments are represented by a Decision Node and a corresponding Merge Node.
Parallel Combined Fragments are represented by a Fork Node and a corresponding Join Node.
Loop Combined Fragments are represented by simple cycles.
Branching and joining of branches must in Interaction Overview Diagrams be properly nested. This is more
restrictive than in Activity Diagrams.
Interaction Overview Diagrams are framed by the same kind of frame that encloses other forms of Interaction
Diagrams. The heading text may also include a list of the contained Lifelines (that do not appear graphically)
.
Table 18: Graphic nodes included in Interaction Overview Diagrams in addition to those borrowed from Activity
Diagrams
NODE TYPE
NOTATION
Frame
REFERENCE
572
Table 18: Graphic nodes included in Interaction Overview Diagrams in addition to those borrowed from Activity
Diagrams
NODE TYPE
NOTATION
Interaction
sd
AC System
User
CardOut
ref
REFERENCE
An Interaction diagram of any kind may appear
inline as an ActivityInvocation. See Interaction
on page 8-140. The inline Interaction diagrams
may be either anonymous (as here) or named.
ActivityInvocation in the form of InteractionOccurrence. See InteractionOccurrence on page

8-143. The tools may choose to explode the view
of an InteractionOccurrence into an inline Interaction with the name of the Interaction referred by
the occurrence. The inline Interaction will then
replace the occurrence by a replica of the definition
Interaction where eventual arguments have
replaced parameters.
573
36.3 Interaction Overview Diagrams
Examples
sd OverviewDiagram lifelines User, ACSystem
ref
(inline) Interaction
EstablishAccess("IllegalPIN")
sd
AC System
User
CardOut
decision
interaction constraint
[PINok]
sd
User
AC System
Mesg("Please
Enter)"
ref
OpenDoor
Figure 36-161. Interaction Overview Diagram representing a High Level Interaction diagram
Interaction Overview Diagrams are Activity diagrams where the Activities are either Interactions or InteractionOccurrences.. Interaction Overview Diagrams is a way to describe Interactions where messages and Lifelines are
abstracted away. In the purest form all Activities are InteractionOccurrences and then there are no Messages or Lifelines shown in the diagram at all.
Activity diagrams offer notation for InteractionOperators for alternative (with guards) namely the Decision diamond, and for parallel merge namely the fork/join notation.
574
36.1. Timing Diagram

Note: This section is included in a preliminary form. Some of the material will appear within the main body
of explanation of the time concepts and the examples will be elaborated and updated according to discussions]
Timing Diagrams are used to show interactions when a primary purpose of the diagram is to reason about time. Timing diagrams focus on conditions changing within and among Lifelines along a linear time axis.
Description
Timing diagrams describe behavior of both individual classifiers and interactions of classifiers, focusing attention on
time of occurrence of events causing changes in the modeled conditions of the Lifelines. The Interactions that are
described by Timing Diagrams are described in Chapter 8, Basic::Interactions.
Graphic Nodes
NODE TYPE
NOTATION
REFERENCE
Frame

doIt(w:int)
VSense
evAcquire(
void): long
Message
Messages come in different variants depending on

what kind of Message they convey. Here we show
an asynchronous message, a call and a reply. See
Message on page 8-146.
575
36.1 Timing Diagram

NODE TYPE
NOTATION
State or condition timeline
REFERENCE
This is the state of the classifier or attribute, or
some testable condition, such as an discrete enumerable value. See //to be referenced//
Initializing
Acquiring
Reporting
Idle
General value
timeline
x"FFFF"
Lifeline
Shows the value of the connectable element as a

function of time. Value is explicitly denoted as
x"00 text. Crossing reflects the event where the value
changed.
instance 1
Instance 2
GeneralOrdering
See GeneralOrdering on page 8-139
Stop
See ///to be referenced ///
Examples
Timing diagrams show change in state or other condition of a structural element over time. There are a number of
common forms in use. The most simple form is shown in Figure 36-162.
576
Instance name
State or condition
timing constraint
{ 20 ms +/- 2 ms }
Atrial Model
Pacing
tm(Pulse Width)
State
Waiting
tm(senseTime)
Refractory
Sense
tm(Ref Time)
Idle
To Inhibited
10 15 ...
Time (ms)
tick mark values
event or stimulus
timing ruler
Figure 36-162. A lifeline for a discrete object

The primary purpose of the timing diagram is to show the change in state or condition of a lifeline (representing
a Classifier Instance or Classifier Role) over linear time. The most common usage, as shown in Figure 36-162 is to
show the change in state of an object over time in response to accepted events or stimuli. The received events are
annotated as shown when it is desireable to show the event causing the change in condition or state. The mark in the
figure indicating the acceptance of the Sense event shows an event received and processed but did not result in a
change of state.

The Interaction Overview Diagram of Interaction Diagram was not available in UML 1.4. Communication Diagrams
were subsumed under Collaboration Diagrams in UML 1.4. and covers fully the situations where UML 1.4 Collaboration Diagrams were used to describe Interactions. Sequence Diagrams are extensions of Sequence Diagrams in
UML 1.4.
577
578
37 Internal Structure Diagrams
37.1 Description
Chapter 37. Internal Structure Diagrams

Internal structure diagrams show the internal structures of a classifiers. This chapter outlines the graphic elements
that may be shown in an internal structure diagram, and provides cross references where detailed information about
the semantics and concrete notation for each element can be found. It also furnishes examples that illustrate how the
graphic elements can be assembled into diagrams.
37.1. Description
An internal structure diagram depicts the internal structure of a classifier, including the interaction points of the classifier to other parts of the system. It shows the configuration of parts that jointly perform the behavior of the containing classifier. The architecture diagram specifies a set of instances playing parts (roles), as well as their required
relationships given in a particular context.
An internal structure diagram describes the structure of any StructuredClassifier (see Chapter 9, Basic::InternalStructures), such as classes, components, or collaborations. It shows parts linked by connectors. It may also contain
collaboration occurrences and bindings of its parts to parts of the referenced collaboration. An internal structure diagram may also contain ports to describe the encapsulation boundary of a structured classifier.
The following sections describe the graphic nodes and paths that may be shown in internal structure diagrams.
37.2. Graphic Nodes

Table 20: Graphic nodes included in internal structure diagrams
NODE TYPE
NOTATION
Class
REFERENCE
See Class (extended) on page 13-297.
ClassName
Part
See Part on page 9-161.

partName :
ClassName
Port
portName:
ClassifierName
See Port (extended) on page 13-299. A port may

appear either on a contained part representing a
port on that part, or on the boundary of the class
diagram, representing a port on the represented
classifier itself. The optional ClassifierName is
only used for ComplexPorts.
InternalStructureDiagrams.fm Version 2 beta R1September 9, 2002 11:32 am
579
37.3 Graphic Paths
Table 20: Graphic nodes included in internal structure diagrams

NODE TYPE
NOTATION
REFERENCE
Behavior port
See Port (extended) on page 13-299.
Collaboration
See Collaboration on page 14-304.

CollaborationName
Collaboration
occurrence
See CollaborationOccurrence on page 14-306.

name:
Collaboration
37.3. Graphic Paths

The graphic paths that can be included in internal structure diagrams are shown in Table 21.
Table 21: Graphic nodes included in collaboration diagrams
PATH TYPE
NOTATION
REFERENCE
Connector
See Connector on page 9-157.
Role binding
See RoleBinding on page 14-309.
580
37.4 Examples
37.4. Examples
The following are typical examples of internal structure diagrams.
Car
axle
rear : Wheel [2]
e : Engine
Figure 37-163. Internal structure of a Car class.
Sale
Buyer
Seller
Figure 37-164. The Sale collaboration.
BrokeredSale
wholesale:
Sale
broker
Buyer
Seller
Seller
producer
retail:
Sale
Buyer
consumer
Figure 37-165. The BrokeredSale collaboration.
581

The constructs to model the internal structure of classifiers and the encapsulation of classifiers through ports are new
to UML 2.0. UML 1.x collaborations (not to be confused with UML 1.x collaboration diagrams) are now modeled
using internal structure diagrams as shown above.
582
38 Package Diagrams
38.1 Description
Chapter 38. Package Diagrams

Package diagrams show how to organize model elements into packages and show the dependencies among them.
This chapter outlines the graphic elements that may be shown in package diagrams, and provides cross references
38.1. Description
Package diagrams show how to organize model elements into packages and show the dependencies among them,
including package imports and package extensions. The following sections describe the graphic nodes and paths that
may be shown in class diagrams.
38.2. Graphic Nodes

NODE TYPE
NOTATION
Package
REFERENCE
See Package on page 1-72.
PackageName
38.3. Graphic Paths

The graphic paths that can be included in class diagrams are shown in Table 2.
PATH TYPE
Package
Extension
NOTATION
REFERENCE
See PackageExtension on page 1-74.
<<extend>>
Package
Import
(private)
See PackageImport on page 1-81.
<<use>>
PackageDiagrams.fm Version 2 beta R1
583
38 Package Diagrams
38.4 Examples

PATH TYPE
NOTATION
REFERENCE
Package
Import
(public)
See PackageImport on page 1-81.
<<import>>
38.4. Examples
The following are typical examples of package diagrams.
Units
player
Player
unit
Unit
*
*
name: String
armor: Integer
Building
Warrior
extend
Buildings
Figure 38-1. Example of package extension
584
38 Package Diagrams
Types
AuxiliaryTypes
import
use
ShoppingCart
import
WebShop
Figure 38-2. Examples of public and private package imports

TBD
585
38 Package Diagrams
586
39 Protocol State Machine Diagrams
39.1 Graphic Elements
Chapter 39. Protocol State Machine Diagrams

Protocol state machine diagrams specify the lifecycle of the instances of the context classifier. This chapter is based
on Chapter 40, State Machine Diagrams. The notation is the same, except that certain elements are not legal in protocola state diagrams (exit, entry, do, and internal transitions, history states). Only the specificities of protocol state
machines are detailed in this chapter.
39.1. Graphic Elements

In addition to the graphic elements that can be included in Chapter 40, State Machine Diagrams, the following
nodes can be included in protocol state machines.
Table 3: Graphic nodes included in state machine diagrams
NODE TYPE
NOTATION
REFERENCE
See ProtocolTransition
ProtocolTransition
The syntax is :
[precondition] event/
[postcondition]
[C1]m1/[C2]
S1
S2
See State
State having a state

invariant
Ty ping
P asswo rd
The invariant expression is close to the

state name, surrounded
by square braquets
[invariant expr]
See ProtocolStateMachine
The {protocol} keyword is used
Door {protocol}
S1
S2
ProtocolStatemachineDiagrams.fm Version 2 beta R1September 9, 2002 11:33 am
587
39 Protocol State Machine Diagrams
39.2 Examples
39.2. Examples
The following is an example of protocol state machine diagrams.
Door {protocol}
[doorWay->isEmpty] Close/
opened
closed
create/
open/
lock/
unlock/
locked
Figure 39-3. Protocol State Machine of a Door class
ProtocolStatemachineDiagrams.fm Version 2 beta R1September 9, 2002 11:33 am
588
40 State Machine Diagrams
40.1 Graphic Nodes
Chapter 40. State Machine Diagrams

State machine diagrams specify state machines. This chapter outlines the graphic elements that may be shown in state
machine diagrams, and provides cross references where detailed information about the semantics and concrete notation for each element can be found. It also furnishes examples that illustrate how the graphic elements can be assembled into diagrams.
40.1. Graphic Nodes

The graphic nodes that can be included in state machine diagrams are shown in Table 4.
NODE TYPE
NOTATION
REFERENCE
Choice pseudo state
See PseudoState on page 19-359.
[Id>10]
[Id<=10]
Composite state
See State on page 19-366.

S
Sb2
Sb1
Entry point
Sb3
See ConnectionPoint on page 19-357.
activeEntry
Exit point
aborted
Final state
See FinalState on page 19-359.
StatemachineDiagrams.fm Version 2 beta R1September 9, 2002 11:33 am
589
40.1 Graphic Nodes

NODE TYPE
NOTATION
REFERENCE
History, Deep
Pseudo state

H*
History, Shallow
pseudo state

H
Initial pseudo state
Junction pseudo state
Region
See Region on page 19-365.

S
Simple state
S
State list
S1,S2
State Machine
See StateMachine on page 19-376.

ReadAmountSM
aborted
590
40.2 Graphic Paths

NODE TYPE
NOTATION
REFERENCE
Stop node
See PseudoState on page 19-359
Submachine state

ReadAmount
aborted
include /ReadAmountSM
40.2. Graphic Paths

The graphic paths that can be included in state machine diagrams are shown in Table 5.
Table 5: Graphic paths included in state machine diagrams
PATH TYPE
NOTATION
Transition
REFERENCE
See Transition on page 19-383.
E[g]a
40.3. Examples
The following are examples of state machine diagrams.
591
40.3 Examples
ReadAmountSM
abort
selectAmount
otherAmount
amount
enterAmount
abort
aborted
ok
Figure 40-4. State machine with exit point definition
ATM
VerifyCard
acceptCard
OutOfService
ReadAmount
aborted
outOfService include /ReadAmountSM
VerifyTransaction
releaseCard
ReleaseCard
Figure 40-5. SubmachineState with usage of exit point
592
41 Use Case Diagrams
41.1 Description
Chapter 41. Use Case Diagrams

Use Case Diagrams are used to describe Use Cases as defined in Chapter 10, Basic::UseCases.
41.1. Description
Use Case Diagrams are a specialization of Class Diagrams such that the classifiers shown are restricted to being
either Actors or Use Cases.
41.2. Graphic Nodes

NODE TYPE
NOTATION
Actor (default)
REFERENCE
See Actor on page 10-166.
Customer
Subscriber
Actor
(optional userdefined icon example)
Extend
See Extend on page 10-168.

extend
base (use case)

Extend (with
Condition)
extension (use case)
Condition: {customer selected HELP}

extend
UseCaseDiagrams.fm Version 2 beta R1 September 9, 2002 11:33 am
593
41.2 Graphic Nodes

NODE TYPE
NOTATION
ExtensionPoint
REFERENCE
See ExtensionPoint on page 10-170.
extension points
Selection
extension point
OrderStationery
extension points
order created : in Created state
order shipped : in Shipped state
extension point
Include
See Include on page 10-171.

include
addition (use case)
base (use case)
Use Case
See UseCase on page 10-172.

Withdrawl
On-Line Help
extension points
Selection
OrderStationery
594
41.3 Examples
41.3. Examples
Telephone Catalog
use case
Check Status
Salesperson
Place Order
actor
Customer
Fill Orders
Shipping Clerk
subject
Establish Credit
Supervisor
Figure 41-6. Use Case diagram with a rectangle representing the boundary of the subject.
The use case diagram in Figure 41-6 shows a set of use cases used by four actors of a physical system that is the
subject of those use cases. The subject can be optionally represented by a rectangle as shown in this example.
595
Figure 41-7 illustrates a package that owns a set of use cases (NB: a use case may be owned either by a package
or by a classifier (usually the subject)).
ATMtopPkg
ATMsystem
0..1
Card Identification
1
1
0..1
On-Line Help
Custom er
0..*
0..1
Perform ATM Transac tion
1
Bank
0.. *
0..1
1

1
Administrator
0..1
Read Log
Figure 41-7. Use cases owned by a package

There are no changes from UML 1.x, although some aspects of notation to model element mapping have been clarified.
596
Appendices
Appendices.fm Version 2 beta R1
597
Appendices.fm Version 2 beta R1
598
A Standard Profiles
A.1 Basic
Appendix A. Standard Profiles

This appendix describes the predefined standard profiles for UML. The standard profiles are organized by packages:
Basic, Common and Complete.
A.1. Basic
Table A-1
Name
Subpackage
Applies to
Description
auxiliary
Kernel
Class
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.
call
Dependencies
Usage
A 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
Dependencies
Usage
A usage dependency denoting that the client

classifier creates instances of the supplier
classifier.
create
Kernel
BehavioralFeature
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
Kernel
BehavioralFeature
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.
StandardProfiles.fm Version 2 beta R1
A-599
A Standard Profiles
A.1 Basic
Table A-1
focus
Kernel
Class
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.
framework
Kernel
Package
A package that contains model elements

which 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.
implementation
Class
Classes
Class
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.
instantiate
Dependencies
Usage
A usage dependency among classifiers

indicating that operations on the client create
instances of the supplier.
metaclass
Kernel
Class
A class whose instances are also classes.
A-600
A Standard Profiles
A.1 Basic
Table A-1
modelLibrary
Kernel
Package
A package that contains model elements

which 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.
responsibility
Kernel
Usage
A contract or an obligation of an element in

its relationship to other elements.
send
Dependencies
Usage
A usage dependency whose source is an

operation and whose target is a signal,
specifying that the source sends the target
signal.
type
Classes
Class
A class that specifies a domain of objects

together with the operations applicable to the
objects, without defining the physical
implementation of those objects. However, it
may have attributes and associations.
Behavioral specifications for type operations
may be expressed using, for example,
activity diagrams. An object may have at
most one implementation class, however it
may conform to multiple different types. See
also: <<implementationClass>>
utility
Classes
Class
A class that has no instances, but rather

denotes a named collection of non-member
attributes and operations, all of which are
class-scoped.
A-601
A Standard Profiles
A.2 Common
A.2. Common
Table A-2
Name
Subpackage
Applies to
Description
document
Deployments
Artifact
A generic file that is not a source file or

executable. Subclass of file.
executable
Deployments
Artifact
A program file that can be executed on a

computer system. Subclass of file.
file
Deployments
Artifact
A physical file in the context of the system

developed.
library
Deployments
Artifact
A static or dynamic library file. Subclass of

file.
source
Deployments
Artifact
A source file that can be compiled into an

executable file. Subclass of file.
A.3. Complete
Table A-3
Name
Subpackage
Applies to
Description
metamodel
Model
Management
Model
A model of a model, that typically contains

containing metaclasses. See <<metaclass>>.
systemModel
Model
Management
Model
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.
A-602
B Component Profile Examples
B.1 J2EE/EJB Component Profile Examples
Appendix B. Component Profile Examples

This appendix describes example profiles for J2EE/EJB and .NET/COM components. These profiles are not meant
to be either normative or complete, but are provided as an illustration of how UML 2.0 can be customized to model
component architectures.
B.1. J2EE/EJB Component Profile Examples

Examples will be added in the next revision.
B.2. .NET/COM Component Profile Examples

Examples will be added in the next revision.
ComponentProfiles.fm Version 2 beta R1 September 9, 2002 11:33 am
B-603
B Component Profile Examples
B.2 .NET/COM Component Profile Examples
ComponentProfiles.fm Version 2 beta R1 September 9, 2002 11:33 am
B-604
Appendix C. Tabular Notations

This appendix describes optional tabular notations for UML behavioral diagrams, that some vendors or users may
want to use as alternatives to UMLs graphic notation. Although this appendix only describes tabular notations for
Interactions and State Machines, the approach may also be applied to other kinds of behavioral diagrams.
C.1. Tabular Notation for Interactions

This section describes an optional tabular notation for Interaction Diagrams. The following subsections describe the
rows of the tabular representation and provide examples of its use.
Note: The tabular notation for Interactions described here is based on an early version of the Fujitsu UML
2.0 Superstructure submission, which will be updated to reflect improvements in their revised submission
(ad/02-09-09).
Table Row Descriptions
The optional tabular notation notation for Interaction Diagrams consists of a table with the following rows:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Lifeline Class: Designates Class name of Lifeline. If there is no Class name on the Lifeline symbol, this class
name is omitted.
Lifeline Instance: Designates Instance name of Lifeline. If there is no Instance name on the Lifeline symbol, this
instance name is omitted.
Constraint: Designates some kind of constraint. For example, indication of oblique line is denoted as "{delay}".
"alt" is for conditional fragment. And, to represent CombinedFragements, those operators are denoted on this
column.
Message Sending Class: Designates the message sending class name for each incoming arrow.
Message Sending instance: Designates the message sending instance name for each incoming arrow.
Diagram ID: Identifies the document that describes the corresponding sequence/collaboration diagram and can
be the name of the file that contains the corresponding sequence/collaboration diagram.
Generated instance name: An identifier name that is given to each instance symbol in the sequence /collaboration
diagram. The identifier name is unique in each document.
Sequence Number: The corresponding message number on the sequence /collaboration diagram.
Weak Order: Designates partial (relative) orders of events, as ordered on individual lifelines and across lifelines,
given a message receive event has to occur after its message send event. See definition of weak order (section
34.1 in the U2 partners submission.) Events are shown as "e" + event order + event direction (incoming or outgoing).
Message name: The corresponding message name on the sequence /collaboration diagram.
Parameter: A set of parameter variable names and parameter types of the corresponding message on the
sequence/collaboration diagrams.
Return value: The return value type of the corresponding message on the sequence/collaboration diagram.
Message Receiving Class: Designates the message receiving class name for each outgoing arrow.
Message Receiving Instance: Designates the message receiving instance name for each outgoing arrow.
Other End: Designates event order of another end on the each message.
TabularNotations.fm Version 2 beta R1
C-605
C Tabular Notations
C.1 Tabular Notation for Interactions
Examples
sd N
e1o
t()
e2i
s()
ref
e3o(ref)
e4
i
[x==5]
alt
u()
e5o
e6i
[x==0]
v()
e7
o
Figure C-1. Interaction enhanced with identification of the Event occurrences
Message Message
Generated
Message Message
Lifeline Lifeline
Sending Sending Diag Instance Sequence Weak Mesg Para Return Receiving Receive Other
Instance End
Instance ID Name
No
Order Name meter Value Class
Class Inst Constraint Class
C
B
Ref(M.sq)
Ref(M.sq)
C
C
Alt x==5
Alt x==5
Alt x==o
N.sq
e1o
N.sq
e2i
N.sq
e3o(ref) s
C
C
N.sq
e3o(ref) s
_(M.sq)
N.sq
e4i
N.sq
e5o
N.sq
e6i
N.sq
e7o
e2i
e1o
e4i
e4i
e3o(ref)
e6i
e5o
out_v
Figure C-2. Interaction.Table describing Figure C-1
C-606
Figure C-3. Interaction with guards, parallel composition and alternatives [to be updated]
Figure C-4. Interaction Table for Figure C-3
C.2. Tabular Notation for State Machines

An example will be added in the next revision.
C-607
C Tabular Notations
C.2 Tabular Notation for State Machines
C-608
Appendix D. XMI Serialization and Schema

This appendix provides a summary of how the XMI serialization and schema for the UML Superstructure will be
produced in an auxiliary document.
The preferred way to produce the XMI serialization and schema is to base it on a successful proposal to the MOF
2.0 XMI Mapping RFP (ad/01-11-13). There appears to be only one submission team for this RFP, consisting of IBM,
Unisys, et al., and they are scheduled to publish their revised proposal by the same deadline that applies to this proposal, Sept. 9, 2002. In the event that the revised MOF 2.0 XMI Mapping proposal is sufficiently mature, we plan to
use it to produce a separate document with the XMI serialization and schema soon after it is available.
In the event that the MOF 2.0 XMI Mapping proposal is immature or architecturally incompatible, since UML
2.0 is also a MOF 1.4 compliant metamodel the XMI serialization and schema can alternatively be produced from the
current adopted MOF and XMI standards: MOF 1.4 and XMI 2.0. If this alternative is chosen, we plan to use MOF
1.4 and XMI 2.0 to produce a separate document with the XMI serialization and schema soon after we determine that
we cannot use the revised MOF 2.0 XMI Mapping proposal.
In either case, the XMI serialization and schema for this proposal to ensure tool interoperability will be produced
within a timely manner.
XMI.fm Version 2 beta R1
D-609
D XMI Serialization and Schema
XMI.fm Version 2 beta R1
D-610
Appendix E. Glossary
[Note: This glossary is currently being updated from UML 1.x to UML 2.0, and is a work in progress. Since it is not
yet synchronized with the major revision, the reader is likely to encounter significant discrepancies between it and the
main specification.]
This glossary defines modeling terms that are used to describe the Unified Modeling Language (UML) and
which are also used by other OMG modeling standards, such as the Meta Object Facility (MOF). In addition to modeling terms, it also includes relevant terms from OMG standards and object analysis and design methods, that are
helpful in understanding the UML. Glossary entries are organized alphabetically and MOF specific entries are identified as [MOF].
E.1. Notation Conventions

The entries in the glossary usually begin with a lowercase letter. An initial uppercase letter is used when a word
is usually capitalized in standard practice. Acronyms are all capitalized, unless they traditionally appear in all lowercase.
When one or more words in a multi-word term is enclosed in brackets, it indicates that those words are optional
when referring to the term. For example, use case [class] may be referred to as simply use case.
The following conventions are used in this glossary:
Contrast: <term>
Refers to a term that has an opposed or substantively different meaning.
See: <term>
Refers to a related term that has a similar, but not synonymous meaning.
Synonym: <term>
Indicates that the term has the same meaning as another term, which is
referenced.
Acronym: <term>
Indicates that the term is an acronym. The reader is usually referred to the
spelled-out term for the definition, unless the spelled-out term is rarely
used.
This glossary defines the terms that are used to describe the Unified Modeling Language (UML) and the Meta
Object Facility (MOF). In addition to UML and MOF specific terminology, it includes related terms from OMG standards and object-oriented analysis and design methods, as well as the domain of object repositories and meta data
managers. Glossary entries are organized alphabetically and MOF specific entries are identified as [MOF].
Glossary.fm Version 2 beta R1
E-611
E Glossary
E.2 Glossary Terms
E.2. Glossary Terms
abstract class
A class that cannot be directly instantiated. Contrast:

concrete class.
abstraction
The essential characteristics of an entity that distinguish it

from all other kinds of entities. An abstraction defines a
boundary relative to the perspective of the viewer.
action
The specification of an executable statement that forms an

abstraction of a computational procedure. An action
typically results in a change in the state of the system, and
can be realized by sending a message to an object or
modifying a link or a value of an attribute.
action sequence
An expression that resolves to a sequence of actions.
action state
A state that represents the execution of an atomic action,

typically the invocation of an operation.
activation
The execution of an action.
active class
A class whose instances are active objects. See: active

object.
active object
An object that owns a thread and can initiate control

activity. An instance of active class. See: active class,
thread.
activity graph
A special case of a state machine that is used to model

processes involving one or more classifiers. Contrast:
statechart diagram.
actor [class]
A coherent set of roles that users of use cases play when

interacting with these use cases. An actor has one role for
each use case with which it communicates.
actual parameter
Synonym: argument.
aggregate [class]
A class that represents the whole in an aggregation

(whole-part) relationship. See: aggregation.
aggregation
A special form of association that specifies a whole-part

relationship between the aggregate (whole) and a
component part. See: composition.
E-612
analysis
The part of the software development process whose

primary purpose is to formulate a model of the problem
domain. Analysis focuses what to do, design focuses on
how to do it. Contrast: design.
analysis time
Refers to something that occurs during an analysis phase of

the software development process. See: design time,
modeling time.
architecture
The organizational structure and associated behavior of a

system. An architecture can be recursively decomposed into
parts that interact through interfaces, relationships that
connect parts, and constraints for assembling parts. Parts
that interact through interfaces include classes, components
and subsystems.
argument
A binding for a parameter that resolves to a run-time

instance. Synonym: actual parameter. Contrast: parameter.
artifact
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. Synonym: product. Contrast:
component.
association
The semantic relationship between two or more classifiers

that specifies connections among their instances.
association class
A model element that has both association and class

properties. An association class can be seen as an
association that also has class properties, or as a class that
also has association properties.
association end
The endpoint of an association, which connects the

association to a classifier.
attribute
A feature within a classifier that describes a range of values

that instances of the classifier may hold.
auxiliary class
A stereotyped class that supports another more central or

fundamental class, typically by implementing secondary
logic or control flow. 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.
behavior
The observable effects of an operation or event, including

its results.
E-613
E Glossary
E.2 Glossary Terms
behavioral feature
A dynamic feature of a model element, such as an operation

or method.
behavioral model
aspect
A model aspect that emphasizes the behavior of the

instances in a system, including their methods,
collaborations, and state histories.
binary association
An association between two classes. A special case of an nary association.
binding
The creation of a model element from a template by

supplying arguments for the parameters of the template.
boolean
An enumeration whose values are true and false.
boolean expression
An expression that evaluates to a boolean value.
cardinality
The number of elements in a set. Contrast: multiplicity.
child
In a generalization relationship, the specialization of

another element, the parent. See: subclass, subtype.
Contrast: parent.
call
An action state that invokes an operation on a classifier.
class
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. See:
interface.
classifier
A mechanism that describes behavioral and structural

features. Classifiers include interfaces, classes, datatypes,
and components.
classification
The assignment of an object to a classifier. See dynamic

classification, multiple classification and static
classification.
class diagram
A diagram that shows a collection of declarative (static)

model elements, such as classes, types, and their contents
and relationships.
client
A classifier that requests a service from another classifier.

Contrast: supplier.
collaboration
The specification of how an operation or classifier, such as

a use case, is realized by a set of classifiers and associations
playing specific roles used in a specific way. The
collaboration defines an interaction. See: interaction.
E-614
collaboration diagram
A diagram that shows interactions organized around the

structure of a model, using either classifiers and
associations or instances and links. Unlike a sequence
diagram, a collaboration diagram shows the relationships
among the instances. Sequence diagrams and collaboration
diagrams express similar information, but show it in
different ways. See: sequence diagram.
comment
An annotation attached to an element or a collection of

elements. A note has no semantics. Contrast: constraint.
compile time
Refers to something that occurs during the compilation of a

software module. See: modeling time, run time.
component
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 (e.g., implementation classes) that
reside on it, and may be implemented by one or more
artifacts (e.g., binary, executable, or script files). Contrast:
artifact.
component diagram
A diagram that shows the organizations and dependencies

among components.
composite [class]
A class that is related to one or more classes by a

composition relationship. See: composition.
composite aggregation
Synonym: composition.
composite state
A state that consists of either concurrent (orthogonal)

substates or sequential (disjoint) substates. See: substate.
composition
A form of aggregation which requires that a part instance be

included in at most one composite at a time, and that the
composite object is responsible for the creation and
destruction of the parts. Composition may be recursive.
Synonym: composite aggregation.
concrete class
A class that can be directly instantiated. Contrast: abstract

class.
concurrency
The occurrence of two or more activities during the same

time interval. Concurrency can be achieved by interleaving
or simultaneously executing two or more threads. See:
thread.
concurrent substate
A substate that can be held simultaneously with other

substates contained in the same composite state. See:
composite state. Contrast: disjoint substate.
E-615
E Glossary
E.2 Glossary Terms
constraint
A semantic condition or restriction. Certain constraints are

predefined in the UML, others may be user defined.
Constraints are one of three extensibility mechanisms in
UML. See: tagged value, stereotype.
container
1. An instance that exists to contain other instances, and that

provides operations to access or iterate over its contents.
(for example, arrays, lists, sets).
2. A component that exists to contain other components.
containment hierarchy
A namespace hierarchy consisting of model elements, and

the containment relationships that exist between them. A
containment hierarchy forms a graph.
context
A view of a set of related modeling elements for a particular

purpose, such as specifying an operation.
datatype
A descriptor of a set of values that lack identity and whose

operations do not have side effects. Datatypes include
primitive pre-defined types and user-definable types. Predefined types include numbers, string and time. Userdefinable types include enumerations.
defining model [MOF]
The model on which a repository is based. Any number of

repositories can have the same defining model.
delegation
The ability of an object to issue a message to another object

in response to a message. Delegation can be used as an
alternative to inheritance. Contrast: inheritance.
dependency
A relationship between two modeling elements, in which a

change to one modeling element (the independent element)
will affect the other modeling element (the dependent
element).
deployment diagram
A diagram that shows the configuration of run-time

processing nodes and the components, processes, and
objects that live on them. Components represent run-time
manifestations of code units. See: component diagrams.
derived element
A model element that can be computed from another

element, but that is shown for clarity or that is included for
design purposes even though it adds no semantic
information.
design
The part of the software development process whose

primary purpose is to decide how the system will be
implemented. During design strategic and tactical decisions
are made to meet the required functional and quality
requirements of a system.
E-616
design time
Refers to something that occurs during a design phase of the

software development process. See: modeling time.
Contrast: analysis time.
development process
A set of partially ordered steps performed for a given

purpose during software development, such as constructing
models or implementing models.
diagram
A graphical presentation of a collection of model elements,

most often rendered as a connected graph of arcs
(relationships) and vertices (other model elements). UML
supports the following diagrams: class diagram, object
diagram, use case diagram, sequence diagram, collaboration
diagram, state diagram, activity diagram, component
diagram, and deployment diagram.
disjoint substate
A substate that cannot be held simultaneously with other

substates contained in the same composite state. See:
composite state. Contrast: concurrent substate.
distribution unit
A set of objects or components that are allocated to a

process or a processor as a group. A distribution unit can be
represented by a run-time composite or an aggregate.
domain
An area of knowledge or activity characterized by a set of

concepts and terminology understood by practitioners in
that area.
dynamic classification
A semantic variation of generalization in which an object

may change its classifier. Contrast: static classification.
element
An atomic constituent of a model.
entry action
An action executed upon entering a state in a state machine

regardless of the transition taken to reach that state.
enumeration
A list of named values used as the range of a particular

attribute type. For example, RGBColor = {red, green, blue}.
Boolean is a predefined enumeration with values from the
set {false, true}.
event
The specification of a significant occurrence that has a

location in time and space. In the context of state diagrams,
an event is an occurrence that can trigger a transition.
exit action
An action executed upon exiting a state in a state machine

regardless of the transition taken to exit that state.
export
In the context of packages, to make an element visible

outside its enclosing namespace. See: visibility. Contrast:
export [OMA], import.
E-617
E Glossary
E.2 Glossary Terms
expression
A string that evaluates to a value of a particular type. For

example, the expression (7 + 5 * 3) evaluates to a value
of type number.
extend
A relationship from an extension use case to a base use

case, specifying how the behavior defined for the extension
use case augments (subject to conditions specified in the
extension) the behavior defined for the base use case. The
behavior is inserted at the location defined by the extension
point in the base use case. The base use case does not
depend on performing the behavior of the extension use
case. See extension point, include.
facade
A stereotyped package containing only references to model

elements owned by another package. It is used to provide a
public view of some of the contents of a package.
feature
A property, like operation or attribute, which is

encapsulated within a classifier, such as an interface, a
class, or a datatype.
final state
A special kind of state signifying that the enclosing

composite state or the entire state machine is completed.
fire
To execute a state transition. See: transition.
focus class
A stereotyped class that defines the core logic or control

flow for one or more auxiliary classes that support it. 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.
focus of control
A symbol on a sequence diagram that shows the period of

time during which an object is performing an action, either
directly or through a subordinate procedure.
formal parameter
Synonym: parameter.
framework
A stereotyped package that contains model elements which

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. See: pattern.
generalizable element
A model element that may participate in a generalization

relationship. See: generalization.
E-618
generalization
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 and contains
additional information. An instance of the more specific
element may be used where the more general element is
allowed. See: inheritance.
guard condition
A condition that must be satisfied in order to enable an

associated transition to fire.
implementation
A definition of how something is constructed or computed.

For example, a class is an implementation of a type, a
method is an implementation of an operation.
implementation class
A stereotyped class that 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. 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 types operations. See
also: type.
implementation
inheritance
The inheritance of the implementation of a more general

element. Includes inheritance of the interface. Contrast:
interface inheritance.
import
In the context of packages, a dependency that shows the

packages whose classes may be referenced within a given
package (including packages recursively embedded within
it). Contrast: export.
include
A relationship from a base use case to an inclusion use case,

specifying how the behavior for the base use case contains
the behavior of the inclusion use case. The behavior is
included at the location which is defined in the base use
case. The base use case depends on performing the behavior
of the inclusion use case, but not on its structure (i.e.,
attributes or operations). See extend.
inheritance
The mechanism by which more specific elements

incorporate structure and behavior of more general elements
related by behavior. See generalization.
initial state
A special kind of state signifying the source for a single

transition to the default state of the composite state.
instance
An entity that has unique identity, a set of operations that

can be applied to it, and state that stores the effects of the
operations. See: object.
E-619
E Glossary
E.2 Glossary Terms
interaction
A specification of how stimuli are sent between instances to

perform a specific task. The interaction is defined in the
context of a collaboration. See collaboration.
interaction diagram
A generic term that applies to several types of diagrams that

emphasize object interactions. These include collaboration
diagrams and sequence diagrams.
interface
A named set of operations that characterize the behavior of

an element.
interface inheritance
The inheritance of the interface of a more general element.

Does not include inheritance of the implementation.
Contrast: implementation inheritance.
internal transition
A transition signifying a response to an event without

changing the state of an object.
layer
The organization of classifiers or packages at the same level

of abstraction. A layer represents a horizontal slice through
an architecture, whereas a partition represents a vertical
slice. Contrast: partition.
link
A semantic connection among a tuple of objects. An

instance of an association. See: association.
link end
An instance of an association end. See: association end.
message
A specification of the conveyance of information from one

instance to another, with the expectation that activity will
ensue. A message may specify the raising of a signal or the
call of an operation.
metaclass
A class whose instances are classes. Metaclasses are

typically used to construct metamodels.
meta-metamodel
A model that defines the language for expressing a

metamodel. The relationship between a meta-metamodel
and a metamodel is analogous to the relationship between a
metamodel and a model.
metamodel
A model that defines the language for expressing a model.
metaobject
A generic term for all metaentities in a metamodeling

language. For example, metatypes, metaclasses,
metaattributes, and metaassociations.
E-620
method
The implementation of an operation. It specifies the

algorithm or procedure associated with an operation.
model
An abstraction of a physical system with a certain purpose.

See: physical system.
[MOF]
Usage note: In the context of the MOF specification, which

describes a meta-metamodel, for brevity the metametamodel is frequently to as simply the model.
model aspect
A dimension of modeling that emphasizes particular

qualities of the metamodel. For example, the structural
model aspect emphasizes the structural qualities of the
metamodel.
model elaboration
The process of generating a repository type from a

published model. Includes the generation of interfaces and
implementations which allows repositories to be instantiated
and populated based on, and in compliance with, the model
elaborated.
model element
An element that is an abstraction drawn from the system

being modeled. Contrast: view element.
[MOF]
In the MOF specification model elements are considered to

be metaobjects.
model library
A stereotyped package that contains model elements which

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.
modeling time
Refers to something that occurs during a modeling phase of

the software development process. It includes analysis time
and design time. Usage note: When discussing object
systems, it is often important to distinguish between
modeling-time and run-time concerns. See: analysis time,
design time. Contrast: run time.
module
A software unit of storage and manipulation. Modules

include source code modules, binary code modules, and
executable code modules. See: component.
multiple classification

may belong directly to more than one classifier. See: static
classification, dynamic classification.
E-621
E Glossary
E.2 Glossary Terms
multiple inheritance
A semantic variation of generalization in which a type may

have more than one supertype. Contrast: single inheritance.
multiplicity
A specification of the range of allowable cardinalities that a

set may assume. Multiplicity specifications may be given
for roles within associations, parts within composites,
repetitions, and other purposes. Essentially a multiplicity is
a (possibly infinite) subset of the non-negative integers.
Contrast: cardinality.
multi-valued [MOF]
A model element with multiplicity defined whose

Multiplicity Type:: upper attribute is set to a number greater
than one. The term multi-valued does not pertain to the
number of values held by an attribute, parameter, etc. at any
point in time. Contrast: single-valued.
n-ary association
An association among three or more classes. Each instance

of the association is an n-tuple of values from the respective
classes. Contrast: binary association.
name
A string used to identify a model element.
namespace
A part of the model in which the names may be defined and

used. Within a namespace, each name has a unique
meaning. See: name.
node
A node is classifier that represents a run-time computational

resource, which generally has at least a memory and often
processing capability. Run-time objects and components
may reside on nodes.
object
An entity with a well-defined boundary and identity that

encapsulates state and behavior. State is represented by
attributes and relationships, behavior is represented by
operations, methods, and state machines. An object is an
instance of a class. See: class, instance.
object diagram
A diagram that encompasses objects and their relationships

at a point in time. An object diagram may be considered a
special case of a class diagram or a collaboration diagram.
See: class diagram, collaboration diagram.
object flow state
A state in an activity graph that represents the passing of an

object from the output of actions in one state to the input of
actions in another state.
object lifeline
A line in a sequence diagram that represents the existence

of an object over a period of time. See: sequence diagram.
E-622
operation
A service that can be requested from an object to effect

behavior. An operation has a signature, which may restrict
the actual parameters that are possible.
package
A general purpose mechanism for organizing elements into

groups. Packages may be nested within other packages.
parameter
The specification of a variable that can be changed, passed,

or returned. A parameter may include a name, type, and
direction. Parameters are used for operations, messages, and
events. Synonyms: formal parameter. Contrast: argument.
parameterized element
The descriptor for a class with one or more unbound

parameters. Synonym: template.
parent
In a generalization relationship, the generalization of

another element, the child. See: subclass, subtype. Contrast:
child.
participate
The connection of a model element to a relationship or to a

reified relationship. For example, a class participates in an
association, an actor participates in a use case.
partition
1. activity graphs: A portion of an activity graphs that

organizes the responsibilities for actions. See: swimlane.
2. architecture: A set of related classifiers or packages at the
same level of abstraction or across layers in a layered
architecture. A partition represents a vertical slice through
an architecture, whereas a layer represents a horizontal
slice. Contrast: layer.
pattern
A template collaboration.
persistent object
An object that exists after the process or thread that created

it has ceased to exist.
postcondition
A constraint that must be true at the completion of an

operation.
precondition
A constraint that must be true when an operation is invoked.
primitive type
A pre-defined basic datatype without any substructure, such

as an integer or a string.
E-623
E Glossary
E.2 Glossary Terms
process
1. A heavyweight unit of concurrency and execution in an

operating system. Contrast: thread, which includes
heavyweight and lightweight processes. If necessary, an
implementation distinction can be made using stereotypes.
2. A software development processthe steps and
guidelines by which to develop a system.
3. To execute an algorithm or otherwise handle something
dynamically.
profile
A profile is a stereotyped package that contains model

elements which 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.
projection
A mapping from a set to a subset of it.
property
A named value denoting a characteristic of an element. A

property has semantic impact. Certain properties are
predefined in the UML; others may be user defined. See:
tagged value.
pseudo-state
A vertex in a state machine that has the form of a state, but

doesnt behave as a state. Pseudo-states include initial and
history vertices.
physical system
1. The subject of a model.

2. A collection of connected physical units, which can
include software, hardware and people, that are organized to
accomplish a specific purpose. A physical system can be
described by one or more models, possibly from different
viewpoints. Contrast: system.
published model [MOF]
A model that has been frozen, and becomes available for

instantiating repositories and for the support in defining
other models. A frozen models model elements cannot be
changed.
qualifier
An association attribute or tuple of attributes whose values

partition the set of objects related to an object across an
association.
receive [a message]
The handling of a stimulus passed from a sender instance.

See: sender, receiver.
receiver [object]
The object handling a stimulus passed from a sender object.

Contrast: sender.
E-624
reception
A declaration that a classifier is prepared to react to the

receipt of a signal.
reference
1. A denotation of a model element.

2. A named slot within a classifier that facilitates navigation
to other classifiers. Synonym: pointer.
refinement
A relationship that represents a fuller specification of

something that has already been specified at a certain level
of detail. For example, a design class is a refinement of an
analysis class.
relationship
A semantic connection among model elements. Examples of

relationships include associations and generalizations.
repository
A facility for storing object models, interfaces, and

implementations.
requirement
A desired feature, property, or behavior of a system.
responsibility
A contract or obligation of a classifier.
reuse
The use of a pre-existing artifact.
role
The named specific behavior of an entity participating in a

particular context. A role may be static (e.g., an association
end) or dynamic (e.g., a collaboration role).
run time
The period of time during which a computer program

executes. Contrast: modeling time.
scenario
A specific sequence of actions that illustrates behaviors. A

scenario may be used to illustrate an interaction or the
execution of a use case instance. See: interaction.
schema [MOF]
In the context of the MOF, a schema is analogous to a

package which is a container of model elements. Schema
corresponds to an MOF package. Contrast: metamodel,
package.
semantic variation point
A point of variation in the semantics of a metamodel. It

provides an intentional degree of freedom for the
interpretation of the metamodel semantics.
send [a message]
The passing of a stimulus from a sender instance to a

receiver instance. See: sender, receiver.
E-625
E Glossary
E.2 Glossary Terms
sender [object]
The object passing a stimulus to a receiver object. Contrast:

receiver.
sequence diagram
A diagram that shows object interactions arranged in time

sequence. In particular, it shows the objects participating in
the interaction and the sequence of messages exchanged.
Unlike a collaboration diagram, a sequence diagram
includes time sequences but does not include object
relationships. A sequence diagram can exist in a generic
form (describes all possible scenarios) and in an instance
form (describes one actual scenario). Sequence diagrams
and collaboration diagrams express similar information, but
show it in different ways. See: collaboration diagram.
signal
The specification of an asynchronous stimulus

communicated between instances. Signals may have
parameters.
signature
The name and parameters of a behavioral feature. A

signature may include an optional returned parameter.
single inheritance
A semantic variation of generalization in which a type may

have only one supertype. Synonym: multiple inheritance
[OMA]. Contrast: multiple inheritance.
single valued [MOF]
A model element with multiplicity defined is single valued

when its Multiplicity Type:: upper attribute is set to one.
The term single-valued does not pertain to the number of
values held by an attribute, parameter, etc., at any point in
time, since a single-valued attribute (for instance, with a
multiplicity lower bound of zero) may have no value.
Contrast: multi-valued.
specification
A declarative description of what something is or does.

Contrast: implementation.
state
A condition or situation during the life of an object during

which it satisfies some condition, performs some activity, or
waits for some event. Contrast: state [OMA].
statechart diagram
A diagram that shows a state machine. See: state machine.
state machine
A behavior that specifies the sequences of states that an

object or an interaction goes through during its life in
response to events, together with its responses and actions.
static classification

may not change classifier. Contrast: dynamic classification.
E-626
stereotype
A new type of modeling element that extends the semantics

of the metamodel. Stereotypes must be based on certain
existing types or classes in the metamodel. Stereotypes may
extend the semantics, but not the structure of pre-existing
types and classes. Certain stereotypes are predefined in the
UML, others may be user defined. Stereotypes are one of
three extensibility mechanisms in UML. See: constraint,
tagged value.
stimulus
The passing of information from one instance to another,

such as raising a signal or invoking an operation. The
receipt of a signal is normally considered an event. See:
message.
string
A sequence of text characters. The details of string

representation depend on implementation, and may include
character sets that support international characters and
graphics.
structural feature
A static feature of a model element, such as an attribute.
structural model aspect
A model aspect that emphasizes the structure of the objects

in a system, including their types, classes, relationships,
attributes, and operations.
subactivity state
A state in an activity graph that represents the execution of

a non-atomic sequence of steps that has some duration.
subclass

another class; the superclass. See: generalization. Contrast:
superclass.
submachine state
A state in a state machine which is equivalent to a

composite state but its contents is described by another state
machine.
substate
A state that is part of a composite state. See: concurrent

state, disjoint state.
subpackage
A package that is contained in another package.
subsystem
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 can be partitioned into specification and
realization elements. See package. See: physical system.
subtype

another type; the supertype. See: generalization. Contrast:
supertype.
E-627
E Glossary
E.2 Glossary Terms
superclass

another class; the subclass. See: generalization. Contrast:
subclass.
supertype

another type; the subtype. See: generalization. Contrast:
subtype.
supplier
A classifier that provides services that can be invoked by

others. Contrast: client.
swimlane
A partition on a activity diagram for organizing the

responsibilities for actions. Swimlanes typically correspond
to organizational units in a business model. See: partition.
synch state
A vertex in a state machine used for synchronizing the

concurrent regions of a state machine.
system
A top-level subsystem in a model. Contrast: physical

system.
tagged value
The explicit definition of a property as a name-value pair. In

a tagged value, the name is referred as the tag. Certain tags
are predefined in the UML; others may be user defined.
Tagged values are one of three extensibility mechanisms in
UML. See: constraint, stereotype.
template
Synonym: parameterized element.
thread [of control]
A single path of execution through a program, a dynamic

model, or some other representation of control flow. Also, a
stereotype for the implementation of an active object as
lightweight process. See process.
time event
An event that denotes the time elapsed since the current

state was entered. See: event.
time expression
An expression that resolves to an absolute or relative value

of time.
top level
A stereotype of package denoting the top-most package in a

containment hierarchy. The topLevel stereotype defines the
outer limit for looking up names, as namespaces see
outwards. For example, opLevel subsystem represents the
top of the subsystem containment hierarchy.
E-628
trace
A dependency that indicates a historical or process

relationship between two elements that represent the same
concept without specific rules for deriving one from the
other.
transient object
An object that exists only during the execution of the

process or thread that created it.
transition
A relationship between two states indicating that an object

in the first state will perform certain specified actions and
enter the second state when a specified event occurs and
specified conditions are satisfied. On such a change of state,
the transition is said to fire.
type
A stereotyped class that 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. Although an object may have at
most one implementation class, it may conform to multiple
different types. See also: implementation class Contrast:
interface.
type expression
An expression that evaluates to a reference to one or more

types.
uninterpreted
A placeholder for a type or types whose implementation is

not specified by the UML. Every uninterpreted value has a
corresponding string representation. See: any [CORBA].
usage
A dependency in which one element (the client) requires the

presence of another element (the supplier) for its correct
functioning or implementation.
use case [class]
The specification of a sequence of actions, including

variants, that a system (or other entity) can perform,
interacting with actors of the system. See: use case
instances.
use case diagram
A diagram that shows the relationships among actors and

use cases within a system.
use case instance
The performance of a sequence of actions being specified in

a use case. An instance of a use case. See: use case class.
use case model
A model that describes a systems functional requirements

in terms of use cases.
E-629
E Glossary
E.2 Glossary Terms
utility
A stereotype that groups global variables and procedures in

the form of a class declaration. The utility attributes and
operations become global variables and global procedures,
respectively. A utility is not a fundamental modeling
construct, but a programming convenience.
value
An element of a type domain.
vertex
A source or a target for a transition in a state machine. A

vertex can be either a state or a pseudo-state. See: state,
pseudo-state.
view
A projection of a model, which is seen from a given

perspective or vantage point and omits entities that are not
relevant to this perspective.
view element
A view element is a textual and/or graphical projection of a

collection of model elements.
view projection
A projection of model elements onto view elements. A view

projection provides a location and a style for each view
element.
visibility
An enumeration whose value (public, protected, or private)

denotes how the model element to which it refers may be
seen outside its enclosing namespace.
E-630
General Index
A
Action 91, 105

action 97, 112, 132
Action (extended) 190
action expression 386
action label 371
ActionOccurrence 132
active class 316
Activity 236, 429
activity 244, 250, 251, 275
activity in a state 368
Activity Modeling 527
ActivityEdge 244, 430
ActivityFinal 247
ActivityGeneralization 433
ActivityGeneralizationKind 434
ActivityGroup 250, 434
ActivityNode 251, 434
ActivityParameter 253, 435
ActivityPartition 255
AddAttributeValueAction 191
addOnly 38
AddVariableValueAction 192
after 139
aggregateEnd 51
Aggregation 50
alias 9
annotatedElement 4
ApplyFunctionAction 194
argument 94, 95, 98, 102, 143, 147, 194, 196, 405,
413, 422
arrow
solid
for transition 386
Artifact 322, 334, 466, 506
AssemblyConnector 322, 337, 466
Association 52
association 57, 200
AssociationClass 460
AssociationEnd 57, 462
associationEnd 463
AtomicFragment 136
Attribute 42, 463
attribute 31, 195
attribute template parameter 515
AttributeAction 195
AutonomousElement 8
bar (fork and join) 363

Behavior (in Activities) 259
behavioral state machine 376
BehavioralFeature 37
Binding 515
binding 517
BlockActivityGroup 262, 437
body 4, 198, 210, 212
bodyOutput 402
braces
for property string 35, 44, 141, 518
BroadcastSignalAction 94
bulls eye
for final state 359, 366
Index-General.fm Version 2 beta R1
C
CallBehaviorAction 197
CallOperationAction 95
CentralBufferNode 260, 437
ChangeabilityKind 38
ChangeSignal 262, 437
ChangeSpec 262
choice (PseudostateKind) 361, 365
circle
bulls eye
for final state 359, 366
filled
for initial state 361, 366
Class 45, 274, 441
Classifier 31
classifier 65, 68, 206, 418, 419
classifier context
of state machine 376
classifier template parameter 515
Clause 402
clause 203
Clause (extended) 400, 402
ClearAssociationAction 200
ClearAttributeAction 199
ClearVariableAction 201
CollectionAction 402
collectionInput 408
colon
for sequence expression 571
631
for type 35, 44, 141, 158, 163, 518

CombinedFragment 132
Comment 4
completion event 385
completion transition 385
Component 322, 466
Composite state 366
Composite state (semantics) 369
Composite state extension 379
Compound transition 384
concurrency
in state machine 378
concurrent substate 365
ConditionalAction 403
conflict 378
conformance (of StateMachine) 376, 502
connection 367
connectionPoint (of StateMachine) 376
connector 147
Constraint 9, 18
constraint 15
Container 337
container 468
container (StateVertex) 383
containing 132
contents 439
context
of state machine 376
control icons 387
ControlFlow 263
ControlNode 265
covered 142
coveredBy 146
CreateLinkAction 204
CreateLinkObjectAction 205, 403
CreateObjectAction 205
DelegationConnector 338
deployedArtifact 339
deployedComponent 343
Deployment 338
deployment 335, 343
deploymentDescriptor 468
deploymentLocation 468
DeploymentSpecification 343
Derivation 517
derived classifier 515, 516, 517
DestroyLinkAction 206
DestroyObjectAction 207
DirectedRelationship 5
direction 39
do activity 368
do activity (notation) 371
doActivity (State) 367, 376
document (Component) 335
dot
for sequence expression 571
D
DataStoreNode 437
DataType 62
decisionInput 267
DecisionNode 266
declarative protocol state machines 502
decomposedAs 145
deepHistory (PseudostateKind) 360, 365, 369
default 39, 43, 519
default entry 369
defer (keyword) 387
deferrableEvent (State) 367
deferred event 368, 369, 387
definingFeature 71
definition (ConnectionPoint) 357
edge 237
edgeContents 250
effect 446
effect (Transition) 383
Element 6
ElementImport 9
elementImport 16, 73
enabled
transition 385
enabled transition 385
encloser 149
enclosingOperand 142
end 51, 52, 216, 416
endData 204, 213, 410
entering a concurrent composite state 369
entry (ConnectionPoint) 357
entry (State) 367
entry action 368
entry action (notation) 371
entry point 358, 373
entry point (kind of Pseudostate) 361
entry point (PseudostateKind) 365
Enumeration 64
EnumerationValue 65
equal sign
for initial value 35, 44, 141, 518
event 140
event signature 386
EventOccurrence 136
events 145
632
executable (Component) 335

executable protocol state machines 502
executionLocation 468
ExecutionOccurrence 138
exit (ConnectionPoint) 357
exit (State) 367
exit action 368
exit action (notation) 371
exit point 358, 373
exiting a concurrent state 369
exiting a non-concurrent state 369
explicit entry 369
Expression 21
expressiongate 133
extendedPackage 75
extendedRegion 365
extendedState 367
extendedStateMachine 376
extendingpackage 75
F
Feature 33
feature 32
featuringClassifier 33
file (Component) 335
FilterAction 404
final state 359, 366
FinalNode 269
finish 138
finishExec 137
fire a transition 377
first 226
FlowFinal 270
fork (PseudostateKind) 361, 365
ForkNode 272
formalGate 139, 140
formalParameter 48
fragment 145
function 194
G
Gate 139
general 34
Generalization 34
429
generalization 32
generalMachine 497
group 237, 244, 250, 251
GroupAction 407
Guard 359, 385
guard 145, 244

Guard (Trigger) 383
guard constraint 386
H
HandlerAction 209
handlerOutput 210
high-level transition 384
history
deep 369
shallow 369
I
implementationClass (Class) 629
implementingArtifact 466
import 16
importedElement 10
importedMember 16
importedNamespace 12
importedPackage 81
importingNamespace 10, 12
include 371
include (keyword) 373
incoming 251
incoming (StateVertex) 383
inheritedMember 32
initial (PseudostateKind) 360, 364
initial state 361, 366
InitialNode 273
input 92, 207, 213, 419, 420, 424
input event icon 387
InputPin 96
insertAt 191, 193, 215
instance 70
InstanceSpecification 67
InstanceValue 70
inState 449
Interaction 140
interaction 145, 147, 149
InteractionConstraint 141
InteractionFragment 142
InteractionOccurrence 143
InteractionOperand 144
interactionOperator 133
internal transition 385
internal transition compartment 371
internalTransition (State) 367, 383
InterruptibleActivityRegion 274, 438
interruptingEdge 439
invariant 152
633
InvocationNode 251, 434

isAbstract 31
isComposite 50
isComposite (derived attribute of State) 367
isConcurrent (CompositeState) 367
isDerived 43, 52
isDeterminate 203
isDimension 255
isDirect 419
isException 451
isExpanded 8
isExternal 255
isInternal (Transition) 383
isLeaf 32
isMap 441
isMultiCast 446
isMultireceive 446
isOrdered 27
isOrthogonal (derived attribute of State) 367
isReadOnly 92
isReentrant 259
isReplaceAll 191, 193, 215, 420
isSet 294
isSimple (derived attribute of State) 367
isSingleCopy 237
isStatic 33
isSubmachineState (derived attribute of State) 367
isSynchronous 95, 196, 441, 451
isUnordered 408, 421
IterateAction 407
iteration indicator 571
IterationActivityGroup 278, 444
IterationActivityGroupKind 279, 444
J
join (PseudostateKind) 361, 365
JoinNode 280, 444
joinSpec 444
jump type 211
JumpAction 211
JumpHandler 212
jumpHandler 190, 210
jumpOccurrence 211
jumpType 213
junction (PseudostateKind) 361, 365
K
kind 237, 278, 433
kind (PseudoState) 360
L
leftSubinput 422
library (Component) 335
Lifeline 145
lifeline 137, 140, 152
LinkAction 213, 410
LinkEndCreationData 214
LinkEndData 215, 411
LiteralBoolean 22
LiteralInteger 23
LiteralNull 23
LiteralSpecification 24
LiteralString 24
localPostcondition 442
localPrecondition 442
location 337, 339
LoopAction 412
loopVariable 408, 412
loopVariableInput 408, 412
lower 27
M
MapAction 413
mapMultiplicity 441
maxint 142
member 15
MemberImport 12
MergeNode 281, 446
Message 146
message 140
MessageEnd 148
messageKind 147
messageSort 147
messageString 147
minint 142
Multiplicity 27
multiplicity 25, 41
mustIsolate 407
N
name 13, 139
name compartment 371
NamedElement 7, 13
Namespace 14, 25
namespace 13
NavigableEnd 59
nested state 365
nestedClassifier 46
nesting
for composition 161
634
newClassifier 420
Node 343
node 237
nodeContents 250
O
object 195, 200, 416, 417
ObjectFlow 283, 446
ObjectNode 285, 449
ObjectNodeOrderingKind 285, 449, 451
objectNodeSet 449
occurrence 210
jump 211
oldClassifiers 420
operand 133
Operation 47
operation 95
operation template parameter 518
ordering 449
otherEnd 57, 60
outgoing 251
outgoing (StateVertex) 383
output 92, 403
output event icon 387
OutputPin 97
ownedAttribute 46, 63
ownedComment 6
ownedElement 6
ownedMember 15, 16
ownedOperation 46, 63
owner 6
owningInstance 71
P
Package 72
PackageExtension 74
packageExtension 73
PackageImport 81
packageImport 73
PackagingNamespace 16
Parameter 39, 98
237
parameter 38
Parameter (in Activities) 451
ParameterDirectionKind 39
parameterInSet 453
ParameterSet 287, 452
parameterSet 451
ParameterUsageNode 278, 444
parentheses
for parameter list 359, 372, 386

Part (as extended) 345
PartDecomposition 149
partEnd 51
partition 237, 244, 251, 255
passive class 316
Pattern 305
pentagon
for signal receipt 387
for signal sending 387
points 373
Port (as extended) 156
port (Event in Statemachine) 358
postCondition 498
postcondition 48
preCondition 498
precondition 48
predecessor 92
PrimitiveAction 99
PrimitiveType 66
priority of transition 378
Procedure 99
procedure 152
Procedure (extended) 219
ProcedureOccurrence 151
Profile 527, 528, 529, 535, 541, 542, 545, 547, 553,
554, 557, 558, 563, 570, 575, 579, 580, 583, 587,
589, 591, 593
protectedAction 213
protocol 497
protocol state machine 501
Q
qualifiedName 13
qualifier 411, 415, 417, 462
QualifierValue 415
R
raisedException 48
ReadAttributeAction 220
ReadExtentAction 418
ReadLinkAction 221
ReadLinkObjectEndAction 222, 416
ReadLinkObjectQualifierAction 417
readOnly 38
ReadSelfAction 222
ReadVariableAction 223
realizationElement 507
receiveEvent 147
receiveMessage 149
635
ReclassifyObjectAction 420
rectangle
rounded ends
for state 370
recurrence 571
RedefinableElement 35
redefinedAttribute 43
redefinedClassifier 32
redefinedElement 35
redefinedEnd 58
redefinedOperation 48
redefinitionContext 36
ReduceAction 421
referencingClassifier 60
referred 498
refers to 143
region 430, 435
region (of StateMachine) 376
relatedElement 7
Relationship 7
RemoveAttributeValueAction 224
removeOnly 38
RemoveVariableValueAction 225
replacedEdge 430
replacedNode 435
replacedTransition (Transition) 383
represents 145, 255
request 101
result 95, 194, 197, 206, 220, 221, 222, 223, 226, 404,
405, 408, 412, 414, 418, 419, 422
ReturnResult 40
returnResult 38, 48
rightSubinput 422
run to completion 377
S
second 226
selection 446, 449
selector 145
sendEvent 147
sendMessage 149
settability 41
shallowHistory (PseudostateKind) 360, 365, 369
signal 94, 102
signal receipt icon 387
signal sending icon 387
SignalNode 290
signature 147
Simple state 366
Simple state extension 379
slash
for action expression 386
Slot 70
slot 68
source 5, 97, 244
source (Transition) 383
specific 34
specification 68, 467
specificationElement 507
specificMachine 497
square brackets
for attribute multiplicity 35, 44, 141, 518
for condition clause 571
for guard condition 372, 386
star
for iteration indicator 571
start 138
startExec 137
StartObjectStateMachineAction 423
state list 364
State redefinition 368
statechart diagram 379
stateGroup 360
StateInvariant 152
stateInvariant 145, 501
statemachine
as the behaviour specification of a behavioral feature, as the behaviour specification of a
classifier 376
StateMachine extension 379
StateMachine extension (multiple) 379
States (Notation) 370
stop (kind of PseudoState) 361
StructuralFeature 40
StructuredActivityGroup 292
subaction 402, 405, 409, 414, 422
subgroup 250
subinput 405, 409, 414
submachine 367
submachine invocation 371
Submachine state 367
Submachine state (semantics) 370
SubmachineState 383
submachineState 360
SubmachineState redefinition 379
suboutput 409, 414, 422
subpartition 255
substate 366
Subsystem 506
subtest 405
subvertex (Region) 365
successor 92, 198
SynchState 377
636
target 5, 95, 101, 102, 244

target (Transition) 383
taxonomic relationship 34
template 517
collaboration 305
template classifier 515
template parameter 516
TemplateParameter 518
templateParameter 515, 518, 519
ternary association 55
test 278
TestIdentityAction 226
testOutput 198, 217
tiling (a state) 365
TimeSignal 293
timeSpec 293
toAfter 137
toBefore 137
top 376, 502
transformation 446
Transition
execution 385
firing rules 378
transition 365, 376, 502
string 386
Transition redefinition 379
trigger (Transition) 383
290
type 41
type (Class) 613, 618
TypedElement 30, 41
TypedElement (in Activities) 294
weight 430
WriteAttributeAction 228, 230
WriteLinkAction 229
X
XMI 609
U
ubmachine state redefinition 379
unordered execution 408
unrestricted 38
upper 28
upperBound 449
V
value 22, 23, 25, 71, 216, 228, 230, 415
value specification template parameter 520
ValueSpecification 25
variable 228
VariableAction 227
visibility 8, 9, 12, 13, 81
VisibilityKind 7, 17
637
638
Index of Classes
A
Action 91, 105
Activity 236, 429
ActivityEdge 244, 430
ActivityFinal 247
ActivityGroup 250, 434
ActivityNode 251, 434
Aggregation 50
Artifact 322, 334, 466, 506
AssemblyConnector 322, 337, 466
Association 52
AssociationEnd 57, 462
AtomicFragment 136
Attribute 42, 463
AttributeAction 195
AutonomousElement 8
Comment 4
Component 322, 466
Constraint 9, 18
Container 337
ControlFlow 263
ControlNode 265
CreateLinkObjectAction 205, 403
D
DataStoreNode 437
DataType 62
DecisionNode 266
DelegationConnector 338
Deployment 338
Derivation 517

Binding 515
BlockActivityGroup 262, 437
Element 6
ElementImport 9
Enumeration 64
EnumerationValue 65
EventOccurrence 136
Expression 21
C
CentralBufferNode 260, 437
ChangeSignal 262, 437
Class 45, 274, 441
Classifier 31
Clause 402
Clause (extended) 400, 402
Index-Classes.fm Version 2 beta R1
F
Feature 33
FinalNode 269
FlowFinal 270
ForkNode 272
639
Gate 139
NamedElement 7, 13
Namespace 14, 25
NavigableEnd 59
Node 343
H
HandlerAction 209
O
I
InitialNode 273
InputPin 96
Interaction 140
InterruptibleActivityRegion 274, 438
InvocationNode 251, 434
IterateAction 407
IterationActivityGroup 278, 444
IterationActivityGroupKind 279, 444
J
JoinNode 280, 444
JumpAction 211
JumpHandler 212
L
Lifeline 145
LinkAction 213, 410
LinkEndData 215, 411
LiteralBoolean 22
LiteralInteger 23
LiteralNull 23
LiteralString 24
ObjectFlow 283, 446

ObjectNode 285, 449
ObjectNodeOrderingKind 285, 449, 451
Operation 47
OutputPin 97
P
Package 72
PackageExtension 74
Parameter 39, 98
parameterInSet 453
ParameterSet 287, 452
parameterSet 451
ParameterUsageNode 278, 444
Part (as extended) 345
Port (as extended) 156
PrimitiveAction 99
PrimitiveType 66
Procedure 99
Profile 527, 528, 529, 535, 541, 542, 545, 547,
553, 554, 557, 558, 563, 570, 575, 579, 580,
583, 587, 589, 591, 593
Q
QualifierValue 415
MapAction 413
MemberImport 12
MergeNode 281, 446
Message 146
MessageEnd 148
Multiplicity 27
ReadLinkAction 221
ReadLinkObjectEndAction 222, 416
ReadSelfAction 222
640
ReduceAction 421
Relationship 7
ReturnResult 40
S
SignalNode 290
Slot 70
StateInvariant 152
Subsystem 506
T
TemplateParameter 518
TimeSignal 293
TypedElement 30, 41
V
VariableAction 227
VisibilityKind 7, 17
W
WriteAttributeAction 228, 230
WriteLinkAction 229
641
642
Index of Classes
Abstraction 114
Action 105
Activity 236
Activity 429
ActivityEdge 244
ActivityEdge 430
ActivityFinal 247
ActivityGroup 250
ActivityNode 251
ActivityNode 434
ActivityParameter 253
ActivityParameter 435
Actor 166
Aggregation 50
Artifact 334
Association 52
AssociationEnd (extended) 462
AssociationEnd 57
Attribute (extended) 302
Attribute 42
AttributeAction 195
AutonomousElement (extended) 337
AutonomousElement 8
Behavior 106
BehavioralFeature (extended) 108
BehavioralFeature (extended) 313
BehavioredClassifier 109
BehaviorInvocation 109
BinaryObject 337
Binding 515
CallConcurrencyKind 314
CallEvent 314
CentralBufferNode 260
ChangeEvent 315
ChangeSignal 262
Class (extended) 122
Class 45
Classifier (extended) 115
Classifier 31
Clause (extended) 402
Clause 197
Collaboration 304
CollaborationOccurrence 306
Comment 4
CommunicationPath 338
ComplexPort 348
Component 322
ComponentAssembly 466
ComponentDeployment 467
ComponentImport 330
CompositeAction 201
ConditionalAction (extended) 403
ConnectableElement 156
ConnectionPoint 357
Connector 157
Connector 349
ConnectorEnd 159
ConnectorEnd 349
ConnectorKind 160
Constraint 18
644
Constraint 9
ControlFlow 263
ControlNode 265
CreateLinkObjectAction 403
DataStoreNode 437
DataType 62
DecisionNode 266
Dependency 116
Deployment 338
Derivation 517
Device 340
Element 6
ElementImport 9
EncapsulatedClassifier 350
Enumeration 64
EnumerationValue 65
Event (extended) 358
Event 316
EventOccurrence 136
ExecutionEnvironment 341
Expression (extended) 110
Expression 21
Extend 168
ExtensionPoint 170
Feature 33
FilterAction 404
FinalNode 269
FinalState 359
FlowFinal 270
ForkNode 272
Gate 139
Generalization (extended) 474
Generalization 34
GeneralizationSet 477
GeneralOrdering 139
GroupAction (extended) 407
GroupAction 208
HandlerAction 209
IJoinNode 444
Implementation 125
Include 171
InformationFlow 486
InformationItem 487
InitialNode 273
InputPin 96
InstanceValue 70
Interaction 140
Interface (extended) 317
Interface (extended) 496
Interface 122
InterruptibleActivityRegion 438
InvocationNode 274
InvocationNode 441
IterateAction 407
IterationActivityGroup 278
IterationActivityGroupKind 279
JoinNode 280
JumpAction 211
JumpHandler 212
Lifeline 145
LinkAction (extended) 410
LinkAction 213
LinkEndData (extended) 411
LinkEndData 215
LiteralBoolean 22
LiteralInteger 23
LiteralNull 23
LiteralString 24
LoopAction (extended) 412
LoopAction 216
MapAction 413
MemberImport 12
MergeNode 281
Message 146
MessageEnd 148
Model 492
Multiplicity (extended) 218
Multiplicity 27
646
NamedElement (extended) 117

NamedElement 13
NamedElement 7
Namespace 14
Namespace 25
NavigableEnd 59
Network 342
Node 343
ObjectFlow 283
ObjectFlow 446
ObjectFlowEffectKind 449
ObjectNode 285
ObjectNode 449
ObjectNodeOrderingKind 451
Operation (extended) 303
Operation (extended) 518
Operation 47
OutputPin 97
Package 72
PackageExtension 74
PackageImport 81
Parameter (extended) 110
Parameter 39
ParameterableElement 518
ParameterSet 452
ParameterUsageNode 287
ParameterUsageNode 454
Part (extended) 519
Part 161
Permission 117
Pin 111
Port (extended) 299
Port 350
Port 497
PrimitiveAction 99
PrimitiveFunction 218
PrimitiveType 66

Procedure 112
ProtocolConformance 497
ProtocolStateMachine 501
ProtocolTransition 498
PseudoState 359
PseudoStateKind 364
QualifierValue 415
ReadIsClassifiedObjectAction 419
ReadLinkAction 221
ReadLinkObjectEndAction 416
ReadSelfAction 222
Realization 118
Reception 317
ReduceAction 421
Region 365
Relationship 7
ReturnResult 40
RoleBinding 309
SendObjectAction 101
SendSignalAction 102
Signal 318
SignalEvent 319
SignalNode 290
Slot 70
State (extended) 501
State 366
StateInvariant 152
StateMachine 376
StateVertex (extended) 225
StateVertex 382
StructuredClassifier 162
Substitution 118
Subsystem 506
TimeEvent 320
648
TimeSignal 293
Transition 383
TypedElement (in Activities) 294
TypedElement 30
TypedElement 41
Usage 119
UseCase 172
ValueSpecification (extended) 520
Variable 227
VariableAction 228
VisibilityKind 17
VisibilityKind 7
WriteAttributeAction 228
WriteLinkAction 229
WriteVariableAction 230
650
Index of Features
A
action 97, 112, 132
activity 244, 250, 251, 275
after 139
aggregateEnd 51
alias 9
annotatedElement 4
argument 94, 95, 98, 102, 143, 147, 194, 196,
405, 413, 422
association 57, 200
associationEnd 463
attribute 31, 195
B
binding 517
body 4, 198, 210, 212
bodyOutput 402
C
ChangeSpec 262
classifier 65, 68, 206, 418, 419
clause 203
collectionInput 408
conformance (of StateMachine) 376, 502
connection 367
connectionPoint (of StateMachine) 376
connector 147
constraint 15
container 468
containing 132
contents 439
covered 142
coveredBy 146
D
decisionInput 267
declarative protocol state machines 502
decomposedAs 145
default 39, 43, 519
deferrableEvent (State) 367
definingFeature 71
Index-Features.fm Version 2 beta R1
definition (ConnectionPoint) 357

deployedArtifact 339
deployedComponent 343
deployment 335, 343
deploymentDescriptor 468
deploymentLocation 468
direction 39
E
edge 237
edgeContents 250
elementImport 16, 73
encloser 149
enclosingOperand 142
end 51, 52, 216, 416
endData 204, 213, 410
entry (ConnectionPoint) 357
entry (State) 367
entry point (kind of Pseudostate) 361
event 140
events 145
executable protocol state machines 502
executionLocation 468
exit (ConnectionPoint) 357
expressiongate 133
extendedPackage 75
extendedRegion 365
extendedState 367
extendedStateMachine 376
extendingpackage 75
F
feature 32
featuringClassifier 33
FilterAction 404
finish 138
finishExec 137
first 226
formalGate 139, 140
formalParameter 48
fragment 145
function 194
651
isSubmachineState (derived attribute of State) 367

isSynchronous 95, 196, 441, 451
isUnordered 408, 421
general 34
429
generalization 32
generalMachine 497
group 237, 244, 250, 251
GroupAction 407
guard 145, 244
J
joinSpec 444
jumpHandler 190, 210
jumpOccurrence 211
jumpType 213
H
handlerOutput 210
K
kind 237, 278, 433
kind (PseudoState) 360
I
implementingArtifact 466
import 16
importedElement 10
importedMember 16
importedNamespace 12
importedPackage 81
importingNamespace 10, 12
incoming 251
inheritedMember 32
input 92, 207, 213, 419, 420, 424
insertAt 191, 193, 215
instance 70
inState 449
interaction 145, 147, 149
interactionOperator 133
interruptingEdge 439
invariant 152
isAbstract 31
isComposite 50
isComposite (derived attribute of State) 367
isDerived 43, 52
isDeterminate 203
isDirect 419
isException 451
isExpanded 8
isLeaf 32
isMap 441
isMultiCast 446
isOrdered 27
isOrthogonal (derived attribute of State) 367
isReadOnly 92
isReentrant 259
isReplaceAll 191, 193, 215, 420
isSet 294
isSimple (derived attribute of State) 367
isSingleCopy 237
isStatic 33
L
leftSubinput 422
lifeline 137, 140, 152
location 337, 339
LoopAction 412
loopVariable 408, 412
loopVariableInput 408, 412
lower 27
M
mapMultiplicity 441
maxint 142
member 15
message 140
messageKind 147
messageSort 147
messageString 147
minint 142
multiplicity 25, 41
mustIsolate 407
N
name 13, 139
namespace 13
nestedClassifier 46
newClassifier 420
node 237
nodeContents 250
652
O
object 195, 200, 416, 417
objectNodeSet 449
occurrence 210
oldClassifiers 420
operand 133
operation 95
ordering 449
otherEnd 57, 60
outgoing 251
output 92, 403
ownedAttribute 46, 63
ownedComment 6
ownedElement 6
ownedMember 15, 16
ownedOperation 46, 63
owner 6
owningInstance 71
redefinedEnd 58
redefinedOperation 48
redefinitionContext 36
referencingClassifier 60
referred 498
refers to 143
region 430, 435
region (of StateMachine) 376
relatedElement 7
replacedEdge 430
replacedNode 435
represents 145, 255
request 101
result 95, 194, 197, 206, 220, 221, 222, 223, 226,
404, 405, 408, 412, 414, 418, 419, 422
returnResult 38, 48
rightSubinput 422
S
P
packageExtension 73
PackageImport 81
packageImport 73
parameter 38
partEnd 51
partition 237, 244, 251, 255
port (Event in Statemachine) 358
postCondition 498
postcondition 48
preCondition 498
precondition 48
predecessor 92
procedure 152
protectedAction 213
protocol 497
Q
qualifiedName 13
qualifier 411, 415, 417, 462
R
raisedException 48
realizationElement 507
receiveEvent 147
receiveMessage 149
redefinedAttribute 43
redefinedClassifier 32
redefinedElement 35
second 226
selection 446, 449
selector 145
sendEvent 147
sendMessage 149
settability 41
signal 94, 102
signature 147
slot 68
source 5, 97, 244
specific 34
specification 68, 467
specificationElement 507
specificMachine 497
start 138
startExec 137
stateGroup 360
stateInvariant 145, 501
subaction 402, 405, 409, 414, 422
subgroup 250
subinput 405, 409, 414
submachine 367
submachineState 360
suboutput 409, 414, 422
subpartition 255
subtest 405
successor 92, 198
T
target 5, 95, 101, 102, 244
template 517
653
templateParameter 515, 518, 519

test 278
testOutput 198, 217
timeSpec 293
toAfter 137
toBefore 137
top 376, 502
transformation 446
transition 365, 376, 502
type 41
U
upper 28
upperBound 449
V
value 22, 23, 25, 71, 216, 228, 230, 415
variable 228
visibility 8, 9, 12, 13, 81
W
weight 430
654

MASTER UML 2.0 Superstructure

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MASTER UML 2.0 Superstructure

Uploaded by

Copyright:

Available Formats

ad/2002-09-02

Date: 9 September 2002

Revised submission to OMG RFP ad/00-09-02:

Unified Modeling Language: Superstructure

Copyright 2001-2002 U2 Partners (www.u2-partners.org).

Part II. UML::Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

TOC.fm Version 2 beta R1

September 9, 2002 11:32 am

Part III. UML::Common . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Part IV. UML::Complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

Part V. Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

TOC.fm Version 2 beta R1

September 9, 2002 11:32 am

Chapter 30. Activity Diagrams - Common . . . . . . . . . . . . . . . . . . . . 527

TOC.fm Version 2 beta R1

September 9, 2002 11:32 am

Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579

TOC.fm Version 2 beta R1

September 9, 2002 11:32 am

0.1 Submission summary

0.1. Submission summary

Cris Kobryn (Cris.Kobryn@telelogic.com)

Guus Ramackers (Guus.Ramackers@oracle.com)

Bran Selic (bselic@rational.com)

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

0.2 Resolution of RFP requirements

0.2. Resolution of RFP requirements

6.5.1 a: Proposals shall enforce a clear

The proposed specification defines the semantics and notation for

6.5.1 b: Proposals shall minimize the

The proposed speficication defines precise mappings between UML

6.5.1 c: Proposals shall identify language

UML language constructs recommended for retirement will be

6.5.1 d: Proposals shall specify an XMI

The specification of a UML 2.0 XMI Schema for this proposal is

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

0.2 Resolution of RFP requirements

Proposals shall support component

Proposals shall support the specification of common interaction patterns that

The modeling of the internal structure of classifiers is addressed in

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

0.2 Resolution of RFP requirements

Proposals shall specify what refine

The requirements for state machines are addressed in the following

Proposals shall clarify the semantics

The requirements for activity graphs are addressed in the following

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

0.2 Resolution of RFP requirements

Proposals shall provide mechanisms

To be addressed in a future version of this proposal.

Proposals may support the grouping

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

0.3 Responses to RFP issues to be discussed

Table 2: Superstructure RFP Optional Requirements

Proposals may provide an improved

The revisions to Classes with internal structure and Interactions

0.3. Responses to RFP issues to be discussed

0.4. Optional versus mandatory interfaces

0.5. Proposed compliance points