| Previous | UML Classes | Table of Contents | UML Packages | Next |
The concepts of UML are grouped into three major parts:
• Part I: Concepts related to the modeling of structure
• Part II: Concepts related to the modeling of behavior
• Part III: Supplementary concepts
Within each part, the concepts are grouped into chapters according to modeling capability. A capability typically covers a
specific modeling formalism. For instance, all concepts related to the state machine modeling capability are gathered in the
State Machines chapter and all concepts related to the activities modeling capability are in the Activities chapter. The Capability
chapters in each part are presented in alphabetical order.
Within each chapter, there is first a brief informal description of the capability described in that chapter. This is followed
by a section describing the abstract syntax for that capability. The abstract syntax is defined by a CMOF model (i.e., the
UML metamodel) with each modeling concept represented by an instance of a MOF class or association. The model is decomposed
into packages according to capabilities. In the specification, this model is described by a set of UML class and package diagrams
showing the concepts and their relationships. The diagrams were designed to provide comprehensive information about a related
set of concepts, but it should be noted that, in many cases, the representation of a concept in a given diagram displays only
a subset of its features (the subset that is relevant in that context). The same concept may appear in multiple diagrams with
different feature subsets. For a complete specification of the features of a concept, readers should refer to its formal concept
description (explained below). When the concepts in the capability are grouped into sub packages, the diagrams are also grouped
accordingly with a heading identifying the sub package preceding each group of diagrams. In addition, the name of the owning
package is included in each figure caption.
The Concept Definitions section follows the abstract syntax section. This section includes formal specifications of all concepts
belonging to that capability, listed in alphabetical order. Each concept is described separately according to the format explained
below.
The final section in most chapters gives an overview of the diagrams, diagram elements, and notational rules and conventions
that are specific to that capability.
The formal concept descriptions of individual concepts are broken down into sub sections corresponding to different aspects.
In cases where a given aspect does not apply, its sub section may be omitted entirely from the class description. The following
sub sections and conventions are used to specify a concept:
• In some cases, following the heading is a brief, one- or two-sentence informal description of the meaning of a concept. This is intended as a quick reference for those who want only the basic information about a concept.
• All the direct generalizations of a concept are listed, alphabetically, in the Generalizations sub section. A direct generalization of a concept is a concept (e.g., a class) that is immediately above it in the hierarchy of its ancestors (i.e., its parent). Note that these items are hyperlinked in electronic versions of the document to facilitate navigation through the metamodel class hierarchy. Readers of hardcopy versions can use the page numbers listed with the names to rapidly locate the description of the superclass. This sub section is omitted for enumerations.
• A more detailed description of the purpose, nature, and potential usage of the concept may be provided in the Description sub section. This too is informal. If a concept is defined in multiple increments, then the first part of the description covers the top-level package and is followed, in turn, by successive description increments for each sub package. The individual increments are identified by a sub package heading such as
• The heading gives the formal name of the concept and indicates, in parentheses, the sub package in which the concept is defined. In some cases, there may be more than one sub package name listed. This occurs when a concept is defined
in multiple package merge increments – one per package. In a few instances, there is no package name, but the phrase as specialized appears in parentheses. This indicates a semantic increment, which does not involve a new increment in the metamodel and which, therefore, does not change the abstract syntax, but which adds new semantics to previous increments (e.g., additional constraints).
Package PowerTypes
This indicates that the text that follows the heading describes the increment that was added in the PowerTypes sub package.
The description continues either until the end of the sub section or until the next sub package increment heading is encountered.
• This convention for describing sub package increments is applied to all other sub sections related to the concept.
• The Attributes sub section of a concept description lists each of the attributes that are defined for that metaclass. Each attribute is specified by its formal name, its type, and multiplicity. If no multiplicity is listed, it defaults to 0..*. This is followed by a textual description of the purpose and meaning of the attribute. If an attribute is derived, the name will be preceded by a slash. For example:
•body: String[1] Specifies a string that is the comment
specifies an attribute called body whose type is String and whose multiplicity is 1.
• If an attribute is derived, where possible, the definition will also include a specification (usually expressed as an OCL
constraint) specifying how that attribute is derived. For instance:
•/isComposite : Boolean A state with isComposite = true is said to be a composite state. A composite state is a state that
contains at least one region>
isComposite = (region > 1)
• The Associations sub section lists all the association ends owned by the concept. The format for these is the same as the
one for attributes described above. Association ends that are specializations or redefinitions of other association ends in
superclasses are flagged appropriately. For example:
•lowerValue: ValueSpecification [0..1] {subsets Element::ownedElement} The specification of the lower bound for this
multiplicity.
specifies an association end called lowerValue that is connected to the ValueSpecification class and whose multiplicity is
0..1. Furthermore, it is a specialization of the ownedElement association end of the class Element.
• As with derived attributes, if an association end is derived, where possible, the definition will also include a specification (usually expressed as an OCL constraint) specifying how that association end is derived.
• The Constraints sub section contains a numerical list of all the constraints that define additional well-formedness rules that apply to this concept. Each constraint consists of a textual description and may be followed by a formal constraint expressed in OCL. Note that in a few cases, it may not be possible to express the constraint in OCL, in which case the formal expression is omitted.
• Additional Operations contains a numerical list of operations that are applicable to the concept. These may be queries or utility operations that are used to define constraints or other operations. Where possible, operations are specified using OCL.
• The Semantics sub section describes the meaning of the concept in terms of its concrete manifestation. This is a specification of the set of things that the concept models (represents) including, where appropriate, a description of the behavior of those things (i.e., the dynamic semantics of the concept).
• Semantic Variation Points explicitly identifies the areas where the semantics are intentionally under specified to provide leeway for domain-specific refinements of the general UML semantics (e.g., by using stereotypes and profiles).
• The Notation sub section gives the basic notational forms used to represent a concept and its features in diagrams. Only concepts that can appear in diagrams will have a notation specified. This typically includes a simple example illustrating the basic notation. For textual notations a variant of the Backus-Naur Form (BNF) is often used to specify the legal formats. The conventions of this BNF are:
• All non-terminals are in italics and enclosed between angle brackets (e.g., <non-terminal>). • All terminals (keywords, strings, etc.), are enclosed between single quotes (e.g., ‘or’). • Non-terminal production rule definitions are signified with the ‘::=’ operator. • Repetition of an item is signified by an asterisk placed after that item: ‘*’. • Alternative choices in a production are separated by the ‘|’ symbol (e.g., <alternative-A> | <alternative-B>). • Items that are optional are enclosed in square brackets (e.g., [<item-x>]). • Where items need to be grouped they are enclosed in simple parenthesis; for example:
(<item-1> | <item-2>) *
signifies a sequence of one or more items, each of which is <item-1> or <item-2>.
• The Presentation Options sub section supplements the Notation section by providing alternative representations for the concept or its parts. Users have the choice to use either the forms described in this sub section or the forms described in the Notation sub section.
• Style Guidelines identifies notational conventions recommended by the specification. These are not normative but, if applied consistently, will facilitate communication and understanding. For example, there is a style guideline that suggests that the names of classes should be capitalized and another one that recommends that the names of abstract classes be written out in italic font. (Note that these specific recommendations only make sense in certain writing systems, which is why they cannot be normative.)
• The Examples sub section, if present, includes additional illustrations of the application of the concept and its notation.
• Changes from previous UML identifies the main differences in the specification of the concept relative to UML versions 1.5 and earlier.