GA003-182-19

Three State Timeline with Constraints

带约束的三态时间线

带有约束的三状态时间线模式创建元素和时序图，该时序图显示随着时间推移发生的事件，类中的离散状态更改。时间线在x轴上定义时间刻度，在y轴上定义离散状态。将显示持续时间，指示类保持给定状态的时间。
该图显示了一个时序图，使用值生命线来表示类可以假定的离散状态。

讨论

其目的是展示一个类（或其他分类器）如何使用定义的时间尺度随时间改变状态。这允许分析员创建相对于定义的时间尺度在类之间转换的离散状态的可视化表示。

它通常在分析或实现过程中用于分析复杂的时序问题或表示需要根据定义的时间尺度分析的状态变化。它可用于定义或分析通信协议、服务器响应、软件组件、业务或系统流程或其他实体，其中实际时间值对分析至关重要。这与状态机相反，状态机显示状态之间的转换顺序，但不显示相对于时间尺度的转换。

下面列出了使用此模式时可能需要执行的一些操作：

• 更改图表的名称以适应计划。
• 更改类的名称以适应计划。
• 重命名这些状态并添加其他状态，以对类可以采用的重要状态进行建模。
• 更改图表的时间刻度。

下面列出了使用此模式时可能需要执行的一些操作：

• 向任何转换添加时间限制、持续时间限制和观察。
• 将类跟踪到模型中的其他元素。
• 使用文档生成器创建文档。

Basic Activity Diadram with Decisions

具有决策的基本活动图

带决策的基本活动图模式创建元素和一个活动图，其中包含一系列由控制流连接的动作，这些动作指示触发动作的顺序。决策用作异或，表示将仅遵循一个控制流来确定警卫队的值

如图.显示了一个活动图，其中包含通过控制流连接的多个动作和控制节点（初始，最终，决策）。

讨论
目的是允许业务分析人员和其他利益相关者通过定义一系列操作来创建活动如何执行其工作的直观表示。顺序由“控制流”关系显示。该决定用于表示仅遵循一个控制流。警卫队表达了需要满足的条件或遵循的控制流程。

它通常在计划的分析阶段中使用，以显示活动描述的工作如何通过一系列动作来执行。通常不会为每个活动创建图表，而是为一小部分图表，这对于阐明工作的执行方式很重要。

以下是使用此模式时可能要执行的一些操作的列表：

• 重命名元素和图表以适合该计划。
• 重命名动作和伪节点（初始，最终，决策等）以适应主动性。
• 在需要扩展图的语义的地方添加其他元素。

以下是使用此模式时可能要执行的一些操作的列表：

• 添加对象节点（使用引脚）以显示信息已由操作使用和创建。
• 创建与组件的跟踪关系，这些组件将最终执行活动和操作定义的工作。
• 创建文档，以帮助将图表中包含的信息传播给其他团队成员。

Basic Sequence Diagram with Asynchronous Message

具有异步消息的基本序列图

具有异步消息模式的基本序列图创建了元素和序列图，该图描述了一个参与者和两个组件的交互，显示了消息的时间顺序调用。在交互所代表的时间内，发送一条消息来创建一个类，一旦它在交互中扮演了它的角色，就会发送另一条消息来销毁它。

该图显示了一个序列图，一个参与者和两个组件的交互，以及它们交换的消息，包括创建、利用和销毁类的消息。

讨论

使元素之间的相互作用可视化。设计人员和实现团队通常创建序列图，作为设计工具或用于文档目的。该模式允许建模者展示如何创建资源，例如类，一旦它们在交互中达到了目的，就可以销毁它们。消息序列通常可以通知设计决策或使操作系统中发现的问题变得清晰。

该模式通常在设计或实现阶段使用，但也可以在计划完成并需要文档记录时使用。它可用于：

• 在这种情况下，call对象不需要等待消息被回复，并且可以立即继续处理。

下面列出了使用此模式时可能需要执行的一些操作：

• 更改参与者和组件的名称以适应方案。
• 更改图表的名称以适应计划。
• 更改组件中定义的操作的名称以适应方案。
• 更改在交互过程中创建的类的名称。

下面列出了使用此模式时可能需要执行的一些操作：

• 扩展该图以包括反映需要分析的序列的其他元素。
• 创建在交互过程中需要使用的其他类和其他元素。
• 使用可视化执行分析器自动创建序列，并构建、调试、记录、分析实现的系统。

Basic Use Case Model with Extend

扩展的基本用例模型

带有扩展模式的基本用例模型创建元素和描述用户角色希望从系统中实现的目标的用例图。用例都包含在系统边界内，参与者都在边界之外。扩展关系允许一个用例在指定的点通过另一个用例中定义的交互来扩充。

该图显示了一个用例图，其中包含参与者和系统边界中包含的多个用例。扩展关系是用从扩展用例指向基本用例的箭头来定义的。

讨论
其目的是允许业务分析师和其他涉众描述参与者（用户扮演的角色）在与系统交互时想要实现的价值。

该模式通常用于计划的分析阶段，可用于实现任意数量的需求，并作为为实现团队提供规范的一种方式。它可用于：

• 在指定点（扩展点）和特定条件下扩展基本用例的行为。

下面列出了使用此模式时可能需要执行的一些操作：

• 更改系统边界的名称以适应方案。
• 更改参与者和用例的名称以适合该方案。
• 添加描述来描述用例提供的价值。

以下是应用该模式时的一些后续步骤的列表：

• 使用场景生成器定义一个或多个用例中的详细步骤。
• 生成一个行为图，直观地描述详细的步骤。
• 在用例和需求之间创建跟踪关系。
• 在用例和实现它们的组件之间创建实现关系。
• 使用扩展、包含和泛化关系构建用例模型。

Sequence with Object Creation and Destruction

对象创建和销毁的序列

具有对象创建和销毁模式的序列创建元素和序列图，该图描述了一个参与者和两个显示消息按时间顺序调用的组件之间的交互。在交互所代表的时间内，发送一条消息来创建一个类，一旦它在交互中扮演了它的角色，就会发送另一条消息来销毁它。

该图显示一个序列图，一个参与者和两个组件的交互，以及它们交换的消息，包括创建、利用和销毁类的消息。

讨论

使元素之间的相互作用可视化。设计人员和实现团队通常创建序列图，作为设计工具或用于文档目的。该模式允许建模者展示如何创建资源，例如类，一旦它们在交互中达到了目的，就可以销毁它们。消息序列通常可以通知设计决策或使操作系统中发现的问题变得清晰。

该模式通常在设计或实现阶段使用，但也可以在计划完成并需要文档记录时使用。它可用于：
在交互中的一个定义点上对对象的创建和随后的销毁进行建模。
下面列出了使用此模式时可能需要执行的一些操作。

• 更改参与者和组件的名称以适应方案。
• 更改图表的名称以适应计划。
• 更改组件中定义的操作的名称以适应方案。
• 更改在交互过程中创建的类的名称。

下面列出了使用此模式时可能需要执行的一些操作。

• 扩展该图以包括反映需要分析的序列的其他元素。
• 创建在交互过程中需要使用的其他类和其他元素。
• 使用
  可视化执行分析器自动创建序列，并构建、调试、记录、分析实现的系统。