335.概要（summarization）
目的在于过滤，合并和抽象元素集合的属性到它们的包容器上，以给出系统的一个更高级别，更抽象的视图。
见包(package)。
语义
包容器，例如包和类，可以具有继承来的属性和联系以总结它们的内容的属性和联系。这样就允许建模者能以一种更高级别而更少细节，因而也更为容易理解的水平上来更好的理解系统。例如，两个包之间的依赖表明在至少两个包里的一对元素之间存在依赖。概要比原始的信息有更少的细节。可能存在一对或者多对依赖，这些依赖由包级别的依赖所表示。在任何情况下，建模者知道对一个包的修改可能会影响其他的包。如果需要更多的细节，建模者一旦注意到高层的概要就可以仔细检查其内容。
相似的，两个类之间的依赖关系通常表示它们的操作之间的依赖，例如一个类里的方法调用另一个类里的操作（不是方法！）。很多类一级的依赖是从操作和属性之间的依赖得来。
通常，在包容器上总结的联系表示至少存在一个内容之间的联系。通常它们并不表示所有被包含的元素都参与联系。
336.超类（superclass）
泛化联系里的别的类的父亲--也就是说，更加普通的元素声明。孩子类被称为子类。父亲类被称为超类。
见泛化(generalization)。
语义
子类继承它的超类的结构、联系和行为，并且可以进行增加。
337.超类型（Supertype）
超类的同义名。更加中立的术语"父亲"可以用于任何可泛化的元素上。
见泛化(generalization)。
338.提供者（supplier）
提供可以被其他元素激发的服务的元素。对比：客户（client）。在表示法中，提供者出现在虚线依赖箭头的头部。
见依赖(dependency)。
339.泳道（ swimlane ）
为了对活动的职责进行组织而在活动图上进行的分块。泳道并没有一个固定的含义，但是它们经常对应于商业模型中的组织单元。
见活动图(activity graph)。
语义
活动图里的活动状态可以基于它们的表示法而被组织成各个部分，称为泳道。泳道是为组织活动图而由状态组成的分组。每个泳道代表特定含义的状态职责的部分--例如，负责工作流步骤的商业组织。建模者可以在任何适合的条件下使用它们。如果泳道存在，那它们就会划分状态图的各个状态。
每个泳道由一个与其他泳道不同的名称。在UML 里它没有额外的语义，但是它可以带有一些的现实世界的含义。
表示法
一个活动图通常可以被划分为泳道，每个泳道通过垂直实心线与它的邻居泳道相分离（图13-176）。
每个泳道代表整个活动的部分高级职责，而整个活动可能在最后由一个或者多个对象实现。泳道的相对次序在语义上没有重要意义，但是可能会表示现实世界里的某种关系。每个活动状态被赋到一个泳道上，并且在泳道里被代替。转换可能会穿过泳道；对转换路径的路由没有意义。
因为泳道是到任意目录的划分，所以如果几何上的区域安排不可行，那还可以通过别的方式实现。可以使用颜色或者简单的使用标签值来表明各个划分区域。
340.同步状态(synch state)
一个特殊的状态，它可以实现在一个状态机里的两个并发区域之间的控制同步。
见复杂转换(complex transition)、复合状态(composite state)、分叉(fork)、结合(join)、状态机(state machine)、转换(transition)。
语义
复合状态可能由几个并发区域组成，每个区域有自己的顺序状态区域。当进入一个并发复合状态时，每个并发区域都会活动。在每个并发区域里，都存在一个控制线程，每个区域独立于其他的区域（并发的含义）。但是，偶尔也会要求对并发区域之间的控制进行同步。一种方法是一个区域里的转换带有一个依赖于别的区域里的某个状态的监护条件。这种方法对于互斥，包括共享资源是有用的，但是它不能出现这样的情况：一个区域里的活动在别的区域里有影响后果。为了捕捉这种情况，可以使用同步状态。
同步状态是一个连接两个并发区域的特殊状态。区域可以是对等的--也就是说，两个属于相同的复合状态的并发区域--或者它们是嵌套在对等区域里的任何深度。但这两个区域不能顺序相连。
一个转换把一个区域里的一个分叉的输出连到同步状态的输入上，另外一个转换把同步状态的输出连到另外一个区域里的一个结合的输入上。换句话说，同步状态是一个缓冲区，间接的把一个区域里的分叉连到另一个区域里的一个结合上。分叉和结合都必须在各自的区域里有一个输入状态和输出状态。
第一个区域里的转换的激发被同步状态记住直到第二个区域里的结合转换激发。如果结合转换上的条件在同步状态变为活动之前被满足，那结合必须等到第一个区域里的转换被激发。换句话说，它代表第二个区域里的一个转换，该转换直到第一个区域里的转换激发后才能被激发。注意因为每个分叉和结合在自己的区域里必须有一个输入和输出，同步状态不会改变每个并发区域的基本的顺序行为，也不会改变形成复合状态的嵌套规则（除了 同步状态和它的弧不属于任何并发区域而属于它们的复合父状态）。
生产者--消费者问题是同步状态的一个典型实例。生产者激发一个激活同步状态的转换，消费者具有一个在激发前必须要求同步状态的转换。
如果到同步状态的输入转换是循环的一部分，那第一个区域可能超过第二个区域。换句话说，同步状态可能有多个环（使用 Petri 网的术语）。因此，不同于普通状态，同步状态代表了一个计数器或者队列（如果信息在区域之间流动就是后者--例如，同步状态是一个对象流状态）。缺省的，同步状态可以有无限多个环，但是建模者可以为同步状态可以带有的环的数目定义一个上界。如果同步状态的能力被超出，这就是一个运行时错误。大多数情况下，这个上界是无限或者1，后者代表一个简单的锁存器。为1的上界只有在可以保证不会发生超限的情况下被使用。这是建模者的责任。
如果封闭的复合状态退出时，在同步状态上存在环，那这些环就会被销毁。当进入复合状态时，同步状态都是空的。
可能存在多个进入同步状态的输入弧，但是它们必须来自相同顺序区域里的分叉。相似的，可以存在多个离开同步状态的输出弧而在顺序区域结合。因为每个区域都是顺序的，就不会存在多条弧的冲突危险。
同步状态可以是一个对象流状态。在这种情况下，它代表从一个区域传到另外一个区域的值构成的队列。
表示法
同步状态由一个小圆圈来表示,在圆圈里面标注单独的上界,是一个整数或者是一个星号(*)表示无限。从同步条(一个重条)符号到同步状态有一个转换箭头,还有一个从同步状态到另外一个区域里的同步条的转换箭头。如图13-77
同步状态最好画在两个区域的边界之间，但并不总是可以作到这样的（两个区域并不相邻），在任何情况下，连接的拓扑结构都没有二义性。
在一个活动图里，每个转换弧代表一个状态。因此，可以从分叉的输出画一个箭头到一个结合的输入，而不必显式的显示同步状态（但同步状态需要显示它的边界）。
举例
图13-178显示了购票情况的状态图。除了必须在选座之后才能计算款项并寄出外，购票和收钱并发进行。这种同步通过在 Pick Seats 和 Post Charges 之间插入一个同步状态来显示。在Pick seats 之后存在一个分叉，因为它后面有 Print tickets 和同步状态。Print tickets不必等待同步。在Post charges 前有一个结合，因为它必须等待Validate Counts 和同步状态。 当Print tickets 和 Post charges 都结束后，该复合状态就会结束，Mial tickets 就被执行。
该同步状态具有一个为1 的上界。不需要更大的上界，因为该复合状态的每次执行只存在一个同步。图13-179显示了定单填写处理过程的批处理形式。在这种变种里，很多定单离线填写。定单有一个服务器填写而收钱有另外一个服务器处理。在定单填写之前不能收钱，但是定单可以超过收钱而使同步状态有一个无限的上界。这是经典的生产者--消费者情况。
讨论
同步状态为生产者--消费者问题建模的能力提供最少花费，并且比普通的并发结构更有安全性，因为每个并发区域始终保持一个控制线程。因为并发父状态退出的时候会清空同步状态，所以不存在超限的危险（如果上界是无限的话）。但如果在包含分支的循环里使用同步状态，就存在挂起的危险：一个区域已经结束而另外的区域还在等待一个永远不会到达的同步环。如果每个状态都处在等待从对方发出的环的分支里，存在发生死锁的可能。在允许决定的并发系统里，没有办法完全避免这样的情况。即使没有同步状态，由于结束问题的存在，也不能保证终结。
341.同步活动（synchronous action）
发送对象停下来等待响应的一个请求；一个调用。对比：异步活动。
342.系统(system)
组织起来以完成一定目的的连接单元的集合。一个系统可以用一个或者多个模型描述，可能通过不同的视点。系统是"完整模型"。
语义
系统由一个高级子系统建模，该子系统间接包含共同完成整个现实世界目的模型元素构成的集合。
表示法
系统可以显示为一个带有构造型 system 的包。但是很少需要作为一个单元来显示一个系统。
343.标签(tag)
标签值对里的选择值。它代表在建模时定义的属性的名称。
344.标签值(tagged value)
附在一个元素上,具有一定信息的标签值对。
见约束(constraint)、构造型(stereotype)
参看14章，标准元素(Standard Elements)，存在一系列的预定义标签。
语义
标签值是可以附在任何元素上（包括模型元素和表示元素）以负载各种信息的选择值对，通常对元素的语义来说是次要的而可能对建模企业是重要的。选择者被称为一个标签；它是一个字符串值。每个标签代表一个可以用于一种或者多种元素的属性。在一个模型里的任何元素上，标签名只能最多出现一次。标签的值可能是各种类型的，但是被编码为字符串。对值的解释是建模者和建模工具之间的约定。可以把标签值实现为由标签进行索引的查询表以提高访问效率。
标签值代表任何以文本方式表达的信息，通常被用来存储工程管理信息，比如，一个元素的作者，测试状态，某个元素对最终系统的重要性（标签可能是 author, status 和 importance）。
标签值代表了对UML元类的元属性的扩展。这不是一种完全适用的扩展机制但是为了后端工具的利益而被用来向已经存在的元类中增加信息，例如代码生成器，报表生成器，和激励。为避免混淆，标签应该与它们所应用的模型元素的已经存在的元属性区别开。可以使用一种工具方便这种检查。
在UML中预定义了一些标签；其他的可以是用户定义的。标签值是允许把任何信息附加到模型上的扩展机制。
表示法
每个标签值以如下方式显示
tag = value
其中， tag 是标签的名称而 value 是一个字面量。标签值可以和其他的属性关键字一起被包含在一个由括弧包含，逗号分割的属性列表中。
可以声明一个关键字以代表一个带有特定值的标签。在这种情况下，关键字可以单独使用。如果不存在标签，就当作标签的一个其他的合法值。
举例
{author=Joe,status=tested,requirement=3.563.2a,suppress}
讨论
大多数模型编辑程序提供基本的功能以把标签值作为字符串进行定义，显示和查找，但并不用它们来扩充UML的语义。但是，后端工具，比如代码生成器，报表生成器，可以读取标签值并灵活的改变它们的语义。注意标签值列表是一种老思想--例如，Lisp 语言里的属性列表。
标签值是一种向模型附加非语义性的工程管理和跟踪信息的方法。例如，标签 author 可能带有一个元素的作者， 标签 status 可以带有开发状态，例如 incomplete, tested , buggy和 complete。
标签值还可以用来把依赖于实现语言的控制附加到UML 模型上而不用把语言的细节建立到UML中去。代码生成标志，提示，杂注都可以编码为标签值而不会影响低层的模型。对于各种语言来说，相同模型上的多个标签集合是可能的。模型编辑者和语义分析者都不必理解标签--它们可以作为字符串来处理。后端工具，例如代码生成器，可以理解并处理标签值。例如，标签值可以命名用来重载多值关联的缺省实现的容器类。
标签值满足了很多种类的信息必须附加在模型上的需要，但它不是一种完整的元模型扩展机制。标签形成一个平的名称空间，它必须采用某些约定以避免冲突。它们没有提供声明值的类型的方法。它们的目的也不是对建模语言本身进行语义扩展。标签有点象元模型属性，但是它们不是元模型属性，还没有象元模型元素一样被规范化。
标签的使用，正象编程语言库里的函数的使用一样，可能需要一定时期的发展，在这个过程中，在不同的开发者之间可能会发生冲突。经过一定的时间，某些标准使用可能会出现。UML不包含标签的"注册"，也没有提供这样的期望：早期的标签使用者可能会保留它们以防止将来用在别的地方。
345.目标范围(target scope)
对一个值是个实例还是个类元的声明。
见 范围(scope)
讨论
目标范围主要用来存储类作为属性值或者关联目标。它的用途是受限的。单独的词汇"scope"表示所有者范围。
346.目标状态(target state)
转换的激发而形成的状态机的状态.在对象处理完一个可以激发转换的事件后，对象就处在转换的目标状态（或者是目标状态集，如果是一个有多个目标状态的复合状态）。它不适用于内部转换，因为内部转换不会引起状态的改变。
见 转换(transition)
347.模板(template)
一个参数化的模型元素。要使用模板，这些参数必须绑定（在建模时）上实际的值。同义名：参数化元素。
见 绑定(binding)、边界元素(bound element)
语义
模板是对一个带有一个或者多个未绑定的形式参数的元素的描述。因此它定义了一系列的潜在元素，每个元素都是通过把参数绑定到实际的值上来声明。典型的，参数是代表属性类型的类元，但是它们也可以代表整数甚至操作。模板里的附属元素用形式参数来定义，所以当模板被绑定的时候，它们也会被绑定。
模板类是对一个参数化的类的描述。模板体可能包含代表模板本身的缺省元素，还包括形式参数。通过把参数绑定到实际值上就可以生成一个实际的类。模板类里的属性和操作可以用形式参数来定义。模板也可能在它自己与它的参数之间存在联系，比如关联或者泛化。当模板被绑定的时候，其结果就是被绑定的模板类和被绑定到联系参数上的类之间的联系。
模板类不是一个直接可用的类（因为它有未绑定的参数）。必须把它的参数绑定到实际的值上以生成实际的类。只有实际的类才可以作为关联的父亲或者目标（但是允许从模板到另一个类的单向关联）。模板类可能是一个普通类的子类，这意味着所有通过绑定模板而形成的类都是给定类的子类。它也可以是某个模板参数的孩子；这意味着被绑定的模板类是被当作参数传递的类的孩子。
参数化可以被用在别的模型元素上，例如合作甚至整个包。这里给出的对类的描述以明显的方式用到别的模型元素上。
模型的内容不直接受模型的合适性规则的影响。这是因为它们具有直到被绑定才具有完整语义的参数。模板是一种二级的模板元素--不是直接为系统建立模型，而是为别的元素建立模型。所以模板的内容在系统的语义之外。绑定模板的结果就是受合适性规则影响的普通模型元素和目标系统里的普通元素。模板的一定合适性规则可以通过考虑到它们的绑定结果必须适合来得到，但是我们不会试图列出它们。在一定意义上，它的内容被复制，参数被实际值所代替。结果成为有效模型的一部分，好象它已经被直接包含在其中。
别的种类的类元，例如用例或者信号，也可以被参数化。合作也可以被参数化；那它们就成为模式。
表示法
一个小虚线矩形加在类矩形或者别的模型元素的右上角。虚线矩形包含类的形式参数的列表。每个参数有一个名称和一个类元。列表不能为空（否则就不存在模板），尽管在表示中它可能被省略。参数化类的名称，属性和操作出现在类矩形里，但是也可以包含形式参数。别的种类的参数化元素相似处理 。形式参数可以出现在模板体内以显示一个由某个参数确定的相关类。
参数的语法如下：
name:type
其中 name 是参数的标识符，具有模板范围。Type是一个为参数指定类型表达式的字符串。
如果省略类型名称，就认为是结果是一个类元的类型表达式，例如类名称或者数据类型。别的参数类型（例如整数）必须显式地显示出来，其结果必须是一个有效类型表达式。
图13-180显示了带有一个整数参数和一个类参数的模板。该模板和它的每个参数有一个关联。
讨论
有效模型是绑定所有模板而形成的隐含模型。在有效模型里模板参数没有意义，因为那时它们已经被绑定。它们只可以在模板体范围里使用。这足以处理包含在参数化元素里的组成元素，例如参数化类里的属性或者操作。
对于参数化元素外面的元素有更多的困难。例如，一个类可能与别的类有关联或者泛化。如果那些类是模板的参数，它们就不能是有效模型的一部分，它们也不能是普通类的一部分。因此，参数化元素包含一个代表一个模型段的体。模型段不是有效模型的一部分。它是模板本身的一部分，它可能包含模板参数，例如代表某个类的参数。当模板被绑定时，体被隐含的复制，参数被实际值代替，而副本成为有效模型的一部分。每个模板的实例会对有效模型进行增加。图13-181显示了一个例子。
模板体隐含包含了一个代表实例化的模板元素本身的元素--例如，通过绑定模板而生成的类。这个隐含元素可以用来建造联系--例如关联或者泛化--以模板化参数。在这种表示法里，参数画在模板边界里，到模板边界内部的连接代表一个到隐含实例化模型元素的联系。当模板被实例化后，这些就变成有效模型里被绑定元素（刚刚生成）和元素（已经存在且为模板参数）之间的联系。
模板可以是别的元素的孩子。这意味着由它生成的绑定元素都是给定元素的孩子。
例如，在图13-181中，每个变量数组( VArray )是一个数组（Array）。所以，Varray< oint>是Array的一个孩子，Varray<Address>是Array的一个孩子，等等。
一个模板通常不能是别的元素的父亲。这将意味着通过绑定模板而生成的每个元素都是别的元素的父亲。尽管会有人为这种情况赋予一定的含义，但这是不真实的。
两个模板只因为共享相同的名称而不能有关联。（这样做意味着第一个模板的实例化都和第二个模板的每个实例化存在联系，这不是通常所期望的。这一点经常被过去的作者所误解。）参数只在它自己的模板里有效。在两个模板中为一个参数使用相同的名称不会使它成为相同的参数。通常，如果两个模板有必须相连的参数化元素，一个模板必须在另一个模板体里实例化。（回忆一下，模板隐含地在它自己的体中实例化。所以，两个模板都有效地在体内实例化，所以联系存在于实例化地元素之间。）图13-182显示了定义这样联系的一个错误的和一个正确的尝试--这这种情况下，有一个指向相同类型的参数化数组的参数化指针。
图13-182
一种类似的方法是声明一个是别的参数化类的孩子的参数化类，它们使用相同的参数进行绑定。另一种方法是在只有一个参数的第三方模板中实例化这两个模板。该参数用来绑定对方模板的一个副本。然后可以在模板的实例化副本之间建造关联。在大多数情况下，并不需要这样做，因为联系可以声明在任何一个模板里。
348.线程(thread)
(来自控制线程)经过一个程序，动态模型，或者别的控制流表示的执行的单个路径。也是把一个主动对象实现为轻量进程的构造型。
见主动对象(active object)、复合转换(complex transition)、复合状态(composite state)、状态机(state machine)、同步状态(synch state)。
349.时间（time）
代表一个绝对或者相对时刻的值。
见时间表达式（time expression）。
350.时间事件（time event）
代表某个时间表达式被满足的事件，例如一个绝对时间的发生或者对象进入一个状态后的给定时间的包。
语义
时间事件是一个依赖于时间包因而依赖于时钟的存在的事件。在现实世界里，时钟是隐含的。在计算机里，它是一个物理实体，在不同的计算机里可能存在不同的时钟。时间事件是从时钟到系统的一条消息。注意对于现实世界的时钟或虚拟内部时钟（在后一种情况下，对于不同的对象可能存在差异）可以定义绝对时间或者流逝时间。
时间事件可能建立在绝对时间（一天的时间或者系统里的时钟设定）或者相对时间（进入某个状态或者某个时间发生后的流逝时间）的基础上。
表示法
时间事件不象信号那样声明为一个命名事件。相反，时间表达式仅用作转换的触发。
讨论
在任何实际实现中，时间事件不是来自整体--它们来自系统里或者系统外的某个时钟对象。这样，它们变的与信号几乎无法区分，特别是在实时和分布式系统里。在这样的系统里，使用哪个时钟的问题必须解决--不存在象"实时"这样的东西。（它在真实世界里也不存在--问一下 爱因斯坦）
351.时间表达式（time expression）
其计算结果是一个绝对或者相对时间值的表达式。用于定义时间事件。
语义
大多数时间表达式或者是进入某个状态后的流逝时间或者是特定绝对时间的发生。别的时间表达式必须以一种特别的方式定义。
表示法
流逝时间。代表进入包含转换的状态后的一定时间的包的事件，可以表示为关键字 after的表达式。after后面跟着其计算值(在建模时)是一定数量时间的表达式。
after (10 seconds)
after (10 seconds since exit from state A)
如果没有声明起始点,那就是从进入包含转换的状态起的流逝时间。
绝对时间。代表绝对时间的发生的事件可以表示为关键字 When ，后面跟着由括弧括起的包含时间的布尔耳表达式。
When ( date =Jan.1,2000)
352.时标（timing mark）
事件或者消息发生时间的一种表示法。时标用在限制里面。
语义
时标根据消息的名称而形成一个表达式。在交互中，消息被给予一个名称，时标表达式可以根据它来形成。在下面的表达式中，Message是消息的名称。
Message.SendTime()
Message.recieveTime()
表示法
时标表达式显示为文本。
举例
下面的约束限制了形成一个拨号声音所要求的时间。
{ dialtone.sendTime() - offhook.sendTime() <1 second }
353.跟踪（trace）
表示历史开发过程或者表示代表相同概念的依赖关系，该依赖关系没有规则声明其中一个从另外一个继承来的两个元素之间的特殊模型联系。这是最不特殊的依赖形式，它也具有最少的语义。它主要用作开发过程中对人的思考过程的提醒。
见依赖dependency)、模型(model)。
语义
跟踪是依赖的一种，它表明在不同的含义级别上代表相同概念的两个元素之间的连接。它不表示模型里的语义。它是代表具有不同语义的元素之间的连接--既不同含义层次的不同模型上的元素之间的连接。在元素之间没有显式的映射。通常它表示在不同开发阶段捕捉一个概念的两种方式之间的连接。例如，属于相同主题的不同变体的两个元素可以由跟踪连接。跟踪不能表示运行时的实例之间的联系。相反，它是模型元素本身之间的一个依赖。
跟踪的主要应用在于跟踪在系统的开发过程中已经变化的要求。跟踪依赖可以联系两种模型（比如用例模型和设计模型）的元素或者相同模型的不同形式的元素。
表示法
跟踪由带有关键字 trace的依赖箭头（一个虚箭头，其尾部在新元素上而头部在老元素上）来表示但是。但是通常元素处在不同步显示的不同模型里，所以实际上，联系在工具中经常实现为一个超级链结。
354.暂时链（transient link）
只存在一段有限时间的链--例如一个操作的执行--的链结。
见关联(association)、合作(collaboration)、使用(usuage)。
语义
在执行过程中，一些链结存在一段有限的时间。当然，如果时间跨度足够大，几乎所有的对象和链结的生命期都是有限的。但是有些链结只存在于一定的限制语境中，例如在一个方法的执行过程中。过程参数和局部变量可以由暂时链表示。把所有这样的链结建模成关联是可能的，但是这样的话，关联上的条件必须非常粗略的进行声明，失去在限制对象的结合上的精度。这样的情况可以使用合作来建立模型，合作是对对象和存在于特定语境的链结的配置。
来自合作的关联角色可以认为是只在行为实体（如一个过程）的执行过程中存在的一个暂时链。它在类模型中作为使用依赖出现。要得到完整的细节，需要参考行为模型。
表示法
暂时链显示为一个关联，带有一个附在链结角色上以表示各种不同实现的构造型。可以使用下面的构造型。
<parameter> 过程参数
<local> 过程的局部变量
<global> 全局变量（在整个模型或包里可见的）；如果可能应该尽量避免，因为它违反了面向对象的精神。
<self> 自链结（对象给自己发送消息的能力，在对象中是隐含的，只在具有消息流的动态情况下显示是有用的）
<association> 关联（缺省，不必声明除非为了强调）；它不是暂时链，列出来只是为了完整性。
355.暂时对象(transient object)
只在生成它的线程的执行过程中存在的对象。
356.转换(transition)
用于表示一个状态机的两个状态之间的一种关系，即一个在某初始状态的对象通过执行指定的动作而进入第二种状态，当然，这种转换需要某种指定的事件发生和指定的监护条件得到满足。在这个状态的变化中，转换被称作激发。简单转换只有一个源状态和一个目标状态。复杂转换有不止一个源状态和（或）有不止一个目标状态。它表示在一系列并发的活动状态中或在一个分叉型或结合型的控制下所发生的转化。内部转换有一个源状态但没有目标状态。它表示对没有状态转化的事件的反应。状态和转换是状态机的顶点和节点。
见状态机(state machine)。
语义
转换表示在一个对象的生命历史中所有的状态之间可能有的路径以及在状态变化时发生的动作。转换显示某状态的对象对一个事件的发生进行反应的路径。状态和转换是状态机中的顶点和弧，来描述一个类元中所有实例的可能的生命历史。
结构
转换有一个源状态，一个事件触发器，一个监护条件，一个动作和一个目标状态。在转换中，有一些可能会缺少。
源状态 源状态是被转换所影响的状态。如果某对象处于源状态，而且此对象接受了事件的触发和监护条件得到了满足，则此状态的外向转换会激发。
目标状态 目标状态是转换结束后的主动状态，它是主对象要转向的状态。目标状态不会用于不存在状态变化的内部转换。
事件触发器 事件触发器是一个事件，它被处于源状态的对象所接受后，转换只要得到监护条件的满足就可激发。如果此事件有参数，这些参数可以被转换所用，也可以被监护条件和动作的表达式所用。触发转换的事件就成为当前事件，而且可以被并发的动作访问，这些并发动作都是由事件激发的"运行到完成"这一过程的步骤。
没有明确的触发器事件的转换称作结束转换（或无触发器转换），是在结束时被状态中的任一内部活动隐式触发的。复合状态通过达到它的终止状态而表明其结束。如果一个状态没有内部活动或嵌套状态，而状态在任意入口动作执行之后被输入，那么结束状态就会被立即触发。要注意到，结束转换要激发，必须满足监护条件。若结束发生时监护条件不成立，则隐式结束事件会被消耗，而且以后即使监护条件再成立，转换也不会激发了。（这种行为用一个修改事件来模拟）
注意，一个状态机的某个事件的所有表现必须有同样的特征。
监护条件 监护条件是一个布尔表达式，它在一个事件的操作触发了转换时得到值，包括隐式结束事件对结束转换的触发。如果一个事件发生时状态机正在执行"运行到结束"的过程，此事件会被保存，直到这个过程结束和状态机静止。否则，此事件会被立即处理。如果表达式的值为真，转换可以激发；如果表达式的值为假，转换不能激发；如果没有转换适合激发，事件会被忽略。这种情况并非错误。有着不同监护条件的多重转换可以被同样的事件触发。若此事件发生，所有监护条件都被测试，若有不止一个监护条件为真，也只有一个转换会激发。如果没有给定优先权，则选择哪个转换来激发是不确定的。
注意，监护条件的值只在事件被处理时计算一次。如果其值开始为假，以后又为真，转换是不会激发的，除非有另一个事件发生，且令这次的监护条件为真。注意，监护条件不是持续监控一个值的正确方法。修改事件应该被用于这种情况。
如果转换没有监护条件，监护条件就被认为是真，而且一旦触发器事件发生，转换就激活。若有几个转换同时激活，只有一个可以激发，其选择是不确定的。
为了方便，一个监护条件能够被拆解成一系列简单的监护条件。实际上，这一系列监护条件可以是某个触发器事件或监护条件的分支，每一分支都是一个单独的转换，每一转换被有着不同的但却是有效的监护条件的（单独的）触发器事件所触发，这是对触发器事件的路径上所有的监护条件的合取（"与"）。这条路径上所有的表达式都会在转换访问激发前得到值。转换不能部分地激发。事实上，一套独立的转换可以部分地共享它们的描述。
图13-183是一个示例。
注意，那些监护条件的树和将转换安排得合理的能力仅仅是为了方便，因为同样的效果还能通过一套独立的转换实现，只要每个转换有它拆解的监护条件。
动作 转换可含有描述一个动作的动作表达式。这个表达式是为了过程化计算，过程计算可以对拥有状态机的对象产生影响（而且，间接地，其他对象也会被影响）。动作表达式可以使用触发器事件的参数，以及所拥有的对象的属性和关联。在整个"运行到完成"的过程中，若当前事件被包括以后的非触发器段、出口动作和入口动作在内的事件激发，触发器事件就可用。
动作可以是一个动作顺序。单个动作是原子的--就是说，它不能在外部被终止，而必须在任何其他动作或事件的处理之前被完整地执行。动作应该用最小的持续时间以免状态机被中止。任何一个在动作执行期间接收到的事件都会被保存，直到动作结束，那时接受到的事件也已得到值。
分支 为了方便，几个共享同一触发器事件却有着不同的监护条件的转换能够因为模型和表示法被分在同一组中，以避免触发器或者监护条件的相同部分被重复。这仅仅是一种表示上的方便，不会影响转换的语义。
在分支中查看其表示法的详细说明。
表示法
转换用实线箭头表示，从一个状态（源状态）到另一个状态（目标状态），用一条转换线标注。
图13-184显示的是在两个状态间的转换，还有从一个分出多个线段的情况。
内部转换表示成在状态标志内部的转换线。一条转换线有如下格式：
名称：操作事件名称操作（参数清单）操作[监护条件]操作 / 动作清单操作
名称可用于引用转换的表达式，尤其是用于形成时标。其后有一个冒号。
事件名称命名了一个事件，其后跟有参数清单。如无参数，参数清单可以省略。事件名称和参数清单对一个结束转换是省略的。参数清单有如下格式：
名称：类型表，
监护条件是一个布尔表达式，由触发器事件的参数、属性和用状态机描述的对象的连接等条目组成。监护条件还可以包括状态机中的并发状态的测试或某可获得的对象所指定的外部状态的测试--[在 状态1]和[在 状态2]是具体示例。状态名称可以完全由包含它们的嵌套状态来限制，产生这种形式的路径名：状态1::状态2::状态3。在整个状态机中，如果在不同的复合状态区域有同样的状态名称发生，就可用此形式。
动作清单是一个过程表达式，它在转换激发时得到执行。它可由操作、属性、拥有对象的连接、触发器事件的参数等条目组成。动作包括调用、发送及其他种类的动作。动作清单可包含多个的被分号隔开的动作子句：
动作表；
分支 一个转换可包含一条线段，并有一个伴随着结合状态的树的触发器事件，画成小圆圈。这相当于一套独立的转换，每一个相当于通过树的每一条路径，其监护条件是此路径上所有条件的"与"。只有每条路径的最后一条线段可有一个动作。
结合状态如果表示分叉或结合，也可画成一个菱形，在意义上没有不同。
讨论
转换表示从一状态到另一状态的原子变化，也可能伴有原子动作。转换是不可中断的。转换上的动作应当短暂，通常是琐碎的处理，例如赋值、声明和简单的计算。
357.移交阶段(transition phase)
软件开发过程的第四个阶段，在该阶段中，配置实现的系统准备在现实世界环境中执行。在这个阶段，配置试图已经完成，前面各个阶段尚未完成的剩余视图也完成了。
见 开发过程(development process)
358.转换时间(transition time)
见时标(timing mark)。
359.触发器(trigger)
一个事件，其发生使一个转换能够激发。其名称可以是个名词（事件本身），也可以是个动词（事件的发生）。
见结束转换(completion transtion)、转换(transition)。
语义
每个转换（除了结束转换是因内部活动的结束而激发）都会将事件作为结构的一部分而涉及到它。如果某个事件在对象处于包含一个外向转换的状态时发生，而此外向转换的触发器就是这个事件或是这个事件的祖先，那么，这个转换的监护条件会被测试。如果条件满足，转换能够激发；如果缺少监护条件，它必须得到满足。如果有多个转换满足条件，实际上也只有一个可以激发，而选择哪一个可能是不确定的。（如果对象有多个并发状态，从任何一个状态开始的转换都可能激发，但最多只有一个转换可以激发。）
注意，监护条件只在触发器事件（包括隐式的结束事件）发生的时候被测试一次。若某事件发生时没有转换能够激发，此事件仅仅会被忽略。这不是错误。
在一个监护条件中，或者在一个参加转换或参加目标状态的入口动作的动作中，触发器事件的参数都能被使用。
在转换之后的"运行到完成"的整个步骤执行当中，触发器事件对转换的分步骤中的动作作为当前事件保持可用。在一个入口动作或多段转换的一个后续段中，这个事件的准确类型可能是不可知的，因此，此事件的类型会在使用多态操作或情况说明的某个动作中得到辨别。一旦得到了事件的确定类型，其参数就能够被使用。
表示法
触发器事件的名称和特征是转换标号的组成部分。
见转换(transtion)。
触发器事件可以在由保留字"当前事件"限定的表达式中被访问。这个关键字涉及到在一个多段转换的首段的触发器事件。
360.无触发器转换(triggerless transition)
没有明确的事件触发器的转换。当它离开一个普通状态，就代表一个结束转换，就是说这个转换是被活动的结束而非某个明确的事件所触发。当它离开一个伪状态，就代表一个转换段，此转换段可被自动通过，若其先前的段已经结束动作。无触发器转换用于连接初始状态和历史状态以达到它们的目标状态。
361.有序表(tuple)
一个对值按序排列的列表。通常情况下，此术语的含义是一系列相似格式的列表（这是一个标准的数学术语）。
362.类型(type)
作为形容词：按一个属性、参数或变量的值而声明的类元必须保留。其实际的值必须是此类型的一个实例，或是此类型的一个子孙的实例。
作为名词：一个类的构造型通常说明了一系列实例（比如对象）以及适用于这些对象的操作。类型可以不包含任何方法。对比：接口，实现类。
类型和实现类
类能被构造成类或实现类（虽然对它们也可以无差别地进行支配）。类型被用来说明一个对象的域以及适用于这些类的操作，但没有定义这些对象或操作的物理实现。类型可以不包含任何方法，但它可以提供这些行为的操作说明，也可以包括属性和方法，这是为了说明操作的行为。类型的属性和关联不决定它的对象的实现。
一个实现类定义了物理数据结构和对象的方法，与传统语言中实现的一样，比如C++和Smalltalk。当实现类包括了所有与类型所具有的行为一样的操作，实现类被认为实现了一个类型。一个实现类可以实现多个类型，而多个实现类可以实现同样的类型。一个实现类的属性和关联不必相同，象在类型的实现中一样。实现类可以在其物理属性和关联的条件中为起操作提供方法，而且可以声明其他类型中所没有的附加操作。
对象必须是只有一个实现类的实例，此实例指定了对象的物理实现。然而，一个对象是有多个类型的实例。如果对象是只有一个实现类的实例，那么此实现类必须实现此对象作为一个实例的全部类型。如果动态类元是可用的，则在生命期内，对象可以获得和失去类型。通过这种方式使用的类型刻画了一个可变的角色，对象可以接受，以后再放弃。
尽管类型和实现类的在使用上并不相同，但其内部结构是一致的，所以它们成为类构造型的模型。它们支持泛化、替代原理、以及属性继承、关联和操作。类型可专用于类型，而实现类也可专用于实现类。类型只能通过实现这一行为和实现类联系起来。
表示法
说明一个无明显特征的类时是没有关键字的。说明类型时有关键字《type》，而说明实现类有关键字《implementation》。图13-185显示了一个例子。
依靠实现类来实现的类型通过使用"实现"这一联系而成为模型，表示为带有实三角箭头的一条虚线（一个"虚线泛化箭头"或一个"有实箭头的依赖关系"）。这种符号表示了在操作上的继承关系，但没有表示结构的继承（属性或关联）。实现可以在任何两个类元间得到使用，为此其中的一个类元会支持另一个类元的操作，但依靠实现类而成的类型的实现是这种方式的一个共有的使用。
讨论
类型和实现类在某种程度上是受到一些限制的概念，这是由于概念针对的是象C++和Smalltalk这样的传统程序设计语言。在UML中，类的概念能够直接地以更加全面的方式得到应用。UML对多重类元和动态类元都提供支持，去除了对类型和实现类之间存在区别的需要。然而，在用传统的语言编制代码时，这些区别的确有用。
363.类型表达式(type expression)
一个表达式，其值是指向一种或多种数据类型的引用。比如，在典型的程序语言里，一个属性类型声明就是一个类型表达式。
举例
在C++里类型表达式如下：
Person*
Order[24]
Boolean(*)(String,int)
364.无解释(uninterpreted)
一个占位符，提供给一个或多个不是由UML定义其实现的类型。每个无解释的值都有一个相应的字符串来代表。在任何物理实现中，例如模型编辑，实现必须完成，所以其中不能有无解释值。
365.非指定值(unspecified value)
一个还没有被模型指定的值。
讨论
一个非指定值在特定的含义下完全不是一个值，而且除了其值不是必需的或其值是不相关的那些特性以外，非指定值不能在一个完全模型中出现。例如，多重性是不可知的；而它必须有值。如果缺乏任何知识，就相当于一个多重性，因此UML的语义不允许或不处理缺少值或非指定值的情况。
在另外一个含义中"非指定"是未结束模型的一个有用部分。它有这样的意思："我仍然没有考虑过这个值，而我已经对它作了记录，以便我可以在后来赋给它一个值。"非指定是一个外在的、模型是不完整时的状态。这是个有用的能力，而且一个那样的工具可以支持它。正是依靠其本来的性质，这样的一个值只不能在已完成的模型里出现，而且它并不关注对它的语义作出定义。在需要值的时候，有工具能自动地为非指定值提供一个缺省值--比如在代码生成的时候--但这只是一个方便的措施，而不是语义的一部分。非指定值是UML语义之外的概念。
简单而言，为特性提供的缺省值没有语义定义。在模型里的特性只不过有一个值。对新创建元素的特性，有工具可以自动地为其提供值。需要再次说明，这只是一个由于工具而带来操作上的简便，不是UML语义的一部分。语义完全的UML模型没有缺省值或非指定值；只不过它们有值。
366.使用(usuage)
一个依赖关系。在此关系当中，一个元素（客户）为了自己的当前功能或实现，需要另一个元素（提供者）的存在--通常是因为实现的原因。
见合作(collaboration)、依赖(dependency)、暂时链(transient link)。
语义
一个使用依赖关系是这样的状况：某个元素（客户）为了自己的当前实现或功能，需要另一个元素（提供者）的存在。所有的元素必须存在于同等的意义级别上--就是说，它们不涉及在抽象或实现上提高级别（比如在一个分析级的类和一个实现级的类之间的变换）。使用依赖关系经常涉及实现级元素，比如一个C++的包含文件，为此它包含了编译器结果。使用可以被进一步构造，以表明依赖关系的精确性质，比如调用属于另一个类的某个操作或实例化属于另一个类的某个对象。
表示法
使用由一个带有关键字《use》的虚箭头（依赖关系）来表示。箭头在提供者（独立的）元素，而尾标在客户（依赖）元素。
讨论
使用通常与暂时链相符合--即指在类的实例之间的一种联系，这个联系不是始终都有意义或存在，只存在与某些语境中，比如一个子过程的执行。在这种情况下，依赖关系构造不对所有的信息建模，除非事实它的确存在。合作构造提供了对这种联系在所有细节上建模的能力。
标准元素
调用，创建，实例化，发送。
367.使用(use)
使用依赖关系的表示法中的关键字。
368.用例(use case)
动作的顺序的说明，包括变量顺序和出错顺序，使一个系统、子系统或类能够通过与外部参与者间的交互而执行。
见参与者(actor)、类元(classifier)。
语义
一个用例是一个连贯的功能性单元，由一个用消息的顺序来显示的类元（一个系统，子系统，或类）提供，这些消息与动作被系统执行的同时在系统和一个或更多个外部使用者（表现为参与者）间交换。
用例的目标是要定义类元（包括一个子系统或整个系统）的一个行为，但并不显示类元的内部结构。每个用例说明一个类元提供给它的使用者的一种服务，也即一种对外部可见的使用类元的特定方式。它描述由某用户以用户和类元间交互的观点来初始化的完整的顺序，以及由类元执行的响应。这里的交互只包括系统与参与者之间的通讯。内部行为和实现是隐藏的。一个类元或系统的全部用例分割和覆盖它的行为，每个用例代表一部分量化了的、有深刻意义的和对用户可用的功能性。注意这里的用户包括人、计算机和其他对象。参与者是一个用户意图的理想化事物，并不是自然用户的代表。一个自然用户能映射到许多参与者，而一个参与者能代表多个自然用户的同一个方面。
见参与者(actor)。
用例包括对一个用户请求作出响应的常规的主线行为，以及常规顺序的可能变量，比如间隔顺序，异常行为和错误处理。其目的是要描述在其所有的变化中的一个连贯的功能性，包括所有的错误条件。一个类元的全套用例说明使用此类元的所有不同的方式。为了方便，用例可以被分组打包。
用例是一个描述；它描述潜在的行为。用例的执行是用例实例。用例的行为能够用附加的状态机或用文本代码（与状态机相同）来说明，也可以用一种非正式的文本描述。行为能用一套方案被举例说明，但并不形式化。在发展的早期阶段，这可能已足够。
用例实例是一个用例的执行，由来自参与者的一个实例的一条消息初始化。作为对此消息的响应，用例实例执行一系列被用例指定动作，比如给参与者实例发送消息，不必只是给初始参与者。参与者实例可以向用户实例发送消息，而此种交互会持续下去，直到实例已经对所有的输入作出响应。当它不再得到输入时就会结束。
作为在与外部参与者的交互中的一个整体，用例是对系统（或其他类元）的行为的说明。在实现行为的系统中，合作实现了用例，内部对象之间的内部交互也是由它来描述。
结构（Structure）
用例可以有类元特征和联系。
特征 用例是类元，因此有属性和操作。属性用于代表用例的状态--即执行用例的行进。一个操作代表用例能执行的一件工作，它不是直接从外部随时支取，但可以被用来描述用例对系统的影响。操作的执行可以与来自参与者的消息相关联。操作作用于用例的属性，而且间接作用于用例所附属的系统或类。
到参与者的关联 在参与者和用例间的关联表明了参与者实例与系统实例或类元实例相通讯，而对一些对于参与者很重要的结果产生影响。参与者会模型化类元的外部用户，这样，如果此类元是一个系统，它的参与者就是系统的外部用户。较低级子系统的参与者可能是整个系统的其他的类。
一个参与者可以与多个用例通讯--即参与者可以请求系统的多个不同服务--而且，如果提供它的服务，一个用例可以与一个或多个参与者通讯。注意，两个被同一系统指定的用例不能互相通讯，这是因为其中任何一个用例都为系统单独描述了一个完全的使用。它们可以通过共享的参与者间接地进行交互。
参与者和用例之间的交互能够用接口来定义。一个接口定义了一个参与者或用例可以支持或使用的操作。由同一用例给出的不同接口不需要互斥。
泛化 泛化联系将特化用例和更一般的用例联系起来。子用例继承父用例的属性，操作和行为序列，而且可以增加属于自己的另外的属性和操作。子用例通过在任意点向父用例插入额外的动作序列而向父用例增加增量行为，它也可以修改某些继承操作和顺序，但这必须象任何一个重载一样地完成，以使父用例的目的得以保留下来。
扩展 扩展联系是一种依赖关系。客户用例通过向基序列插入额外的动作序列而向基用例加入增量行为。客户用例包含一个或多个分开的行为顺序段。扩展联系包含来自基用例的一列扩展点名字，在数量上与客户用例的段的数量一样多。一个扩展点代表基用例中的一个或一组位置，扩展可以在这位置上被插入。在扩展点上，扩展联系也可以有一个条件，以此来使用父用例的属性。当一个父用例的实例到达一个被扩展联系中的扩展点所引用的位置时，上述条件得到判断；若条件为真，与之相符的子用例中的行为段被执行。若没有条件约束，则被认为是永真。如果扩展联系具有多于一个扩展点，那么条件只有在首段中的优先执行的第一个扩展点上得到判断。
扩展联系不会创建一个新的可实例化的用例。相反，它隐式地向原始的基用例增加行为。基用例隐式地包括了扩展行为。未扩展的原始基用例在其旧有的形式下是不可用的。换一种说法，如果你扩展了一个用例，那就不能隐式地在没有扩展的可能性时将基用例实例化。用例可以有多个扩展，这些扩展都适用与同一基用例，而且如果它们的条件分别得到满足，还能够被插入一个用例实例。在另一方面，一个扩展用例可以扩展多个基用例（或是同一个扩展在不同的扩展点），每一个都在其正确的扩展点上（或是扩展点的列表）。如果在同一个扩展点上有多个扩展，则它们执行的相对顺序是不确定的。
注意，扩展用例是不会被实例化的，而基用例必须被实例化以得到联合的基-附加-扩展行为。扩展用例可不可以被实例化都可能，但不论是哪种情况，它都不包括基用例行为。
包括 包括联系表示的是：在一个客户用例的控制当中，对提供者用例在一个客户用例的交互顺序当中的行为顺序的包含。而此客户用例正处于由客户的描述所指定的位置上。这是一个依赖关系，不是泛化，因为提供者用例不能在客户用例出现的位置上被替代。客户可以使用基用例的属性来获得值和通讯结果。用例实例执行的是客户用例，当它到达包括点时，就开始执行提供者用例，直到结束。然后，它重新开始执行客户用例，超过包括位置。在不同的执行之间，提供者用例的属性没有值是坚持不变的。
用例可以是抽象的，这意味着它不能直接在一次系统执行中被实例化。它定义一个行为的片段，而此行为是被具体用例特化或包括了的；或者它是一个基用例的一次执行；如果它能被自己实例化，它也可以是具体的。
行为 一个用例的行为顺序能够用状态机、活动图或某种可执行的文本代码来描述。状态机的动作或代码的状态可以调用用例的内部操作来说明执行的效果。动作也可以显示向参与者发送的消息。
用例可以用方案或纯文本进行非形式化的描述，但这种描述是不严密的，而且只能用于人类阐述。
用例的动作可以在调用由用例描述的类元的操作期间被说明。一个操作可以被多个用例调用。
实现 用例的实现可以由一组成作来说明。合作是依靠用例所描述的类元里的对象而对用例的实现进行描述。每个合作描述系统的要素之间的语境，而在系统中有一个或多个交互序列发生。合作和它们的交互定义了系统中的对象怎样交互来得到用例指定的外部行为。
系统能够通过各种抽象级别的用例得到说明。例如，说明系统的用例可以被重定义成一组下属用例，其中每个说明子系统的一个服务。由超级（较高级别）用例说明的功能性完全可跟踪到由下属（较低级别）用例说明的功能性。一个超级用例和一组下属用例在不同的抽象级别上说明同样的行为。下属用例协同提供超级用例的行为，这些下属用例的协同是由超级用例的合作来说明的，而且可以在合作图中表示。一个超级用例的参与者是以多个下属用例的多个参与者出现。在一组实现了整个系统的嵌套的用例和合作中，这些关系将实现的结果层次化。
表示法
用例是用一个包括用例名字的椭圆形来表示。如果用例的属性和操作必须被显示出来，可以将用例绘制成一个带有关键字《use case》的矩形类元。
图13-186表示的是一个用例图。
一个扩展点是一个命名了在用例内部的的实体，这个用例描述了来自其他用例的动作序列可以被插入的位置。扩展点提供扩展和行为序列文本之间的一个间接级别。扩展点引用了在用例的行为序列中的一个位置或一组位置。对于使用此扩展点的扩展联系，这种引用能够被独立地改变。每个扩展点必须在用例中有一个独有的名字。扩展点可以在一个用例的区域里被列举出来，标题为"扩展点"。
在用例和参与者之间的通讯联系是用一个关联符号表示--连接用例和参与者符号的一条实线。因为通讯是参与者和用例之间唯一的一种关联，所以关键字《communication》通常可以被省略。通常情况下，由于参与者和用例唯一地定义了这个联系，因而在这条实线上不标注名字或角色名字。
泛化联系用一个泛化箭头表示--从子用例到父用例的一条实线，一个实三角箭头指向父用例。
扩展联系或包含联系用一个带有关键字《extend》或《include》的依赖关系箭头表示--带有附着箭头的一条虚线，指向客户用例。在扩展联系上也有一个扩展点名字的列表（在图上可以取消）。
图13-187表示了各种用例联系。
行为说明 用例和它的外部交互序列之间的联系通常由一个连向序列图的超链来代表。此超链不可见，但可以在一个编辑器中移动。行为也可以用一个状态机或用附加在用例上的程序设计语言文本来说明。自然语言文本可以当作一种非正式的说明。
见扩展(extend)，作为某些行为序列的一个例子。
用例和其实现之间的联系可以表示成一个实现联系，此实现来自一个到合作的用例。但因为这些联系经常是在不同的模型中，所以通常用一个不可见的超链来代表。期望的情况是有一种工具可以支持这样的能力："压缩进入"一个用例中来查看其作为一个合作的方案和/或实现。
369.用例图(use case diagram)
表示处于同一系统中的参与者和用例之间的关系的图。
见参与者(actor)、用例(use case)。
表示法
一个用例图是一个包括参与者、由系统边界（一个矩形）封闭的一组用例、参与者和用例之间的关联、用例间的联系以及参与者的泛化等的图。用例图表示了来自用例模型（用例，参与者）的元素。
370.用例泛化(use case generalization)
是在一个用例（子用例）和另一个用例（父用例）之间的类元关系，其中的父用例描述了子用例与其他用例共享的特性，而这些用例是有着同一父用例的。这是适用于用例的泛化。
语义
父用例可以被特化成一个或多个子用例，用这些用例来代表父用例的更多明确的形式（图13-188）。
因为用例是一个类元，所以子用例要继承父用例的所有属性、操作和关系。这个继承操作的实现可以被实现子用例的合作进行重载。
父用例的Verify Identity的用例行为：
父用例是抽象的，则没有行为序列。
一个具体的子孙必须提供如下所示的行为。
子用例的Check Password的用例行为：
从主数据库获得密码
请求使用密码
用户提供密码
在用户登录时检查密码
子用例Retinal scan的用例行为：
得到来自主数据库的网状特征
扫描用户的网形和得到特征
将主特征和扫描特征比较
子用例继承父用例的行为序列，而且可以向父用例插入额外的行为（图13-189）。
父用例和子用例是潜在地可实例化（如果它们不是抽象的），而同一父用例的不同的特化是独立的，这不同于扩展联系，在其中多重扩展都隐式地限制同一基用例。行为可以通过在继承自父用例的行为序列中增加步骤而被加入到子用例中，也可以通过对子用例声明扩展和包含联系的方式来完成。如果父用例是抽象的，其行为序列可以有分段，这些分段在父用例中是显式不完整的，而且必须是由子用例提供的。子用例可以对继承自父用例的步骤作限制，但由于方法上的重载，这种能力必须小心使用，因为要保证父用例的意图必须保留下来。
泛化联系将一个子用例连向一个父用例。子用例可以存取和修饰由父用例定义的属性。
用例的替代意味着子用例的行为序列必须包含其父用例的行为序列。在父用例序列中的步骤不需要相互邻接；子用例可以在继承自父用例的行为序列中插入额外的步骤。
对用例的多重继承的使用需要一个显式的说明，说明如何在父用例的行为序列中插入步骤来生成子用例的序列。
用例泛化可以使用私有继承来共享基用例的实现，而不完全替代，但这个功能应该保守使用。
表示法
使用普通的泛化符号--从子用例到父用例的一条实线，空三角箭头指向父用例的符号。
实例
图13-188显示了抽象用例身份检验和其由两个具体用例的特化，用例的行为在图13-189中显示。
用例实例(use case instance)
被一个用例指定的序列动作的执行。
见用例（use case）。
372.用例模型(use case model)
一个模型，它描述的是系统或其他在用例的项目上的类元的功能需求。
见参与者(actor)、用例(use case)。
语义
用例模型代表一个系统或其他类元的功能性，表现为与系统的外部交互。用例图中显示了用例模型。
373.用例视图(use case view)
是指就用例而言，系统中关系到指定行为的那个方面。一个用例模型是集中在此视图的模型。用例视图是松散地成组的建模概念中的一部分，就象动态视图。
374.效用(utility)
一个类的构造型，它以类声明的形式将全局变量和过程进行分组。效用的属性和操作分别成为全局变量和全局过程。效用不是一个基本建模结构，却方便了编程。它没有实例。
语义
效用的属性是全局变量，而且效用的操作是全局操作。由于作为类作用域成员，全局的属性和操作能够被更好的模型化，所以对于面向对象的程序，效用不是必需的。此结构是为了与非面向对象的语言相兼容而提供的，比如C。
表示法
效用表示为一个类符号，在类名之上有构造型的关键字《utility》。属性和操作代表全局成员。在这里的符号中没有声明类作用域成员。
375.值(value)
见数据值(data value)。
376.顶点(vertex)
在状态机中，转换的一个源或目标。顶点可以是一个状态或一个伪状态。
377.视图(view)
模型的一个影射，它可从一个透视图或优势位置看到，而且它省略了与这个透视图无关的实体。这个词用在这里不是表示一个说明元素。相反，语义模型和可见的表示法中的影射，它都包括。
378.可见性(visibility)
一个枚举，其值（公有的，受保护的，或私有的）说明了它所涉及的模型元素是否在其命名空间的外部可见。
见访问(acess)，作为一个应用于包间引用的可见性规则的讨论。
语义
可见性声明了建模元素引用一个元素的能力，此元素与引用元素处于不同的命名空间。可见性是一个元素和包含它的容器之间的联系的一部分，容器可以是包、类或某个其他的命名空间。有三个预定义的可见性。
公有的 任一元素，若能够访问容器，则也能够访问包容器指出的元素。
受保护的 只有容器中的元素或包容器的子孙能够访问指出的元素，其他
元素不能引用或使用它。
私有的 只有包容器中的元素能够访问指出的元素。其他元素，包括包 含体的子孙的元素，都不能引用或使用它。
增加的可见性的种类可以为某些编程语言定义，比如C++的implementation可见性（实际上，所有非公有可见性的形式都是由语言决定的）。使用额外的选择必须依靠用户与建模工具和代码生成器之间的约定。
表示法
可见性用放在模型元素前的一个特定的关键字或一个标记符来表示。
公有的 +
受保护的 #
私有的 -
可见性标记可以取消。缺少可见性标记说明可见性没有显示，而不是说未定义或是公有的。即使可见性没有显示，也有工具给新元素的可见性赋值。可见性标记是对一个可见性说明字符串完全形式的速记。可见性也可以用关键字（public,protected,private）来说明。当一个内部表元素应用于一整快属性或其他表元素时，常用这种形式。
任何语言专用的或用户定义的可见性的选择必须用一个特定的字符串或用一个工具专有约定来说明。
类 在一个类中，可见性标记标在表元素上，比如属性和操作。这表明其他类能否访问这些元素。
关联 在一个关联中，可见性标记标在目标类（通过可见性的设置，能够被访问的结束端）的角色名字上。这表明在远端的类能否通过关联到达带有可见性标记的结束端。
包 在一个包中，可见性标记标在直接为包所包含的元素上，比如类、关联和嵌套包。这表明另一个访问或引入第一个包的包能否访问这些元素。
379.良好构成(welled formed)
指出一个模型是被正确构造的，模型满足所有的预定义和模型说明规则与约束。一个这样的模型具有的语义是有意义的。模型没有良好构成称为差构成。
|
发表于 2003-6-27 03:46:50