Unified Modeling Language 2.0 Proposal

Transcription

1 ad/yyyy-mm-dd Date: 25 January 2002 Revised submission to OMG RFPs ad/ and ad/ : Unified Modeling Language 2.0 Proposal version (draft) Submitters: Alcatel Computer Associates Enea Business Software Ericsson Hewlett-Packard I-Logix International Business Machines IONA Jaczone Kabira Technologies Motorola Oracle Rational Software SOFTEAM Telelogic Unisys WebGain Supporters: Ceira Technologies Commissariat à L'Energie Atomique Embarcadero Technologies Gentleware Intellicorp Lockheed Martin MSC.Software Sims Associates Syntropy Ltd. University of Kaiserslautern

2 Copyright U2 Partners ( 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: 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, CORBASER- VICES, 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. ISSUE REPORTING This proposal is subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by reporting issues to u2p-issues@yahoogroups.com.

3 Preface 6 Submission summary 6 Technical submission 6 Compliance Issues 7 Resolution of Infrastructure RFP requirements 7 Resolution of Superstructure RFP requirements 9 Relation to Other MDA Specifications 13 How to Read this Specification 14 Part I. Introduction 16 Chapter 1. Language Architecture 18 The Common Core 18 The Four-Layer Metamodel Hierarchy 19 Architectural Alignment between UML and MOF 21 Package Structure 21 Chapter 2. Language Formalism 24 Levels of Formalism 24 Package Specification Structure 25 Class Specification Structure 25 Use of a Constraint Language 26 Use of Natural Language 27 Conventions and Typography 27 Part II. Core 28 Chapter 3. Core::Foundation::Classifiers 32 Class Descriptions 32 Chapter 4. Core::Foundation::Elements 38 Class Descriptions 38 Chapter 5. Core::Foundation::Generalizations 42 Class Descriptions 43 Chapter 6. Core::Foundation::Multiplicities 48 Class Descriptions 48 Chapter 7. Core::Foundation::Namespaces 54 Class Descriptions 54 Chapter 8. Core::Constructs::Aggregations 60 Class Descriptions 60 Chapter 9. Core::Constructs::Associations 64 Class Descriptions 64 Chapter 10. Core::Constructs::Attributes 72 Class Descriptions 72 Chapter 11. Core::Constructs::Classes 76 Class Descriptions 77 Chapter 12. Core::Constructs::Constraints 84 Class Descriptions. 85 Chapter 13. Core::Constructs::DataTypes 90 Class Descriptions 90 Chapter 14. Core::Constructs::Expressions 96 Class Descriptions 96 Chapter 15. Constructs - Increments 98 Class Descriptions 98 Chapter 16. Core::Constructs::Operations 106

4 Class Descriptions 107 Chapter 17. Core::Constructs::Packages 112 Class Descriptions 112 Chapter 18. Core::Primitive Types 120 Class Descriptions 120 Part III. Structure 124 Chapter 19. Structure::Associations 126 Class Descriptions 126 Chapter 20. Structure::Auxiliary Elements 132 Class Descriptions 132 Chapter 21. Structure::Classes 136 Class Descriptions 136 Chapter 22. Structure::Collaborations 140 Class Descriptions 141 Diagrams 147 Chapter 23. Structure::Components 152 Class Descriptions 154 Diagrams 188 Chapter 24. Structure::Dependencies 190 Class Descriptions 191 Chapter 25. Structure::Ports 196 Class Descriptions 196 Chapter 26. Structure::Interfaces 202 Class Descriptions 203 Chapter 27. Structure::Internal Structure 208 Class Descriptions 208 Chapter 28. Structure::Packages 214 Class Descriptions 214 Chapter 29. Structure::Relationships 218 Class Descriptions 218 Chapter 30. Structure::Templates 222 Class Descriptions 222 Part IV. Behavior 228 Chapter 31. Behavior::Actions 230 Class Descriptions 230 Chapter 32. Behavior::Activities 238 Class Descriptions 238 Chapter 33. Behavior::Common Behavior 292 Class Descriptions 293 Chapter 34. Behavior::Interactions 306 Class Descriptions 306 Diagrams 329 Semantic Model 336 Chapter 35. Behavior::State Machines 338 Class Descriptions 339 Chapter 36. Behavior::Use Cases 382 Class Descriptions 383 Diagrams 396 Part V. Profiles 398

5 Chapter 37. Profiles 400 Class Descriptions 400 Part VI. Diagrams 408 Chapter 38. Structural Diagrams 410 Graphic Nodes 410 Graphic Paths 411 Examples 412 Changes from UML 1.x 412 Appendices 414 Appendix A: Abstract Syntax Summary 416 Core 417 Structure 426 Behavior 437 Profiles 451 Appendix B: Glossary 452

6 1 1.1 Submission summary Preface This proposed UML 2.0 specification is in response to the Object Management Group Request For Proposals ad/ (UML 2.0 Infrastructure RFP) and ad/ (UML 2.0 Superstructure RFP). It integrates complementary proposals for both RFPs into a complete modeling language definition. This Preface summarizes the relationship of this submission to the RFPs and explains how it satisfies their requirements. The main body of the document describes the technical submission itself 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 is available on the Partners page of the U2 Partners web ( In addition, the following mailing lists are available for requesting information and reporting issues: u2p-info@yahoogroups.com to request general information u2p-issues@yahoogroups.com to report issues Guide to material in the submission See Part I, Introduction. Overall design rationale To be provided. Statement of proof of concept To be provided Technical submission The technical submission is presented in the main body of this document. It comprises a set of new packages that will result in a major revision to the architecture and foundation constructs of the UML 1.x specification. Preface.fm Version January 28, :37 pm 1-6

7 1 1.3 Compliance Issues 1.3. Compliance Issues To be provided Resolution of Infrastructure RFP requirements The submission meets the requirements of the UML 2.0 Infrastructure RFP ( ad/ ), as shown in the tables below: Table 1: Infrastructure RFP Mandatory Requirements MANDATORY REQUIREMENT 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 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 c: Proposals shall identify language elements to be retired from the language for reasons such as being vague, gratuitous, too specific, or not used d: Proposals shall specify an XMI DTD for the UML metamodel. RESOLUTION The proposed specification defines the semantics and notation for each metamodel construct, so that there is a straightforward and precise mapping between them. The proposed speficiation defines precise mappings between UML 1.x and UML 2.0 metamodel constructs in the Changes from UML 1.4 section for each construct. The upgrade path between the UML 1.x and UML 2.0 XMI DTDs will be provided in a future version of this proposal. Language elements to be retired from UML will be addressed in a future version of this proposal. An XMI DTD will be provided with a future version of this proposal. Preface.fm Version January 28, :37 pm 1-7

8 1 1.4 Resolution of Infrastructure RFP requirements MANDATORY REQUIREMENT a: Proposals shall specify the UML metamodel in a manner that is strictly aligned with the MOF meta-metamodel by conformance to a 4-layer metamodel architectural pattern. Stated otherwise, every UML metamodel element must be an instance of exactly one MOF metametamodel element. If this architectural alignment requires that the MOF metametamodel also needs to be changed, then those changes (including changes to XML and IDL mappings) should be fully documented in the proposal b: Proposals shall strive to share the same metamodel elements between the UML kernel and the MOF kernel, so that there is an isomorphic mapping between MOF meta-metamodel kernel elements and UML metamodel kernel elements. a c: Proposals shall restructure the UML metamodel to separate kernel language constructs from the standard elements that depend on them. The standard elements shall be restructured consistent with the requirements in d: Proposals shall decompose the metamodel into a package structure that supports compliance points and efficient implementation e: Proposals shall identify all semantic variation points in the metamodel a: Proposals shall specify how profiles are defined b: Proposals shall specify a firstclass extension mechanism that will allow modelers to add their own metaclasses, which will be instances of MOF metametaclasses. This mechanism must be compatible with profiles and consistent with the 4-layer metamodel architecture described in RESOLUTION The UML Infrastructure metamodel is an instance of a common Core package that will be shared between UML 2.0 and MOF 2.0. This is intended to be part of MOF 2.0. Therefore the XMI DTD for UML 2.0 will be generated using combination of the common Core and MOF. The proposed specification defines a common Core package that will be shared between UML 2.0 and MOF 2.0. This Core package contains common model elements that can be used as a kernel for different modeling domains. The relation of the common Core to UML, MOF and CWM is explained in Chapter 1, Language Architecture. The proposed specification will apply profiles to itself to separate kernel language constructs from standard elements that depend on them. The proposed specification defines a package structure that is finergrained than UML 1.x, which is intended to support more flexible compliance points and more efficient implementations. The package structure for this submission is specified in Chapter 1, Language Architecture. Semantic variation points will be defined in a future version of this proposal. The proposed specification includes an Extensions package that specifies how UML can be extended using profiles. Modelers can add their own meta classes either by instantiating MOF model elements or defining Profiles. The Profiles approach is compatible with the 4-layer metamodel architecture. Preface.fm Version January 28, :37 pm 1-8

9 1 1.5 Resolution of Superstructure RFP requirements MANDATORY REQUIREMENT 6.5.3c: Proposals shall identify model elements whose detailed semantics preclude specialization in a profile. If proposals need to generalize these model elements, they should propose refactoring consistent with the architecture and restructuring requirements described in RESOLUTION A meta-attribute "isfinal" will be added to UML classes to prevent any extensions. In regard to refactoring, the proposed package structure that is finer-grained than UML 1.x, and is intended to support more flexible compliance points and more efficient implementations. a. Kernel refers to core metamodel constructs that are used as the foundation for defining other metamodel constructs. e.g., in UML 1.4 the Core package may be considered the kernel for the rest of the metamodel. Table 2: Infrastructure RFP Optional Requirements OPTIONAL REQUIREMENTS 6.6.1a Proposals may refactor the UML metamodel to improve its structure if they can demonstrate that the refactoring will make it easier to implement, maintain or extend. RESOLUTION The proposed specification defines packages and classes that are finer-grained than UML 1.x, and which make the language more efficient to implement, maintain and extend. The package structure for this submission is specified in Chapter 1, Language Architecture and the advantages of the refactoring are described in Chapter 1, Language Architecture b Proposals may consider architectural alignment with other specification language standards a Proposals may support the definition of new kinds of diagrams using profiles. Architectural alignment of the proposed specification with other specification language standards is addressed in Chapter 1, Language Architecture. The support of new diagram types that use profiles will be addressed in a future version of this proposal Resolution of Superstructure RFP requirements The submission meets the requirements of the UML 2.0 Superstructure RFP ( ad/ ), as shown in the tables below: Table 3: Superstructure RFP Mandatory Requirements MANDATORY REQUIREMENT 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. RESOLUTION The proposed specification defines the semantics and notation for each metamodel construct, so that there is a straightforward and precise mapping between them. Preface.fm Version January 28, :37 pm 1-9

10 1 1.5 Resolution of Superstructure RFP requirements MANDATORY REQUIREMENT 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 c: Proposals shall identify language elements to be retired from the language for reasons such as being vague, gratuitous, too specific, or not used d: Proposals shall specify an XMI DTD for the UML metamodel : 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). 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+. RESOLUTION The proposed speficiation defines precise mappings between UML 1.x and UML 2.0 metamodel constructs in the Changes from UML 1.4 section for each construct. The upgrade path between the UML 1.x and UML 2.0 XMI DTDs will be provided in a future version of this proposal. Language elements to be retired from UML will be addressed in a future version of this proposal. An XMI DTD will be provided with a future version of this proposal. The requirements for component-based development are addressed in the following chapters: Chapter 27, Structure::Internal Structure and Chapter 23, Structure::Components. Preface.fm Version January 28, :37 pm 1-10

11 1 1.5 Resolution of Superstructure RFP requirements MANDATORY REQUIREMENT 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. 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 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. 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. RESOLUTION The requirements for run-time architectures are addressed in the following chapters: Chapter 27, Structure::Internal Structure and Chapter 35, Behavior::State Machines. The requirements for relationships areaddressed in the following chapters: Chapter 5, Core::Foundation::Generalizations, Chapter 19, Structure::Associations, and Chapter 29, Structure::Relationships. Preface.fm Version January 28, :37 pm 1-11

12 1 1.5 Resolution of Superstructure RFP requirements MANDATORY REQUIREMENT 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. 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 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. 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 Interactions: Proposals shall define mechanisms to describe the decomposition of a role in an interaction into an interaction of its constituent parts. 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. RESOLUTION The requirements for relationships are addressed in the following chapter: Chapter 35, Behavior::State Machines. The requirements for relationships are addressed in the following chapter: Chapter 32, Behavior::Activities. The requirements for relationships are addressed in the following chapter: Chapter 34, Behavior::Interactions. Preface.fm Version January 28, :37 pm 1-12

13 1 1.6 Relation to Other MDA Specifications Table 4: Superstructure RFP Optional Requirements OPTIONAL REQUIREMENTS 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 Behavioral Modeling: 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 Notation: Proposals may review and improve the consistency of how symbols and icons are used in the various kinds of 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) 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. RESOLUTION To be addressed in a future version of this proposal. To be addressed in a future version of this proposal. To be addressed in a future version of this proposal. To be addressed in a future version of this proposal Relation to Other MDA Specifications To be addressed in a future version of this proposal. Preface.fm Version January 28, :37 pm 1-13

