| A | abstraction to Attribute | N | Name to notes |
| B | becomes to broadcast | O | object to owns |
| C | call to copy | P | Package to Pseudostate |
| D | define to documentation | Q | qualification to qualifier |
| E | effect to extension points | R | References to roles |
| F | facade to friend | S | scenario to System |
| G | GeneralizableElement to global | T | table to types |
| I | implements to invocation | U | Uninterpreted to utility |
| L | library to location | V | Value to vote |
| M | Member to Multiplicity |
| Class | Message | StateMachine |
| Constraint | ModelElement | Stereotype |
| Dependency | Operation | System |
| Element | Package | TaggedValue |
| Instance | Relationship | Type |
Click here to go back to the home page of my company, Software Documentation Wizards.
I intend to update and expand the UML Dictionary to comform with version 1.1 of the UML, which the Object Management Group (OMG) declared to be a standard in November of 1997. However, I do have a full-time job, and as of February 11, I will be writing another UML book (with Doug Rosenberg, president of ICONIX; this one will focus on use cases), so it will be a while before the 1.1 Dictionary is in place. In the meantime, happy reading!
Note: This Dictionary may be considered to be in the public domain. However, if you would like to use it for commercial purposes, kindly do the following: (1) send me E-mail telling me what you plan to do, and (b) add a link to http://softdocwiz.com so your customers can find out what else I have to offer in the way of software documentation.
A Model is an abstraction of exactly one System. Conversely, a System may be abstracted by zero or more Models.
Action
The term Action refers to an invocation of a Signal or an Operation that represents a computational or algorithmic procedure. This is work carried out as an effect of a change in State.
Action is a subtype of ModelElement.
action
The term action refers to a Relationship between an Action and a Message.
An Action is the action that triggers at most one Message. Conversely, a Message receives an action from exactly one Action.
ActionExpression
The term ActionExpression refers to an Expression that resolves to references to one or more Actions.
The operations associated with ActionExpression are as follows:
A BehaviorInstance may specify the actions for zero or more UseCases. Conversely, a UseCase may have actions associated with no more than one BehaviorInstance.
ActionState
The term ActionState refers to a State that has no substates, exactly one internal transition (do), and an effect whose associated ActionExpression resolves to an Action that invokes exactly one Operation.
ActionState is a subtype of State.
An ActionState would normally be used to model a step in the execution of a procedure.
activation
The term activation refers to the execution of an Operation.
ActiveClass
The term ActiveClass refers to a Class that embodies one or more threads.
Each ActiveClass represents the root of an independent flow of control. The set of ActiveClass instances within the same scope represents a concurrent flow of control.
ActiveClass is a subtype of Class. As such, an ActiveClass may be connected with a Type by a refinement relationship. The Type associated with a given ActiveClass acts as an interface to that ActiveClass.
ActiveClass is ultimately a subtype of Element. As such, an ActiveClass can participate in Dependencies, and an ActiveClass can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
Since ActiveClass is also ultimately a subtype of GeneralizableElement, an ActiveClass can participate in Generalizations as well.
ActivityDiagram
The term ActivityDiagram refers to a Diagram that encompasses States and their Relationships, organized by Actions, in order to specify the Behavior of an Operation.
An ActivityDiagram reflects StateMachines whose vertices are all ActionStates. Whereas a StateDiagram is designed to show asynchronous, externally-generated Events, an ActivityDiagram is designed to show Events that represent the completion of internally-generated Actions (in other words, procedural flow of control).
actor
The term actor refers to a stereotyped Type that represents an entity outside of the system being modeled that interacts with one or more UseCases.
actual argument
The term actual argument refers to a Relationship between an Action and a number of Instances.
An Action may have zero or more Instances as its actual arguments. Conversely, an Instance may be an actual argument of zero or more Actions.
If an Action represents the invocation of an Operation or a Signal, the Instances that comprise that Action's actual arguments must be ordered and must match the associated FormalParameters or Attributes, respectively.
application
The term application refers to a stereotyped Component that represents an executable program.
Association
The term Association refers to a bidirectional connection between two Instances.
Association is a subtype of Relationship. As such, if the next-to-last Instance connected to a given Association is destroyed, that Association is also destroyed, because a "dangling" Association is not allowed.
An Association has an associated non-null Name. The Names associated with the Associations connected to a given Type must each be unique.
association
The term association refers to a stereotyped Constraint which specifies that the Instance associated with a particular LinkRole is visible.
association class
The term association class refers to a Relationship between a Class and an Association.
An association class can be seen as either an Association that has Class properties or a Class that has Association properties. Regardless of which view is taken, an association class is considered to be a single ModelElement.
A Class may be associated with no more than one Association via an association class. Conversely, an Association is associated with no more than one Class via an association class.
An Association and a Class connected by an association class must have the same Name.
AssociationRole
The term AssociationRole refers to a "face" that a given Type wears within a particular Association.
AssociationRole is a subtype of ModelElement.
An AssociationRole has an associated non-null Name.
The attributes associated with AssociationRole are as follows:
An Association is associated, via association roles, with two or more AssociationRoles. (The most common number is two.) Conversely, an AssociationRole is the association role for one Association.
Attribute
The term Attribute refers to a structural feature of a Type.
Attribute is a subtype of Member.
An Attribute has an associated non-null Name. This Name must be unique within the context of the enclosing Type.
An Attribute is connected to an Association by a qualifier relationship.
The attributes associated with Attribute are as follows:
Behavior
The term Behavior refers to an observable effect of an Operation or Event, including its results.
Behavior is an abstract subtype of ModelElement.
Since Behavior is ultimately a subtype of Element, a Behavior can have associated Stereotypes. It is common to use Stereotypes to distinguish different kinds of Behaviors (such as "primary" and "secondary"). A Behavior can also participate in Dependencies and have TaggedValues, Notes, and Constraints attached to it.
The following subtypes of Behavior are discussed elsewhere:
A BehaviorInstance represents an occurrence of a temporal flow of Actions.
BehaviorInstance is a subtype of ModelElement.
behaviors
The term behaviors refers to a relationship between a Type or a Collaboration and a number of Behaviors.
A Type or a Collaboration has behaviors associated with zero or more Behaviors. Conversely, a Behavior represents the behavior of at most one Type or Collaboration.
bind
The term bind refers to a stereotyped Dependency whose source is a Collaboration or an instantiated Type and whose target is another Collaboration or a template Type, respectively.
The source binds the target. If the source and target are both Types, for instance, the template parameters of the target are bound by Name to the template arguments of the source.
The attributes associated with a bind Dependency are as follows:
BooleanExpression
The term BooleanExpression refers to an Expression that resolves to a Boolean.
broadcast
The term broadcast refers to a stereotyped Constraint which specifies that a particular Message is not invoked in any specific order relative to other Messages.
CallEvent
The term CallEvent refers to an Event caused by an Operation.
characteristic
The term characteristic refers to a Relationship between an Element and a number of TaggedValues.
A TaggedValue is a characteristic of no more than one Element. Conversely, an Element may have characteristics described by zero or more TaggedValues.
Class
The term Class refers to a realization of a Type.
Class is a subtype of Type. The Type associated with a given Class acts as an interface to that Class and the Class's subtypes. A Class is connected with a Type by a refinement relationship. A Type may be realized by zero or more associated Classes and/or subtypes of that Class; a Class and/or the subtypes of that Class may be the realization of zero or more Types.
A Class may have an associated collection of Methods in the same way that a Type may have an associated collection of Operations. Since Operation is a subtype of Member, a Class is connected to a Method by a members relationship that is inherited from Member and Type.
Class is ultimately a subtype of Element. As such, a Class can participate in Dependencies, and a Class can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
Since Class is also ultimately a subtype of GeneralizableElement, a Class can participate in Generalizations as well.
The following subtypes of Class are discussed elsewhere:
classification
The term classification refers to a Relationship between a Stereotype and a set of Elements.
A Stereotype may provide a classification for zero or more Elements. Conversely, an Element may have a classification described by no more than one Stereotype.
client
The term client refers to a Type that uses an interface.
clusters
The term clusters refers to a Relationship between a Behavior and a number of Collaborations.
A Behavior provides clusters for zero or more Collaborations. Conversely, a Collaboration has clusters associated with no more than one Behavior.
A cluster represents a group of Instances and Links in the context of a particular Interaction.
Collaboration
The term Collaboration refers to a mechanism that consists of structural elements and behavioral elements associated with an "interesting" collection of Types.
A Collaboration can also represent any subtype of Type; this includes ActiveClass, Class, Component, Node, and UseCase.
A Collaboration represents a shared aggregation, which means that destroying a given Collaboration will not result in the destruction of its associated Elements.
Collaboration is a subtype of ModelElement.
Collaboration is ultimately a subtype of Element. As such, a Collaboration can participate in Dependencies, and a Collaboration can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
A Collaboration has an associated non-null Name.
The attributes associated with Collaboration are as follows:
A Collaboration has zero or more Values associated with it as collaboration arguments. Conversely, a Value is the collaboration argument for at most one Collaboration.
Each Value that serves as a collaboration argument for a given Collaboration matches up with a Parameter associated with that Collaboration.
CollaborationDiagram
The term CollaborationDiagram refers to a Diagram that encompasses Instances and their Relationships, organized by space.
collaboration parameter
The term collaboration parameter refers to a relationship between a template Collaboration and a number of Parameters.
A Collaboration has zero or more Parameters associated with it as collaboration parameters. Conversely, a Parameter is the collaboration parameter for at most one Collaboration.
complete
The term complete refers to a Constraint that specifies, for a given set of Generalizations, that all subtypes have been specified.
Component
The term Component refers to a reusable part that provides physical packaging for one or more (conceptual) ModelElements.
Component is a subtype of Class. As such, a Component may be connected with a Type by a refinement relationship. The Type associated with a given Component acts as an interface to that Component.
Component is ultimately a subtype of Element. As such, a Component can participate in Dependencies, and a Component can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
Since Component is also ultimately a subtype of GeneralizableElement, a Component can participate in Generalizations as well.
ComponentDiagram
The term ComponentDiagram refers to a Diagram that encompasses Components and their Relationships.
composite
The term composite, in conjunction with the term aggregation, refers to an AssociationRole for which the value of the multiplicity attribute is less than or equal to 1 and the value of the isChangeable attribute is True.
CompositeState
The term CompositeState refers to a State that contains substates.
A CompositeState has an associated non-null Name.
The attributes associated with CompositeState are as follows:
Constraint is a subtype of ModelElement.
The attributes associated with Constraint are as follows:
Constraint is one of three mechanisms that a modeler can use to extend the classes within the UML meta-model in controlled ways. (The other two are Stereotype and TaggedValue.) In plain terms, this means that an Element E, which has an attached Constraint C, is semantically equivalent to a new meta-model class whose association
constraint
The term constraint refers to a stereotyped Note that states a constraint.
constraints
The term constraints refers to a relationship between a Collaboration and a number of Constraints.
A Collaboration may be associated with zero or more Constraints via a constraints relationship. Conversely, a Constraint may be in a constraints relationship with zero or more Collaborations.
copy
The term copy refers to a stereotyped Dependency whose target (B) is an exact copy of its source (A). Future changes in A will not necessarily be reflected in B.
A System defines zero or more Stereotypes. Conversely, a Stereotype is defined by exactly one System.
Dependency
The term Dependency refers to a unidirectional Relationship from a source, consisting of one or more Elements, to a target, also consisting of one or more Elements.
A Dependency is connected to a System by a trace relationship. A Dependency traces from Element to Element. These Elements can belong to different Models within a given System.
A Dependency may have an associated non-null Name. All Dependency instances for which a given Element is a source or target must have unique names.
Since Dependency is ultimately a subtype of Element, a Dependency can be owned or referenced by a Package. A Dependency is owned by the smallest name space that contains both its source and target; this may be a single Package or a set of Packages. Also, a Dependency can participate in other Dependencies, and a Dependency can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
The attributes associated with Dependency are as follows:
The following types of Dependency are discussed elsewhere:
The source Element has a dependency on the target Element.
DeploymentDiagram
The term DeploymentDiagram refers to a Diagram that encompasses Components and Nodes and their Relationships.
deploys
The term deploys refers to a Relationship between a Node and a number of Components.
A Node may deploy zero or more Components. Conversely, a Component may be deployed by zero or more Nodes.
derived
The term derived refers to a stereotyped Dependency whose source and target are both Elements. These Elements are usually, but not always, of the same Type.
A derived Dependency specifies that the source is derived from the target--in other words, the source Element is not manifest.
Diagram
The term Diagram refers to a graphical projection of a set of ModelElements, most often rendered as a connected graph of arcs (which represent Relationships) and vertices (which represent the ModelElements).
A Diagram may cross any and all boundaries of the packaging and visibility associated with a Model. This implies the following:
Diagram is an abstract subtype of ViewElement.
The following subtypes of Diagram are discussed elsewhere:
discriminant
The term discriminant refers to the Name of a Generalization.
disjoint
The term disjoint refers to a Constraint that specifies, for a given set of Generalizations, that each of the associated GeneralizableElements can have only one subtype as its Type. This is the default for a Generalization.
document
The term document refers to a stereotyped Component that represents a document.
documentation
The term documentation refers to a TaggedValue that represents a comment, description, or explanation associated with an Element.
Documentation takes the form of a String.
An ActionExpression represents an effect of no more than one Transition. Conversely, a Transition has an associated effect represented by one ActionExpression.
A Transition does not have to have an associated effect.
Element
The term Element refers to an atomic constituent of a model.
Element serves as the abstract base class for most constituents of the UML.
An Element has an associated Name. This Name uniquely names the given Element in the context of the name space that encloses that Element. The default Name for an Element is the null Name.
An Element is connected to a Package by an owns relationship. An Element may be connected to a Package by a references relationship.
Each Element is unique, even if two or more Elements have the same associated Name. Also:
The following subtypes of Element are discussed elsewhere:
Implementations are free to extend any of the enumerations that are defined as part of the UML.
Event
The term Event refers to a significant, unique occurrence in space and time.
Event is an abstract subtype of ModelElement.
The following subtypes of Event are discussed elsewhere:
Expression is an abstract Class. Every Expression evaluates to some Value expressed by a subtype of Expression. This Expression may include items that have Names, but the Expression itself does not have an associated Name.
The following subtypes of Expression are discussed elsewhere:
The behavior of the source UseCase or Type extends that of the target UseCase or Type.
extension points
The term extension points refers to a relationship between a Type and a number of Names.
A Type has extension points associated with zero or more Names. Conversely, a Name represents the extension points of at most one Type. An extension point is simply a label in a sequence of Operations associated with a given Type or UseCase that identifies a place that another Type or UseCase can extend. (UseCase is a subtype of Type.)
The Names associated with a given Type must each be unique.
file
The term file refers to a stereotyped Component that represents a document which contains source code.
FormalParameter
The term FormalParameter refers to an association class that defines a connection between an Operation and a number of Parameters.
The attributes associated with FormalParameter are as follows:
An Operation has formal parameters represented by zero or more Parameters. Conversely, a Parameter represents the formal parameter of exactly one Operation.
framework
The term framework refers to a Package that consists mainly of patterns.
friend
The term friend refers to a stereotyped Dependency whose source is a Package and whose target is a different Package.
A friend extends the Visibility associated with the contents of the source Package to the target Package, via an implicit or explicit import of those contents.
GeneralizableElement is an abstract Class.
The attributes associated with GeneralizableElement are as follows:
An Generalization has an associated non-null Name, which is referred to as that Generalization's discriminant. For a given GeneralizableElement serving as a supertype, there may be more than one associated Generalization with the same discriminant. This means that all of the given subtypes are partitioned into one set, with the given Name.
The default semantics of a Generalization are disjoint (as opposed to overlapping) and incomplete.
generalization
The term generalization refers to a Relationship between a Generalization and its associated GeneralizableElements.
The GeneralizableElement that serves as the supertype within a given Generalization generalizes the GeneralizableElement that serves as the subtype.
global
The term global refers to a stereotyped Constraint which specifies that the Instance corresponding with a given LinkRole is visible because it is in a global scope.
A Component may implement zero or more ModelElements. Conversely, a ModelElement may be implemented by zero or more Components.
implicit
The term implicit refers to a Constraint that specifies that a given Association is conceptual (in other words, it is never instantiated).
import
The term import refers to a stereotyped Dependencywhose source is a Package and whose target is a different Package.
A source Package that imports the contents of a target Package can reference the contents of that Package which have public Visibility.
incomplete
The term incomplete refers to a Constraint that specifies, for a given set of Generalizations, that more subtypes can be specified. This is the default for a Generalization.
inheritance
The term inheritance refers to a Generalization.
Instance
The term Instance refers to a concrete manifestation of a Type. An Instance represents an entity that exists in space and time.
Instance is a subtype of ModelElement.
An Instance may have an associated non-null Name. Whether or not a given Instance is named, though, its associated Values, Actions, state instance, and roles must each have a unique Name.
Instance is ultimately a subtype of Element. As such, an Instance can participate in Dependencies, and an Instance can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
The attributes associated with Instance are as follows:
instance of (1)
The term instance of refers to a Relationship between an Instance and a Type.
An Instance is an instance of (that is, a concrete manifestation of) not more than one Type. (This is usually exactly one. However, an Instance can exist without an associated Type; this is generally relevant with regard to incomplete or evolving Models.) Conversely, a Type may have zero or more associated Instances.
instance of (2)
The term instance of also refers to a Relationship between a Behavior and a number of BehaviorInstances.
A BehaviorInstance is an instance of (that is, a concrete manifestation of) not more than one Behavior. (This is usually exactly one.) Conversely, a Behavior may have zero or more associated BehaviorInstances.
instances (1)
The term instances refers to a Relationship between a Collaboration and a number of Instances.
A Collaboration is associated with zero or more Instances via an instances relationship. Conversely, an Instance is in an instances relationship with zero or more Collaborations.
instances (2)
The term instances also refers to a Relationship between an Interaction and a number of Instances.
An Interaction is associated with zero or more Instances via an instances relationship. Conversely, an Instance is in an instances relationship with at most one Interaction.
Instances contained within the same Interaction, that have the same Name, are considered to represent the same instances. However, these Instances may have different associated Values, Actions, State, and rolesroles.
Interaction
The term Interaction refers to a Behavior of a Collaboration composed of a number of Instances and Links.
An Interaction has an associated non-null Name.
Execution of an Interaction begins with all Messages whose sequence is 1 for each independent thread. (A Message is activated as the result of the evaluation of an Action.) Execution proceeds to the next sequentially numbered Message, except that:
interface
The term interface refers to a stereotyped Type that represents a refinement of that Type by a Class.
internal transition
The term internal transition refers to a Relationship between a State and a number of Transitions.
An internal transition represents a Transition whose source and target are the same State, but with triggering that does not result in a leaving of that State. An internal transition has an associated guard attribute just like any other Transition.
A State has zero or more internal transitions represented by Transitions. Conversely, a Transition represents the internal transition of no more than one State.
There are three predefined internal transactions within the UML:
An invariant takes the form of an Uninterpreted value.
invocation
The term invocation refers to a Relationship between an Operation or a Signal and a number of Actions.
An Operation or a Signal may have zero or more associated Actions that represent the invocations of that Operation or Signal. Conversely, an Action may be the invocation of no more than one Operation or Signal.
Link
The term Link refers to a Relationship between Instances across which Messages may be sent.
A Link represents an instance of an Association.
Link is ultimately a subtype of Element. As such, a Link can participate in Dependencies, and a Link can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
A Link may have an associated Name; this is usually the null Name.
The attributes associated with Link are as follows:
An Association may be represented by zero or more associated Links via link instances. Conversely, a Link may be the link instance of no more than one Association.
LinkRole
The term LinkRole refers to the "face" that an Instance presents to a Link.
A LinkRole represents an instance of an AssociationRole.
LinkRole is a subtype of ModelElement.
LinkRole is ultimately a subtype of Element. As such, a LinkRole can participate in Dependencies, and a LinkRole can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
A LinkRole may have an associated Name; this is usually the null Name.
link roles
The term link roles refers to a Relationship between a Link and a number of LinkRoles.
A Link has two or more LinkRoles as its link roles. Conversely, a LinkRole is the link role of exactly one Link.
The link roles associated with a given Link are ordered in the same way as the Associations for that Link.
The link roles relationship is ordered. The Instance associated with the first LinkRole within a given Link is the implicit sender of any Message attached to that LinkRole.
links
The term links refers to a Relationship between an Interaction and a number of Links.
An Interaction has zero or more Links as its links. Conversely, a Link is a link for exactly one Interaction. These links connect the Instances associated with a given Interaction.
List
The term List refers to a container that contains Elements which are ordered and can be indexed.
The operations that can be applied to a List are outside of the scope of the UML.
local
The term local refers to a stereotyped Constraint which specifies that the Instance corresponding with a given LinkRole is visible because it is a local variable of an Operation.
location
The term location refers to a TaggedValue that specifies a value derived from the implementation of a ModelElement by a set of Components or of a Component by a set of Nodes.
Member is an abstract subclass of ModelElement.
Member is ultimately a subtype of Element. As such, a Member can participate in Dependencies, and a Member can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it. It is common to use Stereotypes to categorize different kinds of Members associated with a given Type.
The following subtypes of Member are discussed elsewhere:
The attributes associated with Members are as follows:
A Type has members represented by zero or more Member instances. Conversely, a Member is a member of exactly one Type.
Message
The term Message refers to the sending of an Action.
Message is a subtype of ModelElement.
Message is ultimately a subtype of Element. As such, a Message can participate in Dependencies, and a Message can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
A Message may have an associated Name; this is usually the null Name. A non-null Name of a Message can be used within a Constraint to specify a time constraint.
The attributes associated with Message are as follows:
The syntax for a conditional recurrence attribute is [condition_clause], where condition_clause is a clause expressed in pseudocode or a programming language that represents a predicate upon which execution of the given Message is contingent.
The syntax for an iterative recurrence attribute is *[iteration_clause], where iteration_clause is a clause expressed in pseudocode or a programming language that represents a repeat of the execution of the given Message at the given nesting depth.
The default value of the recurrence attribute is the null String.
The syntax of the sequence attribute is one or more numbers, with . appearing between each number.
The default value of this attribute is the null String.
The syntax of the synchronizationPoint attribute can be expressed in two parts.
A LinkRole has zero or more Messages as its messages. Conversely, a Message is a message for exactly one LinkRole.
metaclass (1)
The term metaclass refers to a stereotyped Dependency whose source is a Type and whose target is another metaclass.
The target metaclass serves as the source Type's metaclass.
metaclass (2)
The term metaclass also refers to a stereotyped Type that serves as the Type of a given Type.
Method
The term Method refers to an elementary quantum of work that provides a realization of a given Operation.
Method is a subtype of Operation. A Method is connected with an Operation by a refinement relationship. Since Operation is a subtype of Member, and Class is a subtype of Type, a Class is connected to a Method by a members relationship that is inherited from Member and Type.
Method is ultimately a subtype of Element. As such, a Method can participate in Dependencies, and a Method can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it. It is common to use Dependencies to connect Methods to associated code.
The attributes associated with Method are as follows:
The responsibility of a Model is to provide a structure that holds an "interesting" collection of Elements, where "interesting" is in the eye of the project stakeholder reviewing the given Model. One fundamental idea of a Model is that its Elements can be understood fairly easily within the context of the Model.
Model is a subtype of Element. As such, a Model can participate in Dependencies, and a Model can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
A Model is connected with a System by an abstraction relationship. A Model is connected with a Package by a represents relationship.
A Model may have an associated Name. The default Name is the null Name.
The attributes associated with Model are as follows:
ModelElement is an abstract subtype of Element. As such, a ModelElement can participate in Dependencies, and a ModelElement can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
A ModelElement may be connected with a ViewElement by a projection relationship.
The following subtypes of ModelElement are discussed elsewhere:
The syntax of Multiplicity can be expressed in three parts.
The basic form of Name is a String referred to as a simple name. A name can also take two other forms:
name
The term name refers to a Relationship between a Name and an Element.
A Name names zero or one Elements. Conversely, an Element is named by zero or one Names.
Nested
The term Nested refers to an association class that defines one type of connection that might exist between a Type and a number of other Types.
The attributes associated with Nested are as follows:
A Type is nested within no more than one other Type. Conversely, a Type has zero or more nested Types.
A nested Type may itself have nested Types. On the same level of nesting, each Type must have a Name that is unique within that level.
Node
The term Node refers to a physical object that represents a computation resource upon which Components may be deployed. This resource generally has memory; it may have processing capability as well.
Node is a subtype of Class. As such, a Node may be connected with a Type by a refinement relationship. The Type associated with a given Node acts as an interface to that Node.
Node is ultimately a subtype of Element. As such, a Node can participate in Dependencies, and a Node can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
Since Node is also ultimately a subtype of GeneralizableElement, a Node can participate in Generalizations as well.
Note
The term Note refers to a comment attached to one or more Elements.
Note is a subtype of ModelElement.
The attributes associated with Note are as follows:
A Note may be used to project any property of a Model, such as a TaggedValue or a Constraint attached to a particular ModelElement.
notes
The term notes refers to a Relationship between a Collaboration and a number of Notes.
A Collaboration may be associated with zero or more Notes via a notes relationship. Conversely, a Note may be in a notes relationship with zero or more Collaborations.
ObjectDiagram
The term ObjectDiagram refers to a Diagram that encompasses Instances and their Relationships.
occurrence
The term occurrence refers to a Relationship between a CallEvent and an Operation, a SignalEvent and a Signal, or a TimeEvent and a TimeExpression.
An Operation/Signal/TimeExpression may have zero or more associated CallEvents/SignalEvents/TimeEvents that represent the occurrences of that Operation/Signal/TimeExpression. Conversely, a CallEvent/SignalEvent/TimeEvent may be the occurrence of no more than one Operation/Signal/TimeExpression.
Operation
The term Operation refers to the public "face" that a unit of work presents to the world, as a behavioral feature of a particular Type.
Operation is a subtype of Member.
Operation is ultimately a subtype of Element. As such, an Operation can participate in Dependencies, and an Operation can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it. It is common to use a refinement Dependency to connect an Operation to an associated Method.
An Operation has an associated non-null Name. More than one Operation associated with a given Type may have the same Name, as long as the parameters of each Operation are distinct.
The attributes associated with Operation are as follows:
Different Operations that are members of the same Type can have different concurrency semantics.
The default value of the concurrency attribute is sequential.
ordered
The term ordered refers to a Constraint that specifies that the order of participants within a given AssociationRole is semantically important.
overlapping
The term overlapping refers to a Constraint that specifies, for a given set of Generalizations, that each of the associated Instances can have more than one subtype as its Type.
Owns
The term Owns refers to an association class that defines one type of connection that might exist between a Package and a number of Elements.
The attributes associated with Owns are as follows:
owns
The term owns refers to a Relationship between a Package and a number of Elements.
A Package owns zero or more Elements. Conversely, every Element is owned by no more than one Package.
A Package may own other Packages.
The Elements that a package owns and references are together referred to as that Package's contents. Within the context of a Package, each Element of a given kind must have an associated Name or alias (see References) that is unique among Elements of that kind.
In general, a Package may only own or reference certain kinds of Elements, including Type, Relationship, Behavior, and Collaboration. (A Package may also own or reference an Element that serves as a subtype to any of these kinds of Elements.)
Package is a subtype of ModelElement. Like ModelElement, Package is conceptual: a Package partitions Elements in the context of a Model, but this partitioning disappears in the context of an executable system. A Package is connected with a Model by a represents relationship.
Since ModelElement is a subtype of Element, a Package can participate in Dependencies. The only meaningful Dependencies that might involve Packages are friend, import, and trace.
Package is also a subtype of GeneralizableElement. As such, a Package can participate in Generalizations, including one in which a Package is a subtype of another Package. However, if a given Package's isAbstract attribute (inherited from GeneralizableElement) is True, that Package must be refined by a concrete Package serving as a subtype.
A Package may own or reference other Packages. Within a given model, only one Element is not owned by a Package: the topmost Package represented by a Model.
In the context of a Package, an Element that is visible is one to which implicit and explicit Relationships may be established. The public contents of a Package (see Visibility) instance are visible to any Element directly outside that Package. However, a Package creates a wall around its contents, which makes an item outside the Package invisible to the contents of the Package unless the Package implicitly or explicitly imports that item.
The nesting of one Package within another establishes an implicit import of the contents of the nested Package by the outer Package. This means that visibility is transitive. For example, consider the following four Packages:
Parameter
The term Parameter refers to an unbound expression.
Parameter is a subtype of ModelElement.
A Parameter has an associated non-null Name.
The attributes associated with Parameter are as follows:
participates
The term participates refers to a Relationship between a Type and a number of AssociationRoles.
A Type participates in zero or more Associations via AssociationRoles. Conversely, an AssociationRole has exactly one participating Type.
pattern
The term pattern refers to a template Collaboration.
persistence
The term persistence refers to a TaggedValue that represents an enumeration whose values (transitory and persistent) describe the possible impact on the State of a Type, an Instance, or an Attribute when that Type, Instance, or Attribute is destroyed.
The State of a transitory Type, Instance, or Attribute is destroyed; the State of a persistent Type, Instance, or Attribute is not destroyed. The default is transitory.
The following rules apply:
An Instance may be a player within zero or more LinkRoles. Conversely, a LinkRole has exactly one Instance as its player.
The Type of the Instance involved in a player relationship must match the Type associated with the AssociationRole connected with each given LinkRole.
Point
The term Point refers to an (x,y,z) tuple that uniquely identifies a position in space.
A Point generally names the position within a given Diagram where a given ModelElement is projected. The point (0,0,0) refers to the upper lefthand corner of a Diagram.
The values of x, y, and z must all be non-negative numbers.
A Point can be expressed as an (x,y) tuple, with z assumed to be 0.
postcondition
The term postcondition refers to a TaggedValue that represents one or more properties which must be True after the completion of a given Operation.
A postcondition takes the form of an Uninterpreted value.
powertype (1)
The term powertype refers to a Relationship between a Type and a Generalization.
A Type may be the powertype of no more than one Generalization. Conversely, a Generalization may have no more than one Type as its powertype.
powertype (2)
The term powertype also refers to a stereotyped Dependency or stereotyped Type.
Within a powertype Dependency, the source is a Generalization, and the target is the Type that serves as that Generalization's powertype. A powertype Type represents the powertype of a given Generalization.
precondition
The term precondition refers to a TaggedValue that represents one or more properties which must be True before a given Operation is invoked.
A precondition takes the form of an Uninterpreted value.
PrimitiveType
The term PrimitiveType refers to a Type (for instance, Integer) that is not realized by a Classwithin the UML meta-model.
PrimitiveType is an abstract subtype of Type. An implementation must provide at least one concrete subclass of PrimitiveType.
PrimitiveType is ultimately a subtype of Element. As such, a PrimitiveType can participate in Dependencies, and a PrimitiveType can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
The attributes associated with PrimitiveType are as follows:
Projection
The term Projection refers to an association class that defines a connection between a ViewElement and a number of ModelElements.
The attributes associated with Projection are as follows:
A ViewElement may be the projection of one or more ModelElements. Conversely, a ModelElement may be projected into zero or more ViewElements.
property
The term property refers to a part of an Element.
Pseudostate
The term Pseudostate refers to a StateVertex that has the form of a State, but does not behave like a State.
Pseudostate is a subtype of StateVertex.
The attributes associated with Pseudostate are as follows:
The default value of the kind attribute is initial.
A LinkRole has zero or more Values that serve as its qualifications. Conversely, a Value is a qualification for no more than one LinkRole.
Each Value corresponds with an Attribute associated with an AssociationRole connected to the given LinkRole.
qualifier
The term qualifier refers to a Relationship between an Attribute and an AssociationRole.
An Attribute qualifies no more than one AssociationRole by specifying a specific Type (via its type attribute) associated with that Association Role. (So, for an AssociationRole whose multiplicity attribute contains a value greater than one, a given Attribute can be used to designate a specific instance of the given Type.) Conversely, an Association Role may be qualified by zero or more Attributes.
The attributes associated with References are as follows:
references (1)
The term references refers to a Relationship between a Package and a number of Elements.
A Package optionally references zero or more Elements. Conversely, every Element may be referenced by zero or more Packages.
A Package may reference other Packages.
A referenced Element is visible within a Package that imports it, and may be used just as if that Package owns it.
references (2)
The term references also refers to a Relationship between a TypeExpression and a number of Types.
A TypeExpression references one or more Types. Conversely, a Type may be referenced by zero or more TypeExpressions.
Note that references is an implicit relationship, in that the value of the referencedType attribute within the given TypeExpression identifies the given Type.
references (3)
The term references also refers to a Relationship between an ActionExpression and a number of Actions.
An ActionExpression can reference zero or more Actions. Conversely, an Action can be referenced by zero or more ActionExpressions.
Note that references is an implicit relationship, in that the value of the referencedActions attribute within the given ActionExpression identifies the given Actions.
refinement
The term refinement refers to a stereotyped Dependency whose source maps to its target with additional information that "refines" the target. This generally involves providing a realization of the target.
The attributes associated with a refinement Dependency are as follows:
Relationship is an abstract subtype of ModelElement.
The Names associated with the Relationships connected to a given Element must each be unique. (These Names are attached to subtypes of Relationship.)
If the next-to-last Element connected to a given Relationship is destroyed, that Relationship is also destroyed, because a "dangling" Relationship is not allowed.
The following subtypes of Relationship are discussed elsewhere:
A Collaboration may be associated with zero or more Relationships via a relationships relationship. Conversely, a Relationship may be in a relationships relationship with zero or more Collaborations.
represents (1)
The term represents refers to a Relationship between a Package and a Model.
A Package represents no more than one Model. Conversely, a Model is represented by one or more Packages. (Typically, a Model is represented by a single topmost Package.)
represents (2)
The term represents also refers to a Relationship between a Collaboration and a Type or an Operation.
Each Collaboration represents at most one Type or Operation. Conversely, a Type or Operation may be represented by zero or more Collaborations.
requirement
The term requirement refers to a stereotyped Note that states a responsibility or obligation.
Responsibility
The term Responsibility refers to a TaggedValue that represents a contract by, or obligation of, a Type.
A Responsibility is connected with a Type by a characteristic relationship (inherited from TaggedValue).
It is possible to connect a Responsibility to one or Member instances, by introducing a traceDependency.
A Responsibility takes the form of a String.
Responsibility is ultimately a subtype of Element. As such, a Responsibility can participate in Dependencies, and a Responsibility can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
The attributes associated with Responsibility are as follows:
A Type may play a role in zero or more AssociationRoles. Conversely, an Association Role may have no more than one Type playing its role.
role (2)
The term role also refers to a stereotyped Dependency whose source is a Type and whose target is an AssociationRole.
role instance
The term role instance refers to a Relationship between an AssociationRole and a number of LinkRoles.
An AssociationRole has zero or more LinkRoles as its role instances. Conversely, a LinkRole is a role instance for no more than one AssociationRole.
roles
The term roles refers to the "faces" that an Instance presents to clients at a given moment in space and time.
An Instance can play zero or more roles relative to a Type. Conversely, a Type can be associated with an Instance playing zero or more roles.
The roles associated with a given Type come from the refinements associated with that Type.
self
The term self refers to a stereotyped Constraint which specifies that the Instance corresponding with a given LinkRole is visible because it is the dispatcher, or part of the dispatcher, of a Message.
semantics
The term semantics refers to a TaggedValue that specifies the meaning of a given Type or Operation.
A semantics instance takes the form of an Uninterpreted value.
send
The term send refers to a stereotyped Dependency whose source is an Operation that sends a target Signal.
SequenceDiagram
The term SequenceDiagram refers to a Diagram that encompasses Instances and their Relationships, organized by time.
shared
The term shared, in conjunction with the term aggregation, refers to an AssociationRole for which the value of the multiplicity attribute is greater than 1.
Signal
The term Signal refers to a stereotyped Class that represents a named Event which represents a significant occurrence in time and space.
As a subtype of Class, a Signal can have associated Member instances. These are generally Attributes that basically act as the formal parameters of the Signal, which may be matched to actual arguments associated with a given Action.
Signal is ultimately a subtype of Element. As such, a Signal can participate in Dependencies, and a Signal can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
Since Signal is also ultimately a subtype of GeneralizableElement, a Signal can participate in Generalizations as well. It is common to define hierarchies of Signals.
SignalEvent
The term SignalEvent refers to an Event triggered by a Signal.
Signals
The term Signals refers to an association class that defines a connection between a Type and a number of Signal instances.
The attributes associated with Signals are as follows:
A Type may have signals associated with zero or more Signal instances. Conversely, a Signal may represent the signals for zero or more Types.
signature
The term signature refers to a concatenation of a Name and a collection of Parameters that forms a "behaviorless interface" of a given Operation.
simple name
The term simple name refers to the basic form of a Name.
source
The term source refers to a Relationship between a StateVertex and a number of Transitions.
A StateVertex is the source of zero or more Transitions. Conversely, a Transition has sources associated with one or more StateVertexes. (A Transition that has multiple sources must have only one target.)
space semantics
The term space semantics refers to a TaggedValue that specifies the "space complexity" of a given Type or Operation.
A space semantics instance takes the form of an Uninterpreted value.
State
The term State refers to a condition of an Instance at a particular moment in space and time.
State is a subtype of StateVertex.
A State has an associated non-null Name.
State is ultimately a subtype of Element. As such, a State can participate in Dependencies, and a State can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
The following subtypes of State are discussed elsewhere:
StateDiagram
The term StateDiagram refers to a Diagram that encompasses States and their Relationships, organized by State, and is used to show the overall Behavior of a Type.
A StateDiagram reflects StateMachines.
state instance
The term state instance refers to a Relationship between a State and a number of Instances.
A State may represent the state instance associated with zero or more Instances. Conversely, an Instance may have a state instance associated with no more than one State at a given moment in space and time.
The State of a given Instance must correspond with one of the possible States of the Type associated with that Instance.
StateMachine
The term StateMachine refers to the behavior of a Collaboration, specified as a collection of Actions carried out over a sequence of State changes.
StateMachine is a subtype of Behavior.
A StateMachine has an associated non-null Name.
None of the parts of a StateMachine are visible outside of the StateMachine. However, all of the parts are visible to each other within the StateMachine.
The execution of a StateMachine, which is not interruptible, represents its dynamic behavior. At any given time, a StateMachine can react to exactly one Event. When this happens, execution of the StateMachine proceeds until it reaches a stable State; at that point, it may wait for another Event to occur or react to an Event that has been queued.
Execution begins with the initial Pseudostate within the given StateMachine. This Pseudostate must be the sole source of a Transition that has no trigger (in other words, an unconditional Transition). Execution proceeds with the evaluation of the Transition's effect, if it has one. (It is possible for an initial Pseudostate to be the source of multiple Transitions, where none of these have triggers but some of them may have guards. The semantics involved in choosing among Transitions are described below.)
Evaluation of an effect involves evaluating every Action that is referenced by the associated ActionExpression in the order in which these Actions appear within the ActionExpression's referencedActions attribute. Evaluating an Action involves invoking the associated Signal or Operation to act upon the appropriate target Instance. (If a given Action invokes an Operation, the actual arguments associated with that Action are involved.) As with the execution of a StateMachine as a whole, the evaluation of an effect is not interruptible; this means that any Events that may occur while an effect evaluation is in progress are queued awaiting response.
Once an effect has been evaluated, StateMachine execution proceeds to the target StateVertexes associated with the given Transition. There are three possibilities at this point.
Execution of the StateMachine proceeds with entry into the given State or ActionState.
If there is an associated entry internal transition, its guard is evaluated. If this guard evaluates to True, the effect of the entry Transition is evaluated.
Once evaluation is complete, the StateMachine is in the given State, and execution waits until conditions arise that cause a State Transition. At this point, if there is a do internal Transition, the associated Action is begun.
Execution of the StateMachine proceeds with entry into the given CompositeState.
If there is an associated entry internal transition, its guard is evaluated. If this guard evaluates to True, the effect of the entry Transition is evaluated.
Once evaluation is complete, the StateMachine is in the given State. At this point, if there is a do internal transition, the associated Action is begun.
Execution of the StateMachine proceeds to the initial Pseudostate belonging to the given CompositeState. As described previously, this Pseudostate must be the sole source of a Transition that has no trigger. Execution then proceeds with the evaluation of the associated Transition's effect, if it has one. Now, the StateMachine is in both the given CompositeState and a substate; execution waits until conditions arise that cause a State Transition.
Each target represents a State, with all but one of them representing concurrent CompositeStates.
Execution of the StateMachine proceeds with entry into all of the concurrent CompositeStates. This results in concurrent flows of execution.
The guard of the trigger-less (unconditional) Transition is evaluated once. If this guard evaluates to False, execution of the StateMachine awaits the next Event.
If the guard evaluates to True, execution of the StateMachine proceeds with exit from the current State.
If there is an associated exit internal transition, its guard is evaluated. If this guard evaluates to True, the effect of the exit Transition is evaluated.
Once evaluation is complete, execution of the StateMachine proceeds with an evaluation of the effect of the only triggerless Transition, if there is one.
The guards of each of the trigger-less (unconditional) Transitions are evaluated once. (The order of evaluation is implementation-dependent.) There are three possibilities.
The StateMachine waits in the current State for an Event. Once an Event arrives, execution continues with evaluation of all Transitions for which the given State is a source and whose associated trigger is the given Event. There are three possibilities.
The Event is ignored; the StateMachine remains in its current State.
The guard of this Transition is evaluated once. If this guard evaluates to False, the Event is ignored, and the StateMachine remains in its current State. If the guard evaluates to True, execution of the StateMachine proceeds according to the associated Transition. (See the first bulleted item in this list for the semantics.)
The guards of each triggered Transition are evaluated once. (The order of evaluation is implementation-dependent.) If exactly one of these guards evaluates to True, execution of the StateMachine proceeds according to the associated Transition. (See the first bulleted item in this list for the semantics.) If more than one of the guards evaluates to True, execution of the StateMachine proceeds according to one of the associated Transitions (this is also implementation-dependent). (See the first bulleted item in this list for the semantics.)
There are other elements of StateMachine execution if a given State is a substate of a CompositeState, or if the State is itself a Composite State.
If execution of a StateMachine proceeds with a Transition from a given State to a substate of that State, then entry internal transitions are evaluated for each of the associated superstates, in order of nesting.
There are two final considerations.
A State may have state variables associated with zero or more Attributes. Conversely, an Attribute may be a state variable associated with no more than one State.
Each state variable has a particular scope within its enclosing State.
StateVertex
The term StateVertex refers to a source or a target of a Transition.
StateVertex is an abstract subtype of ModelElement.
The following subtypes of StateVertex are discussed elsewhere:
Stereotype is a subtype of ModelElement. Since ModelElement is a subtype of Element, a Stereotype can participate in Dependencies, and a Stereotype can also have other Stereotypes, TaggedValues, Notes, and Constraints attached to it.
Stereotype is also a subtype of GeneralizableElement. As such, if the value of the isAbstract attribute (inherited from GeneralizableElement) is True for a given Stereotype, that Stereotype cannot classify any Elements.
A Stereotype has an associated non-null Name.
A Stereotype is connected to a System by a define relationship. The Stereotype's Name must be unique within that System.
The attributes associated with Stereotype are as follows:
A number of Stereotypes are predefined within the UML; the user can define others. The following named Stereotypes are discussed elsewhere:
stub
The term stub refers to a stereotyped Package that has been incompletely transferred.
subclass
The term subclass refers to a stereotyped Generalization in which a subtype inherits the structure and behavior of a supertype, but the subtype is not associated with the same Type as the supertype.
subordinate
The term subordinate refers to a Relationship between two Systems.
A System may have zero or more subordinate Systems. Conversely, a System may be subordinate to no more than one other System.
A System that is subordinate to another System may be referred to as a subsystem.
substate
The term substate refers to a Relationship between a CompositeState and a number of StateVertexes that are not immediate vertices of a StateMachine.
A CompositeState has one or more StateVertexes as its substates. Conversely, a StateVertex is a substate of exactly one CompositeState.
subtype
The term subtype refers to a stereotyped Generalization in which a subtype inherits the structure and behavior of a supertype, and both subtype and supertype are associated with the same Type.
supplier
The term supplier refers to a Type or Class that refines an interface.
System
The term System refers to a collection of connected units that have been organized to accomplish a specific purpose.
System is a subtype of Element. As such, a System can participate in Dependencies, and a System can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
A System has three basic responsibilities:
TaggedValue
The term TaggedValue refers to a characteristic of an Element.
TaggedValue is a subtype of ModelElement. Since ModelElement is a subtype of Element, a TaggedValue can participate in Dependencies, and a Stereotype can also have Stereotypes, other TaggedValues, Notes, and Constraints attached to it.
A TaggedValue has an associated non-null Name. All TaggedValues associated with a given Element must have unique Names.
The attributes associated with TaggedValue are as follows:
The following subtypes of TaggedValue are discussed elsewhere:
A number of TaggedValues are predefined within the UML; the user can define others. The following named TaggedValues are discussed elsewhere:
Every TaggedValue is either directly associated with a particular Element or is a member of a tagset. A TaggedValue can define a tagset; a member of a tagset can define another tagset.
Each TaggedValue within a tagset must have a unique Name.
target (1)
The term target refers to a Relationship between a StateVertex and a number of Transitions.
A StateVertex is the target of zero or more Transitions. Conversely, a Transition has targets associated with one or more StateVertexes. (A Transition with multiple targets must have exactly one source.)
target (2)
The term target also refers to a Relationship between an Instance and a number of Actions.
An Instance may be the target of zero or more Signals or Operations represented by Actions. Conversely, a Signal or Operation, represented by an Action, may have a target associated with no more than one Instance.
template argument
The term template argument refers to a Relationship between a non-template Type, which instantiates a template Type, and a number of Values.
A Type has zero or more Values associated with it via template arguments. Conversely, a Value is the template argument for at most one Type.
Each Value that serves as a template argument for a given Type matches up with a Parameter associated with that Type.
template parameter
The term template parameter refers to a Relationship between a template Type and a number of Parameters.
A Type has zero or more Parameters associated with it via template parameters. Conversely, a Parameter is the template parameter for at most one Type.
thread (1)
The term thread refers to a stereotyped ActiveClass that represents a "lightweight" flow of control.
thread (2)
The term thread also refers to a Relationship between an Instance and a number of Messages.
An ActiveClass has threads associated with zero or more Messages. Conversely, a Message has a thread from no more than one ActiveClass.
The given Message is invoked in the context of the given thread. The given Instance is the thread's owner. The Name of that Instance is also the Name of the thread.
Time
The term Time refers to a String that represents an absolute or relative moment in time.
The syntax of a "well-formed" instance of Time is outside the scope of the UML.
TimeEvent
The term TimeEvent refers to an Event triggered by the passing of time.
TimeExpression
The term TimeExpression refers to an Expression that resolves to a Time. This Time may represent an Event that triggers a Transition.
time semantics
The term time semantics refers to a TaggedValue that specifies the "time complexity" of a given Type or Operation.
A time semantics instance takes the form of an Uninterpreted value.
trace (1)
The term trace refers to a Relationship between a System and a number of Dependencies.
A Dependency represents a trace of Elements associated with exactly one System. Conversely, a System has traces associated with zero or more Dependencies.
trace (2)
The term trace also refers to a stereotyped Dependency whose source is a ModelElement within one Model and whose target is a ModelElement within the same Model or a different Model.
A trace Dependency indicates that the source conceptually traces back to the target.
Note that the trace Dependency is the only kind of Relationship that can span Model boundaries.
transaction
The term transaction refers to a Relationship between a Name and a number of Messages.
A Name may serve as the transaction for zero or more Messages. Conversely, a Message may have a transaction associated with no more than one Name.
A transaction collects a number of Messages into a group that can be treated as a Behavior that can be rolled back.
Transition
The term Transition refers to a passage from one StateVertex to another. This passage represents a change in State.
Transition is a subtype of Relationship.
Every Transition must have at least one source and one target. If a Transition's source or target is destroyed, that Transition is also destroyed, because a "dangling" Transition is not allowed.
A Transition may have an associated Name; this is usually the null Name. The Name of a given Transition must be unique across its sources and targets.
The Name of a Transition can be used within a Constraint to specify a time constraint associated with a given StateMachine. This Name can also be used within a TimeExpression.
The attributes associated with Transition are as follows:
A StateMachine contains the transitions associated with zero or more Transitions. Conversely, a Transition provides the transitions for exactly one StateMachine.
The given Transitions partially compose the contents of the given StateMachine.
trigger
The term trigger refers to a Relationship between an Event and a Transition.
An Event is the trigger for one Transition. Conversely, a Transition is triggered by exactly one Event. The trigger Event initiates a state change from the source(s) of the Transition to its target(s).
An unconditional Transition is one that does not have an associated trigger.
Type
The term Type refers to a specification of a particular domain and the behavior applicable to that domain.
Type is a subtype of ModelElement.
Type is also a subtype of GeneralizableElement. As such, a Type can participate in Generalizations, and a Type may be abstract (if its isAbstract attribute, inherited from GeneralizableElement, is True).
Type is ultimately a subtype of Element. As such, a Type can participate in Dependencies, and a Type can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
A Type has an associated non-null Name.
The attributes associated with Type are as follows:
The operations associated with TypeExpression are as follows:
A Collaboration may be associated with zero or more Types via a types relationship. Conversely, a Type may be in a types relationship with zero or more Collaborations.
The syntax of a "well-formed" instance of Uninterpreted is outside the scope of the UML.
An Uninterpreted instance is represented by a String.
UseCase
The term UseCase refers to a sequence of Actions that a System performs which yields an observable result of value to a particular actor.
A UseCase is connected with a BehaviorInstance by an actions relationship.
UseCase is a subtype of Type. As such, a UseCase can participate in Generalizations and Associations. This includes relationships with actors and other UseCases. However, UseCases cannot be nested.
If a UseCase is associated with a particular Package, the UseCase must conform with any UseCases that are present at lower levels within that Package. Note also that UseCases at lower levels may be traceable to UseCases at higher levels.
UseCaseDiagram
The term UseCaseDiagram refers to a Diagram that encompasses actors and UseCases and their Relationships.
uses
The term uses refers to a stereotyped Dependency whose source and target must both be UseCases.
Within a uses relationship, the behavior of the source UseCase includes that of the target UseCase.
utility
The term utility refers to a stereotyped Type that is a named collection of non-Member Attributes and/or Operations, each of which is type scoped.
A utility Type is abstract (i.e., not instantiated).
Value is a subtype of ModelElement.
Value is ultimately a subtype of Element. As such, a Value can participate in Dependencies, and a Value can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
The attributes associated with Value are as follows:
An Instance has values associated with zero or more Values. Conversely, every Value provides a value for no more than one Instance.
The number, Names, and types of values contained within a given Value must match the number, Names, and types of Attributes attached to the Type associated with the given Instance.
vertices
The term vertices refers to a Relationship between a StateMachine and a number of StateVertexes.
A StateMachine has vertices associated with zero or more StateVertexes. Conversely, a StateVertex is a vertex for exactly one StateMachine.
The given StateVertexes partially compose the contents of the given StateMachine. The Name of each StateVertex must be unique in the context of the enclosing StateMachine.
ViewElement
The term ViewElement refers to a human-readable textual and/or graphical representation of a number of ModelElements.
ViewElement is an abstract subtype of Element. As such, a ViewElement can participate in Dependencies, and a ViewElement can also have Stereotypes, TaggedValues, Notes, and Constraints attached to it.
A ViewElement may be connected to a ModelElement by a projection relationship.
The following subtypes of ViewElement are discussed elsewhere:
Implementations are free to add other subtypes.
Visibility
The term Visibility refers to an enumeration whose values describe how an Element may possibly be seen outside of its enclosing name space.
The UML has four predefined values of Visibility.
Implementations are free to add other Visibility values.
vote
The term vote refers to a stereotyped Constraint which specifies that for a set of return Messages, a particular return value is selected by majority vote of all return values.