15.2.5 示例
图15.12展示了多种活动节点：可执行节点（例如Receive Order、Fill Order）、对象节点（Invoice）和控制节点（Receive Order之前的初始节点、Receive Order之后的决策节点、围绕Ship Order的ForkNodes和JoinNode、Close Order之前的合并节点和Close Order后的活动结束节点）。
图15.12 Activity node example (where the arrowed lines are the only non-activity node symbols)
在图15.13中，连接Fill Order到Ship Order的是一条控制流边。这意味着当Fill Order行为结束后，控制传递到Ship Order。它下面，相同的控制流边带了一个名称。最底部左边的采用了连接器，而不是一条连续的直线。在右上角，从Send Invoice开始在Make Payment结束的带箭头直线式控制流边（至少从图示上看是，参见图15.14的讨论）。这指示了Invoice对象从Send Invoice流向Make Payment。
图15.13 ActivityEdge examples
图15.14中的两个图都指示了Order对象从Fill Order流向Ship Order。左边的例子有两条带箭头线，一条来自Fill Order，另一条到达Ship Order。右边的例子有一条始自Fill Order输出Pin（一个对象节点） 终于Ship Order输入Pin的带箭头线。它们背后的模型是相同的，模型中有一个对象流，左图中显示为两条箭头，假定左图中的Order矩形框不代表一个中央缓冲节点（参见15.4）。
图15.14 ObjectFlow example
图15.15左边的例子展示了Pick Materials活动为相关材料提供了Order用于组装。在右面，这个对象流通过省略对象流细节被简化。
图15.15 Eliding objects flowing on the edge
图15.16展示了选择和转换行为的例子。左边的示例指示Orders应该该着优先级来选择，具有相同优先级的按照先进先出（FIFO）原则。右边的示例指示Close Order的结果是已关闭的Order对象，但Send Customer Notice需要一个Cusomer对象。转换规定了一个检索操作的调用，它输入Order对象产出与之相关的Customer对象。
图15.16 Specifying selection and transformation Behaviors on an ObjectFlow
图15.17中，对象节点Order与一个进一步定义它的类图相关联。该类图展示了完成一个订单需要订单、订单项，以及客户的trim-and-finish需求。一个Order token是流经Accept和Fill活动之间的对象，但还与其它对象相链接。不带该类图的活动提供了一个该过程的简化视图。关联到类图的链接用于细节的展示。
图15.17 Linking a class diagram to an object node
图15.18中，Request for Quote (RFQs)被发送给多个特定的销售商（即，多播），希望从每一个销售商获得一个报价。一些销售商返回了它们的报价响应。由于可以接收多个响应，边用多接收选项来标注。发布/订阅和其它中介机制可以使用多播和多接受来处理。
注意. 泳道是用来指示发送者和响应者的一个重要特性。
图15.18 Specifying multicast and multireceive on the edge
图15.19中，连接器用于避免画一条长边。如果一个problem无优先级，token流向连接器并被发给合并节点。图15.19和图15.20具有相同的抽象语法表示。
图15.19 ActivityEdge connector example
图15.20 Equivalent model
图15.21展示了三个使用weight属性的例子。Cricket示例使用一个常数weight指示一个板球对需要11个队员才能组队。Task示例使用一个非常数weight指示对于某个特定工作，只有当它的所有任务都完成时，才能发送一个invoice。底部的示例描述了对一个提议进行投票的活动，其中可以投多个票。当达到投票截止时间，并且Ready to award bid事件到达，然后Award Bid一次接收所有的投票，然后选择一个进行判决。
图15.21 ActivityEdge weight examples
图15.22中Process Order的定义使用了边界来指示这是一个活动，它使用一个活动参数节点表示一个单一的输入参数。它对于所请求的定义有前置和后置条件。所有的调用都使用相同的执行。
图15.22 Example of an activity with input parameter
图15.23中的图是一个飞机设计过程中标准的部件选择工作流。标准工程师确保Provide Required Part中的子步骤是在规定的次序和条件下执行的，但不是必须执行这些步骤。尽管由标准工程师关联该过程，其中一些子步骤是由设计工程师来执行的。Expert Part Search行为可能导致找到或没找到部件。当没找到部件时，调用Assign Standards Engineer行为。最后，Specify Part Mod Workflow产生需要完成的活动实例。这些被传递给后续的动作来调度和执行（即，Schedule Part Mod Workflow、Execute Part Mod Workflow 和Research Production Possibility）。由于活动是类，它们的实例可以被传递到对象tokens中用于后续执行。这是一个运行时活动实例化和执行的例子。
图15.23 Part selection workflow example
图15.24展示了解决一个故障报告表的流程示例活动。
图15.24 Trouble ticket workflow example
图15.25是一个使用类图示来表示活动的类特征的例子。
图15.25 Activity with attributes and operations