14 1 1.7 How to Read this Specification 1.7. How to Read this Specification This specification is organized in a manner consistent with the architecture of the UML. Consequently, readers are encouraged to first read Chapter 1, Language Architecture and Chapter 2, Language Formalism to familiarize themselves with the structure of the language and the formal approach used for its specification. Afterwards the reader may choose to read Parts II-V, which describe the top-level packages of the UML: Core, Structure, Behavior and Extensions. These top-level packages are organized into subpackages, as described in Chapter 1, Language Architecture. The structure of the chapters parallels that of the UML package structure, where leaf packages are alphabetized for easy reference. Although the packages are organized in a logical manner and they can be read sequentially, this is a reference specification is intended to be read in a non-sequential manner. Consequently, extensive cross-references and indices are provided to facilitate browsing and search. Preface.fm Version January 28, :37 pm 1-14

15 1 1.7 How to Read this Specification Preface.fm Version January 28, :37 pm 1-15

16 1 Introduction Part I. Introduction The Unified Modeling Language is a language for visualizing, specifying, constructing and documenting the artifacts of software systems. It is a general-purpose modeling language that can be used with all major object and component methods and applied to all application domains. The OMG adopted the UML 1.1 specification in November Since then UML Revision Task Forces have produced several minor revisions, the most recent being the UML 1.4 specification, which was adopted in May Under the stewardship of the OMG, the UML has emerged as the software industry s dominant modeling language. It has been successfully applied to a wide range of domains, ranging from health and finance to aerospace to e-commerce. As should be expected, its extensive use has raised numerous application and implementation issues by modelers and vendors. As of the time of this writing over 500 formal usage and implementation issues have been submitted to the OMG for consideration. Although many of the issues have been resolved in minor revisions by Revision Task Forces, other issues require major changes to the language that are outside the scope of an RTF. Consequently, the OMG has issued four complementary and architecturally aligned RFPs to define UML 2.0: UML 2.0 Infrastructure, UML 2.0 Superstructure, UML 2.0 Object Constraint Language and UML 2.0 Diagram Interchange. This proposed UML 2.0 specification integrates complementary proposals for the UML 2.0 Infrastructure and Superstructure RFPs into a complete modeling language definition. The manner in which the proposal address individual RFP requirements is addressed in the Preface of this proposal. The next two chapters describe the language architecture and formalism approach used to define UML 2.0. Part-Introduction.fm Version January 28, :37 pm 1-16

