Previous UML Classes Table of Contents UML Packages Next

6.5.1 Specification format

   The concepts of UML are grouped into three major parts:

   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:

   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.

   •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


   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.

   (<item-1> | <item-2>) *

   signifies a sequence of one or more items, each of which is <item-1> or <item-2>.