工件:业务操作
对象可请求来实现某种行为的服务。操作指定名称、类型、参数和约束,以调用相关行为。
工作产品类型:模型元素
用途

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

关系
描述
主要描述

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

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

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

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

  • 业务架构设计师将描述由体系结构上重要的元素支持的主要服务。
  • 业务分析员将与架构设计师一起工作,将业务用例步骤映射到系统的操作。
  • 业务设计人员将在优化和重构阶段将它们用作输入,操作作为接口/合同规范的构建块。
关键注意事项
业务设计人员负责操作集的完整性,确保:
  • 操作是唯一的并且操作之间不存在重叠
  • 相关操作围绕接口进行了逻辑分组
  • 正确地记录每个操作
  • 已建立了与其他操作和/或业务用例步骤之间的可跟踪性关系
  • 根据当前迭代的范围,正确包括业务用例或系统操作
定制
说明选项

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

主要定制决策为:

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