17 1 Introduction Part-Introduction.fm Version January 28, :37 pm 1-17

18 1 Language Architecture 1.1 The Common Core Chapter 1. Language Architecture This section contains a description of the architecture of the UML. It explains how the UML metamodel and other related OMG metamodels (e.g., Meta Object Facility, Common Warehouse Metamodel) are based on the UML s Core package. It also describes the package structure of the UML metamodel The Common Core The foundation of UML 2.0 is its Core package, which contains the basic elements that are used to specify the UML metamodel and other related OMG metamodels, such as the Meta-Object Facility (MOF) and the Common Warehouse Metamodel (CWM). In addition to fully supporting the advanced constructs in the UML 2.0 Superstructure, the Core package has been designed to be forward-compatible with the next major revisions of MOF and CWM. This Core-centric architecture is shown in Figure 1-1. MOF CWM «import» «import» Core «import» «import» UML Profiles Figure 1-1. The Core architecture Since the metamodels that import and reuse the Core are central to the OMG Model-Driven Architecture (MDA), the UML 2.0 Core may also be considered the architectural kernel of the MDA. The architectural intent is for UML 2.0 and other future MDA metamodels to import the Core and reuse its abstract syntax, well-formedness rules and detailed semantics. This reuse-based approach will allow new metamodels to be created more efficiently and precisely, since they can share the same precise semantics on which UML 2.0 is based. The Profiles package of UML 2.0 makes the extension mechanisms of UML more powerful and flexible, and is applicable to all metamodels that are based on the Core. Language-Architecture.fm Version January 28, :37 pm 1-18

