工作产品 (工件):操作
该工件表示可以从对象请求以实现某种行为的服务。操作指定名称、类型、参数和约束,以调用相关行为。
用途

操作主要用于获取某个元素支持或需要的、已提供的必需服务。

关系
容器工件
角色负责人: 修改者:
输入至必需: 可选:
外部:
主要描述

操作规范概括了以下内容:

  • 描述
  • 输入/输出参数
  • 非功能需求:
    • 这些需求是从一些非功能需求(与该操作支持的各种用例中的步骤相关联)派生的。
    • 可能无法获取使用操作的环境(即,某个特定用例)(例如,它可能是在考虑所有用例时就支持最低性能需求而言指定的)
  • 前置条件
  • 后置条件
  • 上级系统可跟踪性
  • 可选:用例(步骤)可跟踪性

在大多数情况下,操作是为正在开发的系统以及主要的子系统定义的,并以递归的方式按需要的深度进行分解。根据考虑的(子)系统的主要职责围绕接口对操作进行分组。

根据详细程度和使用环境,不同角色指定、定义、优化操作或将操作用作他们的相关任务的主要输入:

  • 架构设计师将描述在体系结构方面具有重要意义的元素所支持的主要服务。
  • 分析人员将与架构设计师一起工作,将用例步骤映射到系统操作中。
  • 设计人员会将它们用作改进阶段和重构阶段的输入,操作作为接口设计规范的构建块。
  • 测试员将根据指定的操作得出他们的测试用例。
  • 管理员会将它们用作阶段和迭代规划的基础。
属性
可选
已计划Yes
关键注意事项
设计人员负责操作集的完整性,确保:
  • 操作是唯一的并且操作之间不存在重叠
  • 围绕着接口对相关操作逻辑地进行了分组
  • 正确地记录每个操作
  • 与其他操作的可跟踪性关系和/或已确定的用例步骤
  • 根据当前迭代的范围,正确地包括用例或系统操作
定制
说明选项

基于操作的方法是定义系统及其主要子系统所支持的服务的更正式、更严格的方法。通常从系统用例开始,因此假定操作将与用例一起使用。

主要定制决策为:

  • 是否仅描述在体系结构方面重要的操作(与最重要的用例相关的那些操作)?
  • 系统逻辑分解应执行到何种“深度”?
  • 是否完整描述前置条件和后置条件?
  • 是否需要保持操作与系统操作和/或用例之间的可跟踪性?

如果需要生成“接口设计规范”,则操作(将作为这些规范的一部分)的细部和形式化级别将提升至可在其中将结果工件用于实施和测试的位置。