任务:操作设计
此任务将“操作分析”的结果优化至详细的“操作实现”中。
用途
  • 在设计模型中,将初级子系统交互优化为“操作实现”。
  • 优化和指定子系统操作。
关系
角色主要: 其他: 辅助:
输入必需: 可选:
外部:
输出
步骤
创建操作实现

任务:操作分析中,设计人员在分析模型中创建了子系统交互(没有很多详细信息)。您记得已针对这些交互的详细程度进行了组织,以使之按“系统操作”进行分组,即:您已记录了用于实现每个“系统操作”的交互。现在要处理扩展(白匣)系统用例描述,已添加了消息、已交换实体、排序和控制流的详细信息以及相关数据,并且已在“设计模型”中捕获了生成的“操作实现”,且再次按“系统操作”进行了组织。添加该详细信息后,设计人员可评估紧急协作的质量,寻找重构设计的机会。使用子系统在处理消息(从白盒步骤描述得出并在需要时进行了优化)时所执行的操作的描述来注释操作实现。这些描述有助于在下一步骤制定每个系统操作的规范。

聚集相似子系统白盒步骤和指定子系统操作

设计人员在执行“操作分析”任务期间生成了初始“子系统操作调查”占位符。调查表还(以灰色背景)显示了回溯至系统用例黑匣步骤的可跟踪性,(以表格形式)指示了系统用例黑匣步骤 <标识 1> 和 <标识 2> 都通过调用 <系统操作名称 1> 执行。

子系统 <名称>
系统操作 系统用例黑匣步骤标识 位置 流程 工作者 子系统白匣步骤描述 子系统操作

<系统操作 名称 1>

<标识 1> 位置标识 流程标识 组织或系统工作者标识 (白匣步骤标识):描述了子系统执行的操作(执行部分黑匣步骤),以输入、处理、输出形式表示 (子系统操作标识):此步骤调用的子系统操作的名称,例如:“«子系统操作» 启动销售列表”(适用于子系统订单处理
... ...   (白匣步骤标识):...  
... ...   ...  
<标识 2> ... ...   ...  
<系统操作名称 2> <标识 3> ... ...   ...  
<标识 4> ... ...   ...  
... ... ... ...   ...  

子系统操作调查示例。

接下来,执行白盒步骤和操作实现,确定了子系统操作并指定了它们的行为。而在确定系统操作时,每个白匣步骤可能没有唯一对应的子系统操作;也就是说,在检查这一组白匣步骤及与其关联的消息、输入-输出实体等交换时,您可能会发现可以定义较小的一组子系统操作来满足其需求。

请注意,也可按位置或流程来对调查表重新排序,以显示一组子系统操作与每个位置或与每个流程的关联。位置排序指明了某个位置上的计算负载(因而这对推测支持该位置的物理组件的容量很有用)。在此表单中,按位置排序的调查将成为部署模型的属性。

当在多个位置安排子系统操作时,这表示至少复制了子系统的一部分。这并没有暗示这些复制的部分必须共享数据和保持同步。这些设计选择依赖于复制所用的应用程序和复制原因;例如,所需的处理可能相同,但用于不同的业务部分。在极端的情况下,可在多个位置安排所有子系统操作,这意味着有效复制子系统本身。是否需要唯一确定复制实例也依赖于复制的原因。

流程排序使设计人员能够推断并行问题:如果您将子系统操作视为参与者可用的一项离散功能,那么第一项推测是:与同一流程关联的操作无法并行执行。这可能会使得设计人员重新考虑流程分配,或考虑流程复制,或者以较低的详细级别检查察觉到的延迟问题(例如:通过检查时间分片选项),以及在操作发生阻塞(例如执行输入输出)时检查流程共享。使用这些技术可获得可接受的响应速度,而启动操作(严格说是序列化操作)的延迟可能令人无法忍受。在此表单中,按流程排序的调查将成为设计模型的属性。

为您已完成的操作添加脚注

对于每个子系统,您已经:

  • 定义它的操作
  • 定义您期望该子系统支持的接口
  • 描述了该子系统与其他子系统如何协作来实现系统用例
  • 定义了子系统环境:它的参与者、接口和 I/O 实体

因此,您已做好准备,能够将该组工作产品移交以进行独立开发(如果您选择这样做),或者在“需求规程”中重新调用 RUP 任务,以按递归方式执行进一步分解。

属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息