19 1 Language Architecture 1.2 The Four-Layer Metamodel Hierarchy This submission is a joint response to both the UML 2.0 Infrastructure RFP and the UML 2.0 Superstructure RFP. Architecturally, the Core and Profiles packages belong to Infrastructure part, while the rest of the submission packages belong to the Superstructure part. The UML 2.0 submission thus covers the shaded parts of Figure 1-2. MOF CWM «import» «import» Core «import» «import» UML Profiles Figure 1-2. The UML architecture 1.2. The Four-Layer Metamodel Hierarchy The Core architecture is a complementary view of the four-layer metamodel hierarchy on which the UML metamodel is based. This architecture is a proven framework for precisely defining metamodels, and how models can be instantiated from them. Other advantages associated with this approach include the following: It provides a basis for defining future UML metamodel extensions. It allows dynamic extensions of UML models through profiles. It facilitates aligning the UML metamodel with other standards based on the same metamodeling principles, for example the Meta-Object Facility (MOF). Although frameworks for metamodeling may be based on an arbitrary number of different metalayers, it is convenient to limit the number of levels in practice: a meta-metamodel, a metamodel, a model, and run-time instances. This architecture is depicted in Figure 1-3. The meta-metamodeling layer forms the foundation of the metamodeling hierarchy. The primary responsibility of this layer is to define the language for specifying a metamodel. The layer is often referred to as M3, and MOF is a prime example of a meta-metamodel. A meta-metamodel is typically more compact than a metamodel that it describes, and often defines several metamodels. It is generally desirable that related metamodels and meta-metamodels share common design philosophies and constructs. However, each layer can be viewed independently of other layers, and needs to maintain its own design integrity. A metamodel is an instance of a meta-metamodel, meaning that every element of the metamodel is an instance of an element in the meta-metamodel. The primary responsibility of the metamodel layer is to define a language for specifying models. The layer is often referred to as M2; UML and the OMG Common Warehouse Metamodel (CWM) are prime examples of metamodels. Metamodels are typically more elaborate than the meta-metamodels that describe them, especially when they define dynamic semantics. The UML metamodel is an instance of the MOF (in effect, each UML metaclass is an instance of an element in Core). A model is an instance of a metamodel. The primary responsibility of the model layer is to define languages that describe semantic domains, i.e., to allow users to model a wide variety of different problem domains, such as software, business processes, and requirements. The things that are being modeled reside outside the metamodel hierar- Language-Architecture.fm Version January 28, :37 pm 1-19

