指南:业务工作者
业务工作者代表在业务中进行操作的人员、软件或硬件(或它们的组合体)的抽象。本指南说明如何确定业务工作者并对他们建模。
关系
主要描述

说明

业务工作者代表在业务中进行操作的人、软件或硬件(或它们的组合体)的抽象。业务工作者对象与其他业务工作者对象进行交互,并操纵业务实体对象,以实现业务用例实例。

业务工作者是在它相应的用例实例工作流程启动时被实例化的(在业务工作者与人绑定时“充当工作者”),或者,最迟恰好是在对象在用例实例实现中扮演其角色时启动的。在执行业务用例实现的过程中,业务工作者对象通常都“存在”(例如,相关的人员)。

当您选择将人员工作者与业务工作者角色绑定时,还将映射创建到业务建模中的 RUP 工作者角度(请参阅概念:系统体系结构)及其扩展中以及人力资源视图中(请参阅概念:业务体系结构)。在考虑业务工作者的属性、操作和特征以确保它们在组织内可支持时,这一点很重要。

属性

人员业务工作者必须具有其必须遵循的核对表。他还可能含有执行业务用例时为其他角色或业务实体提供的信息,例如他的安全级别、电子邮件地址等。

既可在业务工作者的文本描述中含蓄地描述这种信息,也可将该信息作为业务工作者的属性进行明确地建模。

属性是有一定类型的。属性有一个名称,最好是一个描述与类相连的属性角色的名词。属性类型可能或多或少地比较原始,它由简单的数字或字符串开头。不同的类可以有相同结构的属性。这些属性应共享一个描述;即,它们应共享属性类型。

属性可能或多或少比较有形。例如,您可能将某个业务工作者在执行业务用例时必须牢记的信息作为属性进行建模。例如,经过培训的海关代理人会牢记特征“可疑行为”以确定某些要单独进行质询的人。

注意:应当只有使业务工作者更易于理解时才对属性建模!

操作

业务工作者提供的操作代表将由该类实例执行的特定任务。业务工作者的操作是由另一个业务工作者对象或参与者发出的消息启动的。操作有名称和(可选)参数

操作描述了可能要求业务工作者执行的任务。它由消息启动。要在用例实现中扮演角色,业务工作者要执行一个或多个任务。

设计业务工作者时(即,在定义业务工作者必须能够执行什么工作以生成业务用例的预期结果时),有两种可选择的方法:

  • 撰写工作的一般文本描述。
  • 以操作的形式显式定义每个任务,而后应以文本形式描述该操作。对于每个操作,您定义什么消息启动它的执行。

每个操作都是由一个名称(该名称应描述操作的目的)和(可选)很多参数定义的。参数指定了类的对象应期望从正在请求支持或正在作出访问的对象接收什么,以及当操作执行完毕时对象将提供什么。例如,您可以给出一些参数,它们反映业务工作者应何时执行操作的特定步骤,或者业务工作者应何时通过启动某个业务实体操作来访问特定业务实体。参数还可以代表能够交换的切实存在的事物。

根据用例中详细信息的重要性或必需的级别,可对操作进行非正式地或更详细地定义。“更详细”的描述可能会描述行为序列,它说明在行为的执行过程中要处理的属性和关系、如何联系其他类的对象以及如何终止行为。

业务工作者特征

业务工作者的特征对关于应选择什么样的工作者来扮演角色具有实际约束。例如,在业务工作者是人的情况下,可能会考虑以下问题:

  • 先前的知识和经验
  • 物理特征
  • 社会和物理环境
  • 作业、任务和需求
  • 认知特征

角色的成功扮演可能依赖于扮演者要满足这些条件或者适应于特定环境。

同样,对于软件系统和一般系统,也会就它们是否适用作出约束,例如,关于性能、容量和响应能力的约束。

优秀业务工作者的核对表

  • 实体名称和描述清晰易懂。
  • 每个业务工作者与它必须了解的业务实体有关联。
  • 每个业务工作者与它进行沟通的其他业务工作者间有链接。
  • 业务工作者的种种关系并不相互依赖。
  • 每个业务工作者至少参与一个业务用例实现。
  • 每种关系至少在一个业务用例实现的工作流程中使用。
  • 业务工作者的每个操作至少在一个业务用例实现的工作流程中执行。