GA006-181-15

1.Composite Requirement Hierarchy
复合需求层次结构模式创建元素和图表，这些元素和图表允许将需求层次结构定义到任何级别，从而允许从一个级别的需求向下钻取（单击）到另一个图表，在层次结构的下一个级别显示其子需求。

上图显示子需求的需求图，其中一个子需求有一个复合标记，表示可以双击它来显示层次结构中的下一个级别。

上图显示项目浏览器的结构，指示子需求和描述它们的关系图嵌套在父需求下。
讨论
其目的是提供一种可视化一组需求的结构的方法，一次一个级别地显示一个或多个需求具有元素右下角的标记所指示的子级。复合模式可以应用到任何级别。

当一个系统工程师需要显示一个需求层次结构的单一层次，但又想指出这些需求是由其他需求组成的，从而允许向下钻取到其他层次。

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

1.1重新命名图表。

1.2重新定义要求，以适应倡议。

1.3添加详细说明，说明需求的业务或系统重要性。

1.4更新需求的属性，以适应计划。

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

1.通过组合其他需求来扩展层次结构。并在其下创造新的需求。

2.定义跟踪关系，显示需求与向上流程元素（如策略、业务规则和其他需求）和向下流程元素（如用户情景、用例、组件、工件和数据库表）的关系。

3.创建从模型自动生成的高质量文档。

2.Basic Use Case Model

基本用例模型模式创建元素和用例图，描述用户角色希望从系统中实现的目标。用例都包含在系统边界内，参与者都在边界之外。

上图显示了一个用例图，其中包含参与者和系统边界中包含的多个用例。一个参与者表示一个系统，并使用矩形表示法。
讨论

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

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

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

1.1更改系统边界的名称以适应倡议。

1.2更改参与者的名称和用例，以适应方案。

1.3添加描述来描述用例提供的价值。

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

1.1使用Scenario Builder在一个或多个用例中定义详细的步骤。

1.2生成一个行为图，直观地描述详细的步骤。

1.3在用例和需求之间创建跟踪关系。

1.4在用例和实现它们的组件之间创建实现关系。

1.5使用扩展、包含和泛化关系构建用例模型。

3.Nested States

嵌套状态模式描述了一个块或其他元素，该元素具有多个状态，其中一个或多个状态本身具有状态（子状态）。模式允许这些状态显示在同一个图表上。

上图一种状态机图，显示其中一种状态中的嵌套状态。
讨论
其目的是允许系统工程师在一个图表上创建两个（或更多）级别状态转换的可视化表示。
当执行转换的遍历以了解所属元素的行为时，或者当将嵌套状态放置在同一个图上时，这种表示通常很有用，无需单击组合图就可以更容易地理解状态之间的转换。
1.1重新命名图中的状态和转换，以适合您的计划。
可以将新的元素和其他元素从“项目关系图”或“浏览器”的“连接件”或“其他状态”拖到“浏览器”1中。
以下是应用该模式时的一些后续步骤的列表。
1.1根据图表创建可执行状态机。
1.2显示此状态机中的状态如何与为模型中其他元素构造的其他状态机中的状态交互。

4.Two Level Block Hierarchy

两级块层次结构模式通过使用两种不同的线样式定义组成块的块来描述给定块的结构。可以添加描述运行系统中允许的实例数的角色名和多重性。

上图是一种块定义图，它使用两种不同的线样式将块分为两个层次，以帮助使图更具可读性和紧凑性。
讨论
目的是描述一个块的组成，这样就可以理解它，推理它的结构，并且可以创建更详细的模型。此模式允许将块分解为两个级别，使系统工程师能够描述和可视化单个块的结构。

1.当一个块不是原子的，并且需要描述它的结构时，使用模式，以便它所组成的块可以被推理或向下描述到层次结构的两个级别。
2.它是内部框图的一个有用的前奏，其中块的内部结构可以用组成它的部件来描述。
下面列出了使用此模式时可能需要执行的一些操作。
1.1更改图表和方块的名称，以适应倡议。
1.2更改多重性所描述的角色和基数的名称。
1.3创建其他块以将层次结构向下扩展到另一个级别。
以下是应用该模式时的一些后续步骤的列表。
1.1向模块添加说明，以说明它们在系统描述中的作用。
1.2添加一个或多个状态机来描述特定块可能显示的离散状态。
1.3如有必要，向层级结构添加另一层。
1.4使用文档生成器自动生成文档。

5.Activity with Actions and Control Flows

带动作和控制流的活动创建元素和许多图表，这些图显示活动的层次结构，以及表示活动调用的操作如何按顺序连接在一起，以执行由所属活动描述的工作。

上图是一种活动图，示出被称为活动调用的动作序列。顺序由控制流连接器指示；动作管脚也由对象流连接。

讨论
为系统工程师或其他利益相关者提供一种方法，通过活动的执行来可视化控制流，包括动作序列、控制节点和图表中的其他元素。
虽然可以在不使用控制流连接器的情况下创建活动图，但通常需要正确指定操作的执行约束，并允许读者了解在执行所属活动期间将调用的操作序列。许多建模者认为，最好从定义控制流开始，在完全描述了执行的基本顺序后，只添加对象节点和对象流。

1.1更改包装和图表的名称，以适应倡议。

1.2通过添加或删除操作来调整图表。

1.3重命名操作、管脚和参数以适应您自己的努力。

1.4根据需要创建其他销和参数。

1.5重命名指定操作名称的关联的角色名称。

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

1.在活动和行动中添加注释，说明它们所扮演的角色。
2.定义跟踪关系，显示需求与向上流程元素（如策略、业务规则和其他需求）和向下流程元素（如用户情景、用例、组件、工件和数据库表）的关系。
3.使用内置或用户定义的模板创建从模型自动生成的高质量文档。