20 1 Language Architecture 1.2 The Four-Layer Metamodel Hierarchy chy. This layer is often referred to as M1. A user model is an instance of the UML metamodel. Note that the user model contains both model elements and snapshots (illustrations) of instances of these model elements. The metamodel hierarchy bottoms out at M0, which contains the run-time instances of model elements defined in a model. The snapshots that are modeled at M1 are constrained versions of the M0 run-time instances. An Example of the Four-layer Architecture of UML A simple example of the four-layer architecture in action is shown in Figure 1-3. M3 (MOF) Class «instanceof» «instanceof» «instanceof» M2 (UML) Attribute Class classifier Instance «instanceof» «instanceof» «instanceof» «instanceof» M1 (User model) Video +title: String «snapshot» : Video title = "2001: A Space Odyssey" «instanceof» M0 (Run-time instances) avideo Figure 1-3. An example of the four-layer architecture Language-Architecture.fm Version January 28, :37 pm 1-20

21 1 Language Architecture 1.3 Architectural Alignment between UML and MOF 1.3. Architectural Alignment between UML and MOF Both the UML and the MOF share the same common Core package and are based on the same four-layer metamodel hierarchy. In Figure 1-4, the meta-relationships between UML, MOF, and CWM are shown (considering only the M2 and M3 metalayers). M3 «metamodel» MOF «instanceof» «instanceof» M2 «metamodel» UML «metamodel» CWM Figure 1-4. Relationships between UML and MOF Just like the Core specifies the basic constructs for defining UML, it also serves a similar function for MOF. MOF defines for example how UML models are interchanged between tools using XML Metadata Interchange (XMI). MOF also defines reflective interfaces (MOF::Reflection) for introspection that work for MOF itself, but also for CWM, UML, and any other metamodel that is an instance of MOF. MOF further defines an extension mechansism that can be used to extend metamodels as an alternative or in conjunction with profiles (as described in Chapter 37, Profiles ). In fact, profiles are defined to be a limited subset of the MOF extension mechanism Package Structure The packages of UML (shown in Figure 1-5) are all divided into a number of fine-grained logical packages. Both Core and the other UML packages are described in a combination of graphical notation, natural langauge, and formal language. We recognize that there are theoretical limits to what one can express about a metamodel using the metamodel itself. However, our experience suggests that this combination strikes a reasonable balance between expressiveness and readability. «import» Profiles Core «import» Structure «import» Behavior Figure 1-5. The packages that define UML Language-Architecture.fm Version January 28, :37 pm 1-21

