You are on page 1of 670

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
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Chapter 7. Basic::Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Chapter 8. Basic::Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Semantic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Chapter 9. Basic::InternalStructures . . . . . . . . . . . . . . . . . . . . . . . . 155
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Chapter 10. Basic::UseCases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

TOC.fm Version 2 beta R1

September 9, 2002 11:32 am

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


Chapter 11. Common::Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Chapter 12. Common::Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Chapter 13. Common::Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Chapter 14. Common::Collaborations . . . . . . . . . . . . . . . . . . . . . . . 301
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Chapter 15. Common::CommonBehaviors. . . . . . . . . . . . . . . . . . . . 311
Class Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Chapter 16. Common::Components . . . . . . . . . . . . . . . . . . . . . . . . . 321
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Chapter 17. Common::Deployments . . . . . . . . . . . . . . . . . . . . . . . . . 333
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Chapter 18. Common::Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Chapter 19. Common::StateMachines. . . . . . . . . . . . . . . . . . . . . . . . 355
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

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


Chapter 20. Complete::Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Chapter 21. Complete::Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Chapter 22. Complete::Associations . . . . . . . . . . . . . . . . . . . . . . . . . 459
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Chapter 23. Complete::ComponentDeployments. . . . . . . . . . . . . . . 465
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Chapter 24. Complete::Generalizations . . . . . . . . . . . . . . . . . . . . . . 471
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Chapter 25. Complete::InformationFlows . . . . . . . . . . . . . . . . . . . . 485
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Chapter 26. Complete::Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Chapter 27. Complete::ProtocolStateMachines . . . . . . . . . . . . . . . . 495
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Chapter 28. Complete::Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Chapter 29. Complete::Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Class Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

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

TOC.fm Version 2 beta R1

September 9, 2002 11:32 am

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
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Chapter 32. Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Chapter 33. Component Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Chapter 34. Component Deployment Diagrams. . . . . . . . . . . . . . . . 553
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Chapter 35. Deployment Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Chapter 36. Interaction Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Communication Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Interaction Overview Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Timing Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Chapter 37. Internal Structure Diagrams . . . . . . . . . . . . . . . . . . . . . 579
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579

TOC.fm Version 2 beta R1

September 9, 2002 11:32 am

iii

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


Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Chapter 38. Package Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Graphic Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Graphic Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
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
Changes from UML 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596

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

TOC.fm Version 2 beta R1

September 9, 2002 11:32 am

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

September 9, 2002 11:33 am

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.

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

vi

0.2 Resolution of RFP requirements

MANDATORY REQUIREMENT
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.

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

vii

0.2 Resolution of RFP requirements

MANDATORY REQUIREMENT
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.

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

viii

0.2 Resolution of RFP requirements

MANDATORY REQUIREMENT
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.

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

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.

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

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

no/incomplete, complete, complete XMI schema

Basic::
CommonBehaviors

no/incomplete, complete, complete XMI schema

Basic::Dependencies

no/incomplete, complete, complete XMI schema

Basic::Interfaces

no/incomplete, complete, complete XMI schema

Basic::Interactions

no/incomplete, complete, complete XMI schema

Basic::InternalStructures

no/incomplete, complete, complete XMI schema

Basic::UseCases

no/incomplete, complete, complete XMI schema

Common::Actions

no/incomplete, complete, complete XMI schema

Common::Activities

no/incomplete, complete, complete XMI schema

Common::Classes

no/incomplete, complete, complete XMI schema

Common::Collaborations

no/incomplete, complete, complete XMI schema

Common::
CommonBehaviors

no/incomplete, complete, complete XMI schema

Common::Components

no/incomplete, complete, complete XMI schema

Common::Deployments

no/incomplete, complete, complete XMI schema

Common::Ports

no/incomplete, complete, complete XMI schema

Common::StateMachines

no/incomplete, complete, complete XMI schema

Complete::Actions

no/incomplete, complete, complete XMI schema

Complete::Activities

no/incomplete, complete, complete XMI schema

Complete::Associations

no/incomplete, complete, complete XMI schema

Complete::
ComponentDeployments

no/incomplete, complete, complete XMI schema

Complete::
Generalizations

no/incomplete, complete, complete XMI schema

Complete::
InformationFlows

no/incomplete, complete, complete XMI schema

Complete::Models

no/incomplete, complete, complete XMI schema

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

xi

0.6 Changes to Adopted OMG Specifications

Table 0-1

Compliance Point

Valid Options

Complete::
ProtocolStateMachines

no/incomplete, complete, complete XMI schema

Complete::
Subsystems

no/incomplete, complete, complete XMI schema

Complete::
Templates

no/incomplete, complete, complete XMI schema

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.

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

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.

Preface.fm Version 2 beta R1

September 9, 2002 11:33 am

xiii

Preface.fm Version 2 beta R1

0.8 Acknowledgements

September 9, 2002 11:33 am

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

September 9, 2002 11:32 am

UML::Foundation

Part-Foundation.fm Version 2 beta R1

September 9, 2002 11:32 am

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 Foundation::Kernel

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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

1 Foundation::Kernel

DirectedRelationship

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.

DirectedRelationship
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
No additional constraints.
Semantics
DirectedRelationship has no specific semantics. The various subclasses of DirectedRelationship will add semantics
appropriate to the concept they represent.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

1 Foundation::Kernel

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
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

1 Foundation::Kernel

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
No additional attributes.
Associations

relatedElement: Element [1..*] Specifies the elements related by the Relationship.

Constraints
No additional 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
See The Namespaces diagram on page 8.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

1 Foundation::Kernel

Constraint

Constraints
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

1 Foundation::Kernel

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()

Additional Operations
[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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

10

1 Foundation::Kernel

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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

11

1 Foundation::Kernel

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
No additional constraints.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

12

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

13

1 Foundation::Kernel

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()

Additional Operations
[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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

14

1 Foundation::Kernel

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
No additional 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()

Additional Operations
[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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

15

1 Foundation::Kernel

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
No additional 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
association is a specialization of the ownedElement association from Element to
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


association is a specialization of the ownedElement association from Element to
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()))))

Additional Operations
[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;

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

16

1 Foundation::Kernel

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

Additional Operations
[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;

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

17

1 Foundation::Kernel

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-

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

18

1 Foundation::Kernel

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
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

19

1 Foundation::Kernel

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.
Presentation Options
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

20

1 Foundation::Kernel

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
No additional associations.
Constraints
[1] Evaluation of an expression yields zero or more values.
Cannot be expressed in OCL.

Additional Operations
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

21

1 Foundation::Kernel

LiteralBoolean

Expression::isIntegral(): Boolean;

[3] The query isPositive() tells whether an integer expression has a positive value.
Expression::isPositive(): Boolean;
pre: self.isIntegral()

[4] The query isNonNegative() tells whether an integer expression has a non-negative value.
Expression::isNonNegative(): Boolean;
pre: self.isIntegral()

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

22

1 Foundation::Kernel

LiteralInteger

Associations
No additional associations.
Constraints
No additional constraints.
Semantics
No additional 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
No additional associations.
Constraints
No additional constraints.
Semantics
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

23

1 Foundation::Kernel

LiteralSpecification

Attributes
No additional attributes.
Associations
No additional associations.
Constraints
No additional 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.

LiteralSpecification
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
No additional attributes.
Associations
No additional associations.
Constraints
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

24

1 Foundation::Kernel

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
No additional associations.
Constraints
No additional constraints.
Semantics
No additional semantics.
Notation
A LiteralString is typically shown as its string value, often as part of a more complex specification string for another
element.

Namespace
See The Namespaces diagram on page 8.

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
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

25

1 Foundation::Kernel

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.
Presentation Options
The multiplicity may also be shown as a multiplicity mark in the top right corner of the symbol representing the value
specification.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

26

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

27

1 Foundation::Kernel

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.
Cannot be expressed in OCL.

[6] If a non-literal ValueSpecification is used for the lower or upper bound, then that specification must be a constant
expression.
Cannot be expressed in OCL.

Additional Operations
[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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

28

1 Foundation::Kernel

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.
Presentation Options
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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

29

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

30

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

31

1 Foundation::Kernel

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)))

Additional Operations
[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;

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

32

1 Foundation::Kernel

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.
Presentation Options
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-

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

33

1 Foundation::Kernel

Generalization

ization of the association from Namespace to NamedElement where the end on


the NamedElement side is member.
Constraints
No additional 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
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

34

1 Foundation::Kernel

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.
Presentation Options
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

35

1 Foundation::Kernel

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))

Additional Operations
[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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

36

1 Foundation::Kernel

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
[parameter, ownedMember]
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
No additional attributes.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

37

1 Foundation::Kernel

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))

Additional Operations
[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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

38

1 Foundation::Kernel

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
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

39

1 Foundation::Kernel

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
No additional attributes.
Associations
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

40

1 Foundation::Kernel

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
No additional associations.
Constraints
No additional 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}.
Presentation Options
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
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

41

1 Foundation::Kernel

1.7 The Classes diagram

Constraints
No additional 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

[namespace, redefinitionContext]
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

42

1 Foundation::Kernel

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
No additional constraints.
Additional Operations
[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;
pre: redefinee.isRedefinitionContextValid(self)
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

43

1 Foundation::Kernel

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.
Semantic Variation Points
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.
Presentation Options
The type, visibility, default, multiplicity, property string may be suppressed from being displayed, even if there are
values in the model.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

44

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

45

1 Foundation::Kernel

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
No additional 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
No additional 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.
Presentation Options
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

46

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

47

1 Foundation::Kernel

Operation

Attributes
No additional 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.
The association is a specialization of the ownedMember association from
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.
The association is a specialization of the ownedMember association from
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
No additional constraints.
Additional Operations
[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;
pre: redefinee.isRedefinitionContextValid(self)
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

48

1 Foundation::Kernel

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.
Semantic Variation Points
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.

Presentation Options
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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

49

1 Foundation::Kernel

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
[feature, ownedMember]

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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

50

1 Foundation::Kernel

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.
Semantic Variation Points
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.
Presentation Options
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

51

1 Foundation::Kernel

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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

52

1 Foundation::Kernel

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).

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

53

1 Foundation::Kernel

Association

Generalizations between associations can be shown using a generalization arrow between the association symbols.
Presentation Options
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

54

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

55

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

56

1 Foundation::Kernel

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
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

57

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

58

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

59

1 Foundation::Kernel

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.
Presentation Options
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

60

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

61

1 Foundation::Kernel

1.1 The DataTypes diagram

1.1. The DataTypes diagram

Classifier

+ownedAtt ribute
[attribute, ownedMember]

0..1
DataTy pe

[ namespace, redefinit ionContext]

{ordered} *

[ namespace, redefinit ionContext]

{ordered} *

Attribute

Operation

+ownedOperation
[feature, ownedMember]

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
No additional attributes.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

62

1 Foundation::Kernel

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
No additional 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.
Semantic Variation Points
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.
Presentation Options
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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

63

1 Foundation::Kernel

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
No additional attributes.
Associations
No additional constraints.
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.
Presentation Options
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

64

1 Foundation::Kernel

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
No additional 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
No additional 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.
Presentation Options
An EnumerationValue may also be shown using instance notation with the addition of the <<literal>> keyword.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

65

1 Foundation::Kernel

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
No additional associations.
Constraints
No additional 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).

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

66

1 Foundation::Kernel

1.2 The Instances diagram

Examples
See Chapter 2, Foundation::PrimitiveTypes for examples.

1.2. The Instances diagram

AutonomousElement
Element

InstanceSpecification

+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.

InstanceSpecification
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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

67

1 Foundation::Kernel

InstanceSpecification

Attributes
No additional 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)

Additional Operations
[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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

68

1 Foundation::Kernel

InstanceSpecification

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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

69

1 Foundation::Kernel

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
No additional attributes.
Associations

instance: InstanceSpecification [1]The instance that is the specified value.

Constraints
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

70

1 Foundation::Kernel

Slot

Slot is implicitly a subclass of InfrastructureLibrary::Core::Abstractions::Instances::Slot.


Attributes
No additional 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
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

71

1 Foundation::Kernel

1.3 The Packages diagram

1.3. The Packages diagram

PackagingNamespace

Aut onomousElement

MemberImport

[elementImport]
+elementImport

Package
0..1

DirectedRelationship

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

72

1 Foundation::Kernel

Package

Attributes
No additional 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
association is a specialization of the ownedElement association from Element to
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)

Additional Operations
[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).

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

73

1 Foundation::Kernel

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).
Presentation Options
A tool may show visibility by a graphic marker, such as color or font. A tool may also show visibility by selectively
displaying those elements that meet a given visibility level, 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
No additional attributes.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

74

1 Foundation::Kernel

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
No additional 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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

75

1 Foundation::Kernel

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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

76

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

77

1 Foundation::Kernel

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.

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

78

1 Foundation::Kernel

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-

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

79

1 Foundation::Kernel

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.)

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

80

1 Foundation::Kernel

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.
self.visibility = #public or self.visibility = #private