22 1 Language Architecture 1.4 Package Structure The Core Package The general structure of the Core package is accomplished by distinguishing between a Foundation package containing packages with mostly abstract metaclasses, and a Constructs package that builds on the foundation and contains packages with mostly concrete metaclasses. The primary reason for the fine-grained packages is to make it easy for other metamodels to extend Core (or parts thereof). Each package defined contain metaclasses that show strong cohesion with each other, and loose coupling with metaclasses in other packages. These two packages also make use of a PrimitiveTypes package containing types used in both Foundation and Constructs, such as Integer, Boolean, and String. Each package contains an abstract syntax that is modeled using the Core, consisting of a UML class diagram and a supporting natural language description. Structure Package The Structure package imports the Core package. Some of the subpackages of Structure extends elements defined in Core when the requirements go beyond what is required for metamodeling, and in general the package itself is mostly concerned with different architectural aspects, such as relationships between elements (in the packages InternalStructure, Depencencies, and Relationships), contracts between elements (in the packages Interfaces, Ports, and Collaborations), and the elements as structural entities (in the packages Classes and Components). Behavior Package The Behavior package imports the Structure package, and is mostly concerned with modeling behavioral aspects, including packages like Actions, Activities, Interactions, StateMachines, and UseCases. These all existed in UML 1.x, but they have all been more or less improved. Profiles Package Profiles, which are defined in the Profiles package, are a restricted way to extend metamodels based on the Core, such as the UML metamodel. The profiles mechanism allows these extensions to be dynamically applied to and removed from models. UML a general-purpose modeling language intended to be suitable for a wide array of applications. However, because of this generality there are often situations or domains that are not fully captured as part of the language. It is therefore necessary to express specific concerns by introducing mechanisms to extend or tailor UML language constructs. Typical examples of when these mechanisms are desired are when targeting a specific environment (such as Java, C++, CORBA, or EJB), when addressing a specific domain (such as real-time, business objects, or software process modeling), and when tailoring the UML for different development phases (such as requirements, analysis, or design). A profile expresses one way to extend or tailor a metamodel. A profile is a restricted metamodel, and manifests a subset of the capabilities offered by the more general extension mechanisms of MOF with the intent to offer a lightweight extensibility mechanism. Each profile created extends the UML metamodel. In the end-user s model, there are always instances of elements in the UML metamodel. In addition, there may be elements that are instances of elements in one or more profiles, and which are linked to the instances of the UML metamodel. Some of the specific properties exhibited by profiles are: A profile may extend a reference metamodel that is based on the Core package. A reference metamodel is a metamodel that is being extended. It is called referenced because it cannot be changed, and the profile cannot be used without it. Specifically, since the UML metamodel is based on the Core it may be extended using profiles. A profile is created by extending the referenced metamodel using a delegation pattern (a kind of generalization). This is done to achieve a dynamic extension mechanism that allows extensions to be freely added and removed from a model. There are several constraints associated with a profile to guarantee that it is dynamically applicable. Specifically, the delegation patterns ensures that an extended UML model can always be interpreted as an ordinary UML model without extensions. Language-Architecture.fm Version January 28, :37 pm 1-22

23 1 Language Architecture 1.4 Package Structure The use of the delegation pattern allows multiple profiles to be applied to a model at the same time. Each profile can thus represent a specific view of the same model. The referenced metamodel and its XMI DTD remains unchanged. A model extended by profiles can be interchanged through the XMI format, and interpreted using only the DTD of the referenced metamodel. The profiles can also be interchanged using the same DTD. Specifically, a UML model extended by profiles can be interchanged using only the UML DTD. If a tool does not support the applied profiles, it can still understand the model as an ordinary UML model. Language-Architecture.fm Version January 28, :37 pm 1-23