Semantics
No additional 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.
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:
{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-

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

81

1 Foundation::Kernel

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

Foundation-Kernel.fm Version 2 beta R1 September 9, 2002 11:30 am

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

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

2-90

4.1. Class Descriptions


Pin
(from CommonBehaviors)

Action
(from CommonBehaviors)

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
(from CommonBehaviors)

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
(from CommonBehaviors)

*
{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)

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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()

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

2-94

Changes from UML 1.x


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

argument: InputPin [0..*]

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Semantic Variation Points
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.
Changes from UML 1.x
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
This metaclass did not exist in 1.x.

Parameter (extended)
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

2-98

Rationale
Not applicable.
Changes from UML 1.x
This metaclass did not exist in 1.x.

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.
Changes from UML 1.x
This metaclass did not exist in 1.x.

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

2-99

4 Basic::Actions

Procedure (extended)

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
No additional attributes.
Associations
No additional associations.
Constraints
No additional 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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

2-100

Changes from UML 1.x


This metaclass did not exist in 1.x.

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.

target: InputPin [1]

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.
[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. 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.
Changes from UML 1.x
This metaclass has been added.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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

argument: InputPin [0..*]

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.

target: InputPin [1]

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.
[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 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.
Changes from UML 1.x
Replaces the SendAction form UML 1.4, but provides essentially the same features as refined in the Action Semantics specification.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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
[parameter, ownedMember]

*
0..1

{ordered}

+returnResult
[ paramet er, ownedMember]

+nes tedBehavior
[ ownedMember]

BehavioralFeat ure
(from Kernel)

+parameter
[member]

0..1

*
0..1

0..1

[namespace, redefinitionContext]

{ordered}

ReturnResult
(from Kernel)
*

+ownedAttribute
[attribute, ownedMember]

[namespace, redefinitionContext]

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.

CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am

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

body : String [0..1]


language : String [0..1]

0..1

+result

1
+returnResult
[returnResult]

Element
(from Kernel)

ReturnResult
(from Kernel)

Figure 5-64. Procedure.

Element
(from Kernel)

Procedure
body : String [0..1]
language : String [0..1]

[ownedElement]
+action

Ac tion

0..1

Figure 5-65. Action.

[namespace, context]

+prec ondition
[ownedConstraint ]

[namespace, context]

+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

CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am

2-105

5 Basic::Common Behaviors

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
No additional 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
No additional constraints.
Semantics
Action is an abstract metaclass. See its concrete subtypes for the definition of its behavior.
Notation
None.
Examples
None.
Rationale
Not applicable.
Changes from UML 1.x
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.

CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am

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).

CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am

2-107

5 Basic::Common Behaviors

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.
Semantic Variation Points
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.
Changes from UML 1.x
This metaclass has been added. It abstracts the commonalities between the various ways that behavior can be implemented in the UML.

BehavioralFeature (extended)
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.
Changes from UML 1.x
The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.

CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am

2-108

BehaviorInvocation
Description
BehaviorInvocation is an abstract metaclass factoring out the common features of all behavior invocations.
Attributes
No additional 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
No additional 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
No additional notation.
Changes from UML 1.x
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
No additional 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.)

CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am

2-109

5 Basic::Common Behaviors

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.
Changes from UML 1.x
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.

language: String [0..1]

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.

Parameter (extended)
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.

CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am

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
No additional 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
No additional 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
No additional notation.
Changes from UML 1.x
This metaclass did not exist in 1.x.

CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am

2-111

5 Basic::Common Behaviors

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.

language: String [0..1]

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
No additional 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.
Changes from UML 1.x
In 1.4, the Procedure metaclass was subsumed by Expression.

CommonBehaviors.fm Version 2 alpha R4September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

113

6 Basic::Dependencies

6.1 Class Descriptions

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
No additional 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

Dependencies.fm Version 2 beta R1

September 9, 2002 11:32 am

114

6 Basic::Dependencies

Classifier (extended)

and bidirectional. The mapping expression is optional and may be omitted if the
precise relationship between the elements is not specified.
Constraints
No additional 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.

Classifier (extended)
Description

Associations

substitution : Substitution

(Specializes Element.ownedElement and NamedElement.clientDependency.)

Dependencies.fm Version 2 beta R1

September 9, 2002 11:32 am

115

6 Basic::Dependencies

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
No additional 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
No additional 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

Dependencies.fm Version 2 beta R1

September 9, 2002 11:32 am

116

6 Basic::Dependencies

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
No additional 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.

Dependencies.fm Version 2 beta R1

September 9, 2002 11:32 am

117

6 Basic::Dependencies

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
No additional attributes.
Associations
No additional associations.
Constraints
No additional 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.

Dependencies.fm Version 2 beta R1

September 9, 2002 11:32 am

118

6 Basic::Dependencies

Usage

Examples
None.
Rationale
Not applicable.
Changes from UML 1.x
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
No additional attributes.
Associations
No additional associations.
Constraints
No additional 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.
Changes from UML 1.x

Dependencies.fm Version 2 beta R1

September 9, 2002 11:32 am

119

6 Basic::Dependencies

Dependencies.fm Version 2 beta R1

Usage

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

121

7 Basic::Interfaces

7.1 Class Descriptions

7.1. Class Descriptions


Classifier
(from Dependencies)

* {ordered}

Attribute
(from Kernel)

Operation
(from Kernel)

[redefinitionContext]
Interface

+ownedAttribute
[feature, ownedMember]

0..1

0.. 1

{ordered} [redefinitionContext]

+ownedOperation
[feature, ownedMember]

* {ordered}

0..1

+nestedInterface [ownedMember]

+contract
[ supplier, target]

Class
(from Kernel)

[ownedElement, clientDependency]
+implementation
1
+implementatingClassifier
[client,source]

[namespace, redefinitionContext]

+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

Interfaces.fm Version 2 beta R1

September 9, 2002 11:32 am

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
No additional 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


Namespace.ownedMember and Classifier.feature.)

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).

Interfaces.fm Version 2 beta R1

September 9, 2002 11:32 am

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.

Interfaces.fm Version 2 beta R1

September 9, 2002 11:32 am

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
No additional attributes.

Interfaces.fm Version 2 beta R1

September 9, 2002 11:32 am

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.
Changes from UML 1.x
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.

Interfaces.fm Version 2 beta R1

September 9, 2002 11:32 am

126

7 Basic::Interfaces

Interfaces.fm Version 2 beta R1

Implementation

September 9, 2002 11:32 am

127

7 Basic::Interfaces

Interfaces.fm Version 2 beta R1

Implementation

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

129

8 Basic::Interactions

8.1 Class Descriptions

8.1. Class Descriptions

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

130

InteractionFragment
BehaviorInvocation

+coveredBy

(from CommonBehaviors)

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

131

8 Basic::Interactions

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
(from CommonBehaviors)

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

133

8 Basic::Interactions

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

135

8 Basic::Interactions

EventOccurrence

Examples

interactionOperator for Choice

Gate

operand separator

sd example

ob1:C1

ob3:C3

opti()

alt

ob4:C4

InteractionConstraint
[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.
Changes from UML 1.x
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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

137

8 Basic::Interactions

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).

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

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

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

139

8 Basic::Interactions

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

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.
Changes from UML 1.x
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.

InteractionConstraint
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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

141

8 Basic::Interactions

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

142

Rationale
Not applicable.
Changes from UML 1.x
This concept did not appear in UML 1.x.

InteractionOccurrence
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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

143

8 Basic::Interactions

InteractionOperand

Examples

sd UserAccess

InteractionOccurrence
User

ref

ACSystem

EstablishAccess("Illegal PIN")
Card Out()

opt

Msg("Please Enter")()

ref

Open Door

Figure 8-87. InteractionOccurrence.


Rationale
Not applicable.
Changes from UML 1.x
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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

145

8 Basic::Interactions

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.
Changes from UML 1.x
Lifelines are basically the same concept as before in UML 1.x.

Message
A Message defines a particular communication between Parts of an Interaction.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

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.
self.Metaclass1->forAll->(...)

[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>.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

147

8 Basic::Interactions

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.
Changes from UML 1.x
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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

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.
self.Metaclass1->forAll->(...)

[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

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

149

8 Basic::Interactions

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

Msg("Please Enter")()

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

150

Port
sd AC_UserAccess

AccessPoint
p1

ref

extra global
interaction group

Authorizer

Console

p2

AC_EstablishAccess("Illegal PIN")

Card Out()

opt

Msg("Please Enter")()

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.
Changes from UML 1.x
PartDecomposition did not appear in UML 1.x.

ProcedureOccurrence
A ProcedureOccurrence is an instantiation of a Procedure.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

151

8 Basic::Interactions

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

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.

Interactions.fm Version 2 beta R1

September 9, 2002 11:32 am

153

8 Basic::Interactions

Interactions.fm Version 2 beta R1

8.2 Semantic Model

September 9, 2002 11:32 am

154

9 Basic::InternalStructures

9.1 Class Descriptions

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

9.1. Class Descriptions

Classifier
(from Kernel)

StructuredClassifier

NamedElement
(from Dependencies)

+role
[feature]

ConnectableElement
*

0..1

+ownedPart
[role, ownedMember]

[ redefinitionContex t]

0.. 1

Part
*

+ownedConnector
[feature, ownedMember]

[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

September 9, 2002 11:32 am

155

9 Basic::InternalStructures

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
No additional attributes.
Associations

end : ConnectorEnd

Denotes a connector that attaches to this connectable element.

Constraints
No additional 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.
Changes from UML 1.x
This metaclass did not exist in 1.x.

InternalStructures.fm Version 2 beta R1

September 9, 2002 11:32 am

156

9 Basic::InternalStructures

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.

InternalStructures.fm Version 2 beta R1

September 9, 2002 11:32 am

157

9 Basic::InternalStructures

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.

InternalStructures.fm Version 2 beta R1

September 9, 2002 11:32 am

158

9 Basic::InternalStructures

ConnectorEnd

Changes from UML 1.x


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
No additional 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
No additional 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.
Changes from UML 1.x
Connector end has been added in UML 2.0. The UML 1.4 concept of association end roles is subsumed by connector
ends.

InternalStructures.fm Version 2 beta R1

September 9, 2002 11:32 am

159

9 Basic::InternalStructures

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).

InternalStructures.fm Version 2 beta R1

September 9, 2002 11:32 am

160

9 Basic::InternalStructures

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.

Changes from UML 1.x


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
No additional 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
No additional 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 ] ]

InternalStructures.fm Version 2 beta R1

September 9, 2002 11:32 am

161

9 Basic::InternalStructures

StructuredClassifier

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.
Presentation Options
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.
Changes from UML 1.x
Part has been added in UML 2.0.

StructuredClassifier
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
No additional 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
No additional 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.

InternalStructures.fm Version 2 beta R1

September 9, 2002 11:32 am

162

9 Basic::InternalStructures

StructuredClassifier

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

InternalStructures.fm Version 2 beta R1

September 9, 2002 11:32 am

163

9 Basic::InternalStructures

StructuredClassifier

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.

InternalStructures.fm Version 2 beta R1

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

10-165

10 Basic::UseCases

10.1 Class Descriptions

10.1. Class Descriptions


Classifier
(from Kernel)

+subject

*
BehavioredClassifier

Feature

Classifier

(from CommonBehavior)

(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
No additional attributes.
Associations
No additional associations.

UseCases.fm Version 0.69

September 9, 2002 11:32 am

10-166

10 Basic::UseCases

Classifier (extended)

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.)
Presentation Options
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.
Changes from UML 1.x
There are no changes to the Actor concept except for the addition of a constraint that requires that all actors must have
names.

Classifier (extended)
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.)

UseCases.fm Version 0.69

September 9, 2002 11:32 am

10-167

10 Basic::UseCases

Extend

Constraints
No additional 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.
Changes from UML 1.x
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.

UseCases.fm Version 0.69

September 9, 2002 11:32 am

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.
Semantic Variation Points
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).
Changes from UML 1.x
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.

UseCases.fm Version 0.69

September 9, 2002 11:32 am

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
No additional attributes.
Associations
No additional 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.
Semantic Variation Points
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).
Changes from UML 1.x
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

UseCases.fm Version 0.69

September 9, 2002 11:32 am

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
No additional 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
No additional 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.
Semantic Variation Points
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.)

UseCases.fm Version 0.69

September 9, 2002 11:32 am

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.
Changes from UML 1.x
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.

UseCases.fm Version 0.69

September 9, 2002 11:32 am

10-172

10 Basic::UseCases

UseCase

Attributes
No additional 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.

UseCases.fm Version 0.69

September 9, 2002 11:32 am

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.

UseCases.fm Version 0.69

September 9, 2002 11:32 am

10-174

10 Basic::UseCases

UseCase

Transaction Use Cases


condition: {customer selected HELP}
extension point: Selection
<<extend>>

Card Identification

On-Line Help

Perform ATM Transaction

<<include>>

<<include>>

<<import>>
ATM Services

W ithdrawl

Deposit Funds

Transfer Funds

Administration

Read Log

Register ATM at Bank

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.

UseCases.fm Version 0.69

September 9, 2002 11:32 am

10-175

10 Basic::UseCases

UseCase

Presentation Options
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.
Changes from UML 1.x

There was no explicit metamodel relationship between use cases and their corresponding subject in UML 1.x.

UseCases.fm Version 0.69

September 9, 2002 11:32 am

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

September 9, 2002 11:33 am

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.

Part-Common.fm Version 2 beta R1

September 9, 2002 11:33 am

178

Part-Common.fm Version 2 beta R1

September 9, 2002 11:33 am

179

10 UML::Common

Part-Common.fm Version 2 beta R1

September 9, 2002 11:33 am

180

Part-Common.fm Version 2 beta R1

September 9, 2002 11:33 am

181

10 UML::Common

Part-Common.fm Version 2 beta R1

September 9, 2002 11:33 am

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-184

11.1. Class Descriptions


+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
(from Action Foundation)

Figure 11-3. common object actions

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-185

11 Common::Actions

11.1 Class Descriptions

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-187

11 Common::Actions

11.1 Class Descriptions

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
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]

Actions.fm Version 2 alpha R4

(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.

September 9, 2002 11:32 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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

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 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.
let insertAtPins : Collection = self.insertAt in
if self.variable.ordering = #unordered
then insertAtPins->size() = 0
else let insertAtPin : InputPin = insertAts->asSequence()->first() in
insertAtPins->size() = 1
and insertAtPin.type = ValueSpecification
and insertAtPin.multiplicity.is(1,1))
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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)

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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.
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
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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

argument: InputPin [0..*]

Actions.fm Version 2 alpha R4

A list of values that are the arguments to be passed to the invoked behavior. (Specializes BehaviorInvocation.argument and Action.input.)

September 9, 2002 11:32 am

1-196

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).

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.
Semantic Variation Points
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.
Changes from UML 1.x
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

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
These metaclasses did not exist in 1.x.

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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]

object : InputPin [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.


self.object.multiplicity.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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-200

Changes from previous UML


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.
Changes from previous UML
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-

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
These metaclasses did not exist in 1.x.

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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-

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
These metaclasses did not exist in 1.x.

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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
[1] The multiplicity of the input pin is 1..1.
self.input.multiplicity.is(1,1)

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
These metaclasses did not exist in 1.x.

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
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]

Actions.fm Version 2 alpha R4

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.

September 9, 2002 11:32 am

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.
Changes from UML 1.x
This metaclasses did not exist in UML 1.4.

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]

Actions.fm Version 2 alpha R4

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.

September 9, 2002 11:32 am

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.
Changes from UML 1.x
This metaclasses did not exist in UML 1.4.

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..*]

Actions.fm Version 2 alpha R4

(Specialized from Action:input) Pins taking end objects and qualifier values as
input.

September 9, 2002 11:32 am

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.
Changes from previous UML
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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

insertAt : InputPin [0..1]