24 2 Language Formalism 2.1 Levels of Formalism Chapter 2. Language Formalism This section contains a description of the techniques used to describe UML. The specification adapts formal techniques to improve precision while maintaining readability. The technique describes the UML metamodel in three views using both text and graphic presentations. The benefits of adapting formal techniques include: the correctness of the description is improved, ambiguities and inconsistencies are reduced, the architecture of the metamodel is validated by a complementary technique, and the readability of the description is increased. It is important to note that the current description is not a completely formal specification of the language because to do so would have added significant complexity without clear benefit. The structure of the language is nevertheless given a precise specification, which is required for tool interoperability. The detailed semantics are described using natural language, although in a precise way so they can easily be understood. Currently, the semantics are not considered essential for the development of tools; however, this will probably change in the future Levels of Formalism A common technique for specification of languages is to first define the syntax of the language and then to describe its static and dynamic semantics. The syntax defines what constructs exist in the language and how the constructs are built up in terms of other constructs. Sometimes, especially if the language has a graphic syntax, it is important to define the syntax in a notation independent way (i.e., to define the abstract syntax of the language). The concrete syntax is then defined by mapping the notation onto the abstract syntax. The static semantics of a language define how an instance of a construct should be connected to other instances to be meaningful, and the dynamic semantics define the meaning of a well-formed construct. The meaning of a description written in the language is defined only if the description is well formed (i.e., if it fulfills the rules defined in the static semantics). The specification uses a combination of languages - a subset of UML, an object constraint language, and precise natural language to describe the abstract syntax and semantics of the full UML. The description is self-contained; no other sources of information are needed to read the document 1. Although this is a metacircular description 2, understanding this document is practical since only a small subset of UML constructs are needed to describe its semantics. In constructing the UML metamodel different techniques have been used to specify language constructs, using some of the capabilities of UML. The main language constructs are reified into metaclasses in the metamodel. Other constructs, in essence being variants of other ones, are defined as stereotypes of metaclasses in the metamodel. This mechanism allows the semantics of the variant construct to be significantly different from the base metaclass. Another more lightweight way of defining variants is to use metaattributes. As an example, the aggregation construct is specified by an attribute of the metaclass AssociationEnd, which is used to indicate if an association is an ordinary aggregate, a composite aggregate, or a common association. 1. Although a comprehension of the UML s four-layer metamodel architecture and its underlying metametamodel is helpful, it is not essential to understand the UML semantics. 2. In order to understand the description of the UML semantics, you must understand some UML semantics. Language-Formalism.fm Version January 28, :37 pm 2-24

25 2 Language Formalism 2.2 Package Specification Structure 2.2. Package Specification Structure This section provides information for each package and each class in the UML metamodel. Each package has one or more of the following subsections: Class Descriptions The section contains an enumeration of the classes specifying the constructs defined in the package. It begins with one diagram or several diagrams depicting the abstract syntax of the constructs (i.e. the classes and their relationships) in the package, together with some of the well-formedness requirements (multiplicity and ordering). Then follows a specification of each class in alphabetic order (see below). Diagrams If a specific kind of diagram usually presents the constructs that are defined in the package, a section describing this kind of diagram is included. Instance Model An example may be provided to show how an instance model of the contained classes may be populated. The elements in the example are instance of the classes contained in the package (or in an imported package) Class Specification Structure The specification of a class starts with a presentation of the general meaning of the concept which sets the context for the definition. Description The section includes an informal definition of the metaclass specifying the construct in UML. The section states if the metaclass is abstract. This section together with the following two constitute a description of the abstract syntax of the construct. Attributes Each of the attributes of the class are enumerated together with a short explanation. The section states if the attribute is derived, or if it is a specialization of another attribute. If the multiplicity of the attribute is suppressed if it is 1 (default in UML). Associations The opposite ends of associations connected to the class are also listed in the same way. The section states if the association is derived, or if it is a specialization of another association. The multiplicity of an association end is suppressed if it is (default in UML). Constraints The well-formedness rules of the metaclass, except for multiplicity and ordering constraints that are defined in the diagram at the beginning of the package section, are defined as a (possibly empty) set of invariants for the metaclass, which must be satisfied by all instances of that metaclass for the model to be meaningful. The rules thus specify constraints over attributes and associations defined in the metamodel. Most invariant is defined by an OCL expression together with an informal explanation of the expression, but in some cases the invariant is expressed by other means (in exceptional cases with natural language). The statement No additional constraints means that all well-formed- Language-Formalism.fm Version January 28, :37 pm 2-25