Specifies where the new link should be inserted for ordered association ends, or
where an existing link should be moved to. The type of the input is UnlimitedInteger. This pin is omitted for association ends that are not ordered.

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..
let insertAtPins : Collection = self.insertAt in
if self.end.ordering = #unordered
then insertAtPins->size() = 0
else let insertAtPin : InputPin = insertAts->asSequence()->first() in
insertAtPins->size() = 1
and insertAtPin.type = ValueSpecification
and insertAtPin.multiplicity.is(1,1))
endif

Semantics
See CreateLinkAction.
Notation
None.
Examples
None.
Rationale
LinkEndCreationData is introduced to indicate which inputs are for which link end objects and qualifiers.
Changes from previous UML
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
These metaclasses did not exist in 1.x.

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

Actions.fm Version 2 alpha R4

A textual representation of the function in the named surface language.

September 9, 2002 11:32 am

1-218

language: String [0..1]

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.
Changes from previous UML
This metaclass was not present in 1.x.

Procedure (extended)
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

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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]

(Specialized from Action:output) Gives the output pin on which the result is put.

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-220

Changes from previous UML


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.
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in
openend.multiplicity.compatibleWith(self.result.multiplicity)

[4] The open end must be navigable.


let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in
openend.isNavigable = #true

[5] Visibility of the open end must allow access to the object performing the action.
let host : Classifier = self.procedure().hostClassifier() in
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)->asSequence()->first().end in
openend.visibility = #public
or self.endData->exists(oed | not oed.end = openend
and (host = oed.end.participant
or (openend.visibility = #protected
and host.allSupertypes->includes(oed.end.participant))))

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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

result : OutputPin [1..1]

(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()

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-222

[4] The multiplicity of the result output pin is 1..1.


self.result.multiplicity.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.
Changes from previous UML
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

result: OutputPin [1..1]

(Specialized from Action:output) Gives the output pin on which the result is put.

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-223

11 Common::Actions

RemoveAttributeValueAction

Notation
None.
Examples
None.
Rationale
ReadVariableAction is introduced to retrieve the values of a variables.
Changes from previous UML
ReadVariableAction is new in UML 2.0.

RemoveAttributeValueAction
RemoveAttributeValueAction is a write variable attribute action that removes values from attributes.
Description
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
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-224

Changes from previous UML


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.
Changes from previous UML
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

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.

result: OutputPin [1..1]

(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.
Changes from previous UML
TestIdentityAction is new in UML 2.0.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from UML 1.x
These metaclasses did not exist in 1.x.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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.
Changes from previous UML
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

value : InputPin [1..1]

(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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-228

self.value.type = self.attribute.featuringClassifier

[2] The multiplicity of the input pin is 1..1.


self.value.multiplicity.is(1,1)

Semantics
None.
Notation
None.
Examples
None.
Rationale
WriteAttributeAction is introduced to abstract aspects of attribute actions that change attribute values.
Changes from previous UML
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

1-229

11 Common::Actions

WriteVariableAction

Rationale
WriteLinkAction is introduced to navigate across links.
Changes from previous UML
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

value : InputPin [1..1]

(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

[2] The multiplicity of the input pin is 1..1.


self.value.multiplicity.is(1,1)

Semantics
See children of WriteVariableAction.
Notation
None.
Examples
None.
Rationale
WriteVariableAction is introduced to abstract aspects of attribute actions that change variable values.
Changes from previous UML
WriteVariableAction is new in UML 2.0.

Actions.fm Version 2 alpha R4

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

231

12 Common::Activities

12.1 Class Descriptions

12.1. Class Descriptions

Behavior

<<enumerat ion >>


Act ivityK ind

(from CommonBehavior)

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

232

12 Common::Activities

12.1 Class Descriptions

TypedElement
(from Kernel)

TypedElement
isSet : Boolean [1] = false

ObjectNode

BehaviorI nvocat ion

Pin

(from CommonBehavi or)

(from CommonBehavior)

(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

(from CommonBehavior)

Figure 12-5. Controls

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

233

12 Common::Activities

12.1 Class Descriptions

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

234

12 Common::Activities

12.1 Class Descriptions

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

235

12 Common::Activities

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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

236

12 Common::Activities

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

237

12 Common::Activities

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

238

12 Common::Activities

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.
Semantic Variation Points
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-

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

239

12 Common::Activities

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

240

12 Common::Activities

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-

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

241

12 Common::Activities

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

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

242

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

243

12 Common::Activities

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.
Semantic Variation Points
See variations at children of ActivityEdge and ActivityNode.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

244

12 Common::Activities

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

245

12 Common::Activities

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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

246

12 Common::Activities

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.
Changes from previous UML
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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

247

12 Common::Activities

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.
Semantic Variation Points
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-

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

248

12 Common::Activities

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.
Changes from previous UML
ActivityFinal is new in UML 2.0.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

249

12 Common::Activities

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.
Semantic Variation Points
None.
Notation
See children of ActivityGroup.
Presentation Option
Style Guidelines
Examples
See children of ActivityGroup.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

250

12 Common::Activities

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.
Changes from previous UML
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.
Semantic Variation Points
None.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

251

12 Common::Activities

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.
Changes from previous UML
ActivityNode replaces the use of StateVertex and its children for activity modeling in UML 1.4.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

252

12 Common::Activities

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.
Semantic Variation Points
None.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

253

12 Common::Activities

ActivityParameter

Notation
Also see notation at Activity.

Activity name
Parameter name: type
...
...

...

Figure 12-30. Activity notation.


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.
Changes from previous UML
ActivityParameter is new in UML 2.0.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

254

12 Common::Activities

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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

255

12 Common::Activities

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.
Semantic Variation Points
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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

256

12 Common::Activities

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,

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

257

12 Common::Activities

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

258

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

259

12 Common::Activities

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).
Semantic Variation Points
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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

260

12 Common::Activities

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.
Semantic Variation Points
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

261

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

262

12 Common::Activities

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.
Semantic Variation Points
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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

263

12 Common::Activities

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.
Semantic Variation Points
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

264

12 Common::Activities

ControlNode

Changes from previous UML


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.
Semantic Variation Points
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

265

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

266

12 Common::Activities

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.
Semantic Variation Points
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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

267

12 Common::Activities

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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

268

12 Common::Activities

FinalNode

Changes from previous UML


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.
Semantic Variation Points
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

269

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

270

12 Common::Activities

FlowFinal

Tagged Values
None.
Constraints
None.
Semantics
Flow final destroys tokens flowing into it.
Semantic Variation Points
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.
Changes from previous UML
Flow final is new in UML 2.0.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

271

12 Common::Activities

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.
Semantic Variation Points
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


together, sharing the same symbol

Figure 12-50. Fork node notation.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

272

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

273

12 Common::Activities

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.
Semantic Variation Points
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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

274

12 Common::Activities

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.
Semantic Variation Points
See variations in ActivityEdge and ObjectNode.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

275

12 Common::Activities

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
Parameter name: type
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

276

12 Common::Activities

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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

277

12 Common::Activities

IterationActivityGroup

from many activities, without burdening the content-independent behavior with the flows associated with its invocation in a particular activity.
Changes from previous UML
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.

IterationActivityGroup
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.
Semantic Variation Points
None.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

278

12 Common::Activities

IterationActivityGroupKind

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.
Changes from previous UML
Iteration groups are new in UML 2.0.

IterationActivityGroupKind
The datatype IterationActivityGroupKind is an enumeration with possible values testAtBegin and testAtEnd.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

279

12 Common::Activities

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.
Semantic Variation Points
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-

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

280

12 Common::Activities

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


together, sharing the same symbol

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

281

12 Common::Activities

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.
Semantic Variation Points
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


together, sharing the same symbol

Figure 12-65. Merge node notation.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

282

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

283

12 Common::Activities

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.
Semantic Variation Points
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

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

284

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

285

12 Common::Activities

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.
Semantic Variation Points
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

286

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

287

12 Common::Activities

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.
Semantic Variation Points
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

288

12 Common::Activities

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.

Output parameter usage node,


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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

289

12 Common::Activities

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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

290

12 Common::Activities

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.
Semantic Variation Points
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

291

12 Common::Activities

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.
Changes from previous UML
SignalNode replaces the control icons for sending and receiving signals in UML 1.x.

StructuredActivityGroup
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

292

12 Common::Activities

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.
Semantic Variation Points
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.
Changes from previous UML
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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

293

12 Common::Activities

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.
Semantic Variation Points
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.
Changes from previous UML
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 (in Activities)


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.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

294

12 Common::Activities

TypedElement (in Activities)

Tagged Values
None.
Constraints
None.
Semantics
The values of the typed element must be sets of its type. See ObjectNode and its children.
Semantic Variation Points

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.
Changes from previous UML
TypeElement (in Activities) is new in UML 2.0.

Activities.fm Version 2 beta R1

September 9, 2002 11:32 am

295

12 Common::Activities

Activities.fm Version 2 beta R1

TypedElement (in Activities)

September 9, 2002 11:32 am

296

13 Common::Classes

13.1 Class Descriptions

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.

13.1. Class Descriptions


Port
(from Ports)

+ownedPort

EncapsulatedClassifier
(from Ports)

Class
(from CommonBehaviors)

+ 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

September 9, 2002 11:32 am

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
No additional 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

Classes.fm Version 2 beta R1

September 9, 2002 11:32 am

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.
Changes from UML 1.x
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.

Classes.fm Version 2 beta R1

September 9, 2002 11:32 am

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.

Classes.fm Version 2 beta R1

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

301

14 Common::Collaborations

14.1 Class Descriptions

14.1. Class Descriptions

ConnectableElement
(from InternalStructu...

StructuredClassifier
(from InternalSt ructu...

*
+collaborationRole
[role]

*
Collaboration

Attribute

Parameter

Parameter
(from CommonBehavior)
)

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

CollaborationOccurrence

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.

Collaborations.fm Version 2 beta R1

September 9, 2002 11:32 am

302

14 Common::Collaborations

Operation (extended)

Constraints
[1] An attribute may only be associated with a connector end within the context of a collaboration.

Operation (extended)
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.
Changes from UML 1.x
Behavior.representation was shown as collaboration (Collaboration.representedOperation) in 1.x.

Classifier (extended)
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.)

Collaborations.fm Version 2 beta R1

September 9, 2002 11:32 am

303

14 Common::Collaborations

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
See CollaborationOccurrence.
Changes from UML 1.x
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
No additional 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.

Collaborations.fm Version 2 beta R1

September 9, 2002 11:32 am

304

14 Common::Collaborations

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.

Collaborations.fm Version 2 beta R1

September 9, 2002 11:32 am

305

14 Common::Collaborations

CollaborationOccurrence

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.
Changes from UML 1.x
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.

CollaborationOccurrence
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
No additional 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.

Collaborations.fm Version 2 beta R1

September 9, 2002 11:32 am

306

14 Common::Collaborations

roleBinding: RoleBinding

CollaborationOccurrence

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

Collaborations.fm Version 2 beta R1

September 9, 2002 11:32 am

307

14 Common::Collaborations

CollaborationOccurrence

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.
Changes from UML 1.x
This metaclass has been added.

Collaborations.fm Version 2 beta R1

September 9, 2002 11:32 am

308

14 Common::Collaborations

Parameter (extended)

Parameter (extended)
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
No additional 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
See CollaborationOccurrence.
Semantics
See CollaborationOccurrence.
Notation
See CollaborationOccurrence.
Rationale
Not applicable.
Changes from UML 1.x
This metaclass has been added.

Collaborations.fm Version 2 beta R1

September 9, 2002 11:32 am

309

14 Common::Collaborations

14.2 Diagrams

14.2. Diagrams
Diagrams for collaborations are described in Chapter 37, Internal Structure Diagrams.

Collaborations.fm Version 2 beta R1

September 9, 2002 11:32 am

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 Common::CommonBehaviors

15.1 Class Description

15.1. Class Description


BehavioralFeature
(from CommonBehaviors)

Classifier
(from Kernel)

+feature

Signal

+raisedException
[ raisedException]

BehavioralFeature
concurrency : CallConcurrencyKind

0..1
[namespace, redefinitionContext]

{ordered} *

<<enumeration>>
CallConcurrencyKind
sequential
guarded
concurrent

+ownedAttribute
[attribute, ownedMember]

Attribute
(from Kernel)

Figure 15-2. Extensions to behavioral features and signal.

BehavioralFeature
concurrency : CallCo...` rencyK ind

BehavioredClassifier
(from CommonBehaviors)

*
Signal

0..1
+signal

+reception

Reception

0..1

+ownedReception
[feature, ownedMember]

Class
(from Kernel)

Class
isActive : Boolean

*
0..1
*
+ownedReception
[feature, ownedMember]

Interface

Interface
(from Interfaces)

Figure 15-3. Reception.

CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am

312

15 Common::CommonBehaviors

BehavioralFeature (extended)

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

BehavioralFeature (extended)
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.
Changes from UML 1.x
See BehavioralFeature (extended) in the Chapter 5, Basic::Common Behaviors package.

CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am

313

15 Common::CommonBehaviors

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.
Changes from UML 1.x
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.

CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am

314

15 Common::CommonBehaviors

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.
Semantic Variation Points
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.
Changes from UML 1.x
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.

CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am

315

15 Common::CommonBehaviors

Class (extended)

Semantics
When the value of the change expression becomes true, a change event occurs.
Notation
None.
Rationale
Not applicable.
Changes from UML 1.x
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


Namespace.ownedMember and Classifier.feature.)

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.

CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am

316

15 Common::CommonBehaviors

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).
Semantic Variation Points
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.
Changes from UML 1.x
Parameters of events have been changed to value specifications. These are available for all kinds of events.

Interface (extended)
Associations

ownedReception : Reception

Receptions that objects providing this interface are willing to accept. (Specializes
Namespace.ownedMember and Classifier.feature.)

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.

CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am

317

15 Common::CommonBehaviors

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.
Changes from UML 1.x
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

CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am

318

15 Common::CommonBehaviors

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.
Changes from UML 1.x
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.
Semantic Variation Points
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.
Changes from UML 1.x
None.

CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am

319

15 Common::CommonBehaviors

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.
Semantic Variation Points
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.
Changes from UML 1.x
None.

CommonBehaviors.fm Version 2 beta R1 September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

321

16 Common::Components

16.1 Class Descriptions

16.1. Class Descriptions


EncapsulatedClassifier
(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

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

322

16 Common::Components

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).

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

323

16 Common::Components

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.

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

324

16 Common::Components

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).

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

325

16 Common::Components

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.

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

326

16 Common::Components

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.

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

327

16 Common::Components

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.

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

328

16 Common::Components

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.

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

329

16 Common::Components

ComponentImport

Changes from previous UML


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
No additional 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.
self.visibility = #public or self.visibility = #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
No additional 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.
Changes from previous UML
This metaclass was added in UML 2.0.

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

330

16 Common::Components

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.

Components.fm Version 2 beta R1

September 9, 2002 11:32 am

331

16 Common::Components

Components.fm Version 2 beta R1

16.2 Diagrams

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

333

17 Common::Deployments

17.1 Class Descriptions

17.1. Class Descriptions

StructuredCl assifier
(from InternalStructure)

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

StructuredClassifier
(from InternalStructure)

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.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

334

17 Common::Deployments

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
No additional 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.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

335

17 Common::Deployments

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.

Changes from previous UML


The following changes from UML 1.x have been made: Artifacts have been extended to link to deployment specifications.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

336

17 Common::Deployments

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
No additional 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
No additional constraints.
Semantics
No additional semantics.
Notation
No additional notation.
Changes from previous UML
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
No additional attributes.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

337

17 Common::Deployments

CommunicationPath

Associations
No additional associations.
Constraints
No additional constraints.
Semantics
No additional semantics.
Notation
No additional notation.
Changes from previous UML
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
No additional attributes.
Associations
No additional associations.
Constraints

The types of the AssociationEnds of a CommunicationPath are typed by Nodes.

Semantics
No additional semantics.
Notation
No additional notation.
Changes from previous UML
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.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

338

17 Common::Deployments

Deployment

Description
In the metamodel, Deployment is a subtype of Relationship.
Attribute
No additional attributes.
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
No additional 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).

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

339

17 Common::Deployments

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.

Changes from previous UML


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
No additional attributes.
Associations
No additional associations.
Constraints
No additional 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.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

340

17 Common::Deployments

ExecutionEnvironment

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.

Changes from previous UML


The following changes from UML 1.x have been made: Device is not defined in UML 1.4.

ExecutionEnvironment
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
No additional attributes.
Associations
No additional associations.
Constraints
No additional constraints.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

341

17 Common::Deployments

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).

Changes from previous UML


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
No additional attributes.
Associations
No additional associations.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

342

17 Common::Deployments

Node

Constraints

The parts of a Network are typed by Nodes.

The connectors of a Network are typed by CommunicationPaths.

Semantics
No additional semantics.
Notation
No additional notation.
Changes from previous UML
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
No additional attributes.
Associations

nestedNode : Node [*]

The Nodes that are defined (nested) within the Node.


The association is a specialization of the ownedMember association from
Namespace to NamedElement.

deployment : Deployment [*] The set of Deployments defined for this Node.
The association is a specialization of the ownedMember association from
Namespace to NamedElement.

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
No additional 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.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

343

17 Common::Deployments

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.

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

344

17 Common::Deployments

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
Changes from previous UML
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

Deployments.fm Version 2 beta R1

September 9, 2002 11:32 am

345

17 Common::Deployments

Deployments.fm Version 2 beta R1

17.2 Diagrams

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

347

18 Common::Ports

18.1 Class Descriptions

18.1. Class Descriptions


ConnectableElement
(f rom InternalStruct ures)

StructuredClassifier
(from InternalStructures)

EncapsulatedClass if ier

0..1

+ownedPort
[feature, ownedMember]

[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-

Ports.fm Version 2 beta R1

September 9, 2002 11:32 am

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.
Changes from previous UML
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
No additional 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.

Ports.fm Version 2 beta R1

September 9, 2002 11:32 am

349

18 Common::Ports

EncapsulatedClassifier

Changes from UML 1.x


Connector end has been added in UML 2.0. The UML 1.4 concept of association end roles is subsumed by connector
ends.

EncapsulatedClassifier
Description
Extends a classifier with the ability to own ports as specific and type checked interaction points.
Attributes
No additional attributes.
Associations

ownedPort: Port

References a set of ports that an encapsulated classifier may own. (Specializes


Classifier.feature and Namespace.ownedMember.)

Constraints
No additional constraints.
Semantics
See Port.
Notation
No additional notation.
Changes from UML 1.x
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).

Ports.fm Version 2 beta R1

September 9, 2002 11:32 am

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.)

Ports.fm Version 2 beta R1

September 9, 2002 11:32 am

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.
Semantic Variation Points
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.

Ports.fm Version 2 beta R1

September 9, 2002 11:32 am

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.
Changes from UML 1.x
This metaclass has been added to UML.

Ports.fm Version 2 beta R1

September 9, 2002 11:32 am

353

18 Common::Ports

Ports.fm Version 2 beta R1

Port

September 9, 2002 11:32 am

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

September 9, 2002 11:32 am

355

19 Common::StateMachines

19.1 Class Descriptions

19.1. Class Descriptions

<<enumeration>>
PseudostateKind
initial
deepHistory
shallowHistory
join
fork
junction
choice
entryPoint
stop

Behavior
(from CommonBehaviors)

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]

(from CommonBehaviors)

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

356

19 Common::StateMachines

ConnectionPoint

BehavioredClassifier
(from CommonBehaviors)

[redefinitionContext]

0..1
RedefinableElement
(fromKernel)

[redefinitionContext]
+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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

357

19 Common::StateMachines

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

358

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

359

19 Common::StateMachines

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

360

19 Common::StateMachines

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

361

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

362

19 Common::StateMachines

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


Presentation Options
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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

363

19 Common::StateMachines

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


Changes from previous UML

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

364

19 Common::StateMachines

deepHistory

shallowHistory

join

fork

junction

choice

entry point

Region

Changes from previous UML


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


self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->
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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

365

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

366

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

367

19 Common::StateMachines

State

Constraints
[1] A composite state can have at most one initial vertex
self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->
select(p : Pseudostate | p.kind = #initial)->size <= 1

[2] A composite state can have at most one deep history vertex
self.subvertex->select (v | v.oclIsKindOf(Pseudostate))->
select(p : Pseudostate | p.kind = #deepHistory)->size <= 1

[3] A composite state can have at most one shallow history vertex
self.subvertex->select(v | v.oclIsKindOf(Pseudostate))->
select(p : Pseudostate | p.kind = #shallowHistory)->size <= 1

[4] There have to be at least two 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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

368

19 Common::StateMachines

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

369

19 Common::StateMachines

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

370

19 Common::StateMachines

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:

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

371

19 Common::StateMachines

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

372

19 Common::StateMachines

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).

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

373

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

374

19 Common::StateMachines

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

375

19 Common::StateMachines

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.
Additional Operations
[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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

376

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

377

19 Common::StateMachines

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

378

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

379

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

380

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

381

19 Common::StateMachines

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.
Changes from previous UML

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.
Changes from previous UML
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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

382

19 Common::StateMachines

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)

and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies


((self.source.oclAsType(Pseudostate).kind = #fork) implies
((self.guard->isEmpty) and (self.trigger->isEmpty)))

[2] A join segment should not have guards or triggers.


self.target.oclIsKindOf(Pseudostate) implies
((self.target.oclAsType(Pseudostate).kind = #join) implies
((self.guard->isEmpty) and (self.trigger->isEmpty)))

[3] A fork segment should always target a state.


(self.stateMachine->notEmpty

and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies


self.source.oclIsKindOf(Pseudostate) implies
((self.source.oclAsType(Pseudostate).kind = #fork) implies
(self.target.oclIsKindOf(State)))

[4] A join segment should always originate from a state.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

383

19 Common::StateMachines

Transition

(self.stateMachine->notEmpty

and not oclIsKindOf(self.stateMachine, ActivityGraph)) implies


self.target.oclIsKindOf(Pseudostate) implies
((self.target.oclAsType(Pseudostate).kind = #join) implies
(self.source.oclIsKindOf(State)))

[5] Transitions outgoing pseudostates may not have a trigger.


self.source.oclIsKindOf(Pseudostate)
implies (self.trigger->isEmpty))

[6] An initial transition at the topmost level (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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

384

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

385

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

386

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

387

19 Common::StateMachines

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.

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

388

19 Common::StateMachines

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.
Changes from previous UML

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

StateMachines.fm Version 2 beta R1

September 9, 2002 11:32 am

389

19 Common::StateMachines

StateMachines.fm Version 2 beta R1

Transition

September 9, 2002 11:32 am

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

September 9, 2002 11:33 am

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

Part-Complete.fm Version 2 beta R1

September 9, 2002 11:33 am

392

Part-Complete.fm Version 2 beta R1

September 9, 2002 11:33 am

393

19 UML::Complete

Part-Complete.fm Version 2 beta R1

September 9, 2002 11:33 am

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-396

20.1. Class Descriptions

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-397

20 Complete::Actions

20.1 Class Descriptions

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-399

20 Complete::Actions

20.1 Class Descriptions

+subaction
[ownedElement]

Action
(from Acti ons)

CollectionAct ion

MapAction

FilterAction

It erat eAction

ReduceActi on

isUnordered : Boolean

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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
isUnordered : Boolean

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
(from Action Foundation)

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
isUnordered : Boolean

+rightSubinput
[ownedElement]

{ordered}
{ordered}
1..*
1.. *
+result [output]
OutputPin
{ordered} 1 .. *

+suboutput
{ordered}

1..*

pin of the
subaction

Figure 20-45. Reduce action

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-401

20 Complete::Actions

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.
Changes from UML 1.x
This metaclasses did not exist in UML 1.4. They were added in the Action Semantics specification.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-403

20 Complete::Actions

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()

[3] The multiplicity of the output pin is 1..1.


self.result.multiplicity.is(1,1)

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.
Changes from previous UML
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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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

argument: InputPin [1..*]

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.

result: OutputPin [1..*]

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-405

20 Complete::Actions

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.
Changes from UML 1.x
This metaclasses did not exist in UML 1.4. They were added in the Action Semantics specification.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-407

20 Complete::Actions

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.

result: OutputPin [0..*]


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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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.

subaction: Action[1..1]

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-409

20 Complete::Actions

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.
Changes from UML 1.x
This metaclasses did not exist in UML 1.4. They were added in the Action Semantics specification.

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-410

Semantics
Notation
Examples
None.
Rationale
LinkAction is extended for qualifiers.
Changes from previous UML

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
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.
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
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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-411

20 Complete::Actions

LoopAction (extended)

Changes from previous UML

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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

argument: InputPin [1..*]

Actions.fm Version 2 alpha R4

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.

September 9, 2002 11:31 am

3-413

20 Complete::Actions

MapAction

result: OutputPin [0..*]

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.

subaction: Action[1..1]

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.

suboutput: OutputPin[0..*]

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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.
Changes from UML 1.x
This metaclasses did not exist in UML 1.4. They were added in the Action Semantics specification.

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
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 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.

value : InputPin [1..1]

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.


self.value.multiplicity.is(1,1)

Semantics
See LinkAction and its children.
Notation
None.
Examples
None.
Rationale
QualifierValue is introduced to indicate which inputs are for which link end qualifiers.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-415

20 Complete::Actions

ReadLinkObjectEndAction

Changes from previous UML


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.

object : InputPin [1..1]

(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.


self.object.multiplicity.is(1,1)

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

[6] The multiplicity of the result output pin is 1..1.


self.result.multiplicity.is(1,1)

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

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-416

Changes from previous UML


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.

object : InputPin [1..1]

(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.


self.object.multiplicity.is(1,1)

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

[7] The multiplicity of the result output pin is 1..1.


self.result.multiplicity.is(1,1)

Semantics
This action assumes qualifier attributes have multiplicity 1..1.
Notation
None.
Examples
None.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-417

20 Complete::Actions

ReadExtentAction

Rationale
ReadLinkObjectQualifierAction is introduced to navigate from a link object to its end objects.
Changes from previous UML
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.

result : OutputPin [1..1]

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.
Changes from previous UML
ReadExtentAction has been newly introduced in UML 2.0.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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.

input : InputPin [1..1]

Holds the object whose classification is to be tested. (Specializes Action.input.)

result : OutputPin [1..1]

After termination of the action, will hold the result of the test. (Specializes
Action.output.)

Constraints
[1] The multiplicity of the input pin is 1..1.
self.input.multiplicity.is(1,1)

[2] The input pin has no type.


self.input.type->size() = 0

[3] The multiplicity of the output pin is 1..1.


self.result.multiplicity.is(1,1)

[4] The type of the output pin is Boolean


self.result.type = Boolean

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.
Changes from previous UML
ReadisClassifiedObjectAction has been newly introduced in UML 2.0.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-419

20 Complete::Actions

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

input : InputPin [1..1]

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)

[2] The multiplicity of the input pin is 1..1.


self.input.multiplicity.is(1,1)

[3] The input pin has no type.


self.input.type->size() = 0

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-420

Changes from previous UML


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

Actions.fm Version 2 alpha R4

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.

September 9, 2002 11:31 am

3-421

20 Complete::Actions

ReduceAction

Associations

argument: InputPin [1..*]

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.

suboutput: OutputPin[1..*]

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

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.
Changes from UML 1.x
This metaclasses did not exist in UML 1.4. They were added in the Action Semantics specification.

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.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-423

20 Complete::Actions

StartObjectStateMachineAction

Associations

input : InputPin [1..1]

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.
Changes from previous UML
StartObjectStateMachineAction has been newly introduced in UML 2.0.

Actions.fm Version 2 alpha R4

September 9, 2002 11:31 am

3-424

21 Complete::Activities

21.1 Class Descriptions

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

21.1. Class Descriptions

InvocationNode
(from Activities)

InvocationNode
isSynchronous : Boolean = true
isMultipleInvocat ion : Boolean = false

0.. 1
+multiplicity

Multiplicity
(f rom Ke rne l)

Figure 21-47. Decompositions

Activities.fm Version 2 beta R1

September 9, 2002 11:31 am

425

21 Complete::Activities

21.1 Class Descriptions

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

Activities.fm Version 2 beta R1

September 9, 2002 11:31 am

426

21 Complete::Activities

21.1 Class Descriptions

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

Activities.fm Version 2 beta R1

September 9, 2002 11:31 am

427

21 Complete::Activities

21.1 Class Descriptions

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

Activities.fm Version 2 beta R1

September 9, 2002 11:31 am

428

21 Complete::Activities

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.

Activities.fm Version 2 beta R1

September 9, 2002 11:31 am

429

21 Complete::Activities

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.
Semantic Variation Points
None.
Notation
See intermediate notation.
Presentation Option
See intermediate presentation options.
Style Guidelines
Examples
See intermediate examples.
Rationale
Changes from previous UML

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.

Activities.fm Version 2 beta R1

September 9, 2002 11:31 am

430

21 Complete::Activities

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 t