26 2 Language Formalism 2.4 Use of a Constraint Language ness rules are expressed in the superclasses together with the multiplicity and type information expressed in the diagrams. Additional Operations (optional) In many cases, additional operations on the classes are needed for the OCL expressions. These are then defined in a separate subsection after the constraints for the construct, using the same approach as the Constraints section: an informal explanation followed by the OCL expression defining the operation. Semantics The meaning of a well-formed construct is defined using natural language. Semantic Variation Points (optional) If the semantics of a construct is allowed to be different from what is defined in the previous section, the specific part of the semantics is described in this section as well as how it may vary. Notation The notation of the construct is presented in this section. Presentation Options (optional) If there are different ways to show of the construct, e.g. it is not necessary to show all parts of the construct in every occurrence, these possibilities are described in this section. Style Guidelines (optional) Often is an informal convention how to show (a part of) a construct, like the name of a class should be centered and in bold. These conventions are presented in this section. Examples (optional) In this section, examples of how the construct is to be depicted are given. Rationale (optional) If there is a reason for why a construct is defined like it is, or why its notation is defined as it is, this reason is given in this section. Changes from UML 1.4 Here, changes compared with UML 1.4 are described and a migration approach from 1.4 to 2.0 is specified Use of a Constraint Language The specification uses the Object Constraint Language (OCL), as defined in Chapter 6, Object Constraint Language Specification of the UML 1.4 specification, for expressing well-formedness rules. The following conventions are used to promote readability: Self - which can be omitted as a reference to the metaclass defining the context of the invariant, has been kept for clarity. In expressions where a collection is iterated, an iterator is used for clarity, even when formally unnecessary. The type of the iterator is usually omitted, but included when it adds to understanding. The collect operation is left implicit where this is practical. Language-Formalism.fm Version January 28, :37 pm 2-26

27 2 Language Formalism 2.5 Use of Natural Language The context part of an OCL constraint is not included explicitly, as it is well-defined in the section where the constraint appears Use of Natural Language We strove to be precise in our use of natural language, in this case English. For example, the description of UML semantics includes phrases such as X provides the ability to and X is a Y. In each of these cases, the usual English meaning is assumed, although a deeply formal description would demand a specification of the semantics of even these simple phrases. The following general rules apply: When referring to an instance of some metaclass, we often omit the word instance. For example, instead of saying a Class instance or an Association instance, we just say a Class or an Association. By prefixing it with an a or an, assume that we mean an instance of. In the same way, by saying something like Elements we mean a set (or the set) of instances of the metaclass Element. Every time a word coinciding with the name of some construct in UML is used, that construct is ment. Terms including one of the prefixes sub, super, or meta are written as one word (e.g., metamodel, subclass) Conventions and Typography In the description of UML, the following conventions have been used: When referring to constructs in UML, not their representation in the metamodel, normal text is used. Metaclass names that consist of appended nouns/adjectives, initial embedded capitals are used (e.g., ModelElement, StructuralFeature ). Names of metaassociations are written in the same manner as metaclasses (e.g., ElementReference ). Initial embedded capital is used for names that consist of appended nouns/adjectives (e.g., ownedelement, all- Contents ). Boolean metaattribute names always start with is (e.g., isabstract ). Enumeration types always end with Kind (e.g., AggregationKind ). While referring to metaclasses, metaassociations, metaattributes, etc. in the text, the exact names as they appear in the model are always used. No visibilities are presented in the diagrams, as all elements are public. If a mandatory section does not apply for a metaclass, the text No additional XXX is used, where XXX is the name of the heading. If an optional section is not applicable, it is not included. A collection of design patterns have been used. These patterns are described in... [ to be written ]. Language-Formalism.fm Version January 28, :37 pm 2-27

28 2 Core Part II. Core This part describes the package structure and contents of the UML Core package, which defines the basic constructs of the language used to define UML and other metamodels (e.g., Meta Object Facility, Common Warehouse Model). The Core package is one of the four top-level packages that define the UML. The relationship of the Core package to the other top-level packages is shown in Figure 2-6. Core <<import>> <<import>> Extensions Structure <<import>> Behavior Figure 2-6. Top-Level Packages The Core package is further decomposed as shown in Figure 2-7. The general structure is accomplished by distinguishing between a Foundation package containing mainly packages with abstract metaclasses, and a Constructs package that builds on the foundation and contains packages with mostly concrete metaclasses. The primary reason for fine-grained packages is to make it easy for other metamodels to extend the Core (or parts thereof). These two packages also make use of a PrimitiveTypes package containing types used in both Foundation and Constructs, such as Integer, Boolean, and String. Part-Core.fm Version January 28, :37 pm 2-28