Seven's Pad

Just another Product Blog site

UML核心元素之参与者

leave a comment »

参与者(actor)在建模过程中是处于核心地位的。UML官方文档对参与者的定义为:actor是在系统之外与系统交互的某人或某物。系统之外的定义说明在参与者和系统之间有一个明确的边界,参与者只可能存在于边界之外,边界之内的所有人和事物都不是参与者。

按照定义,要弄明白谁是参与者首先要弄明白系统的边界。但有时系统边界是不明确的,如何确定系统之外和系统之内呢,可以通过回答正面两个问题来找出参与者从而确定边界:

  1. 谁对系统有着明确的目标和要求并且主动发出动作?
  2. 系统是为谁服务的?

实际上在官方文档中,参与者还有另外一种叫法:主角。系统之内的人“参与”业务,被称之为业务工人。

参与者可以非人

任何需求都必须至少有一个启动者,如果找不到启动者,那么可以肯定地说这不是一个功能性需求。

如何发现参与者

参与者的一个重要来源是涉众,从涉众中找出那些直接对系统发出动作,或直接从系统中接收反馈的涉众,若无一个好的涉众分析作参考,那么参与者的另一个可参考来源是客户的岗位设置。如果客户的岗位设置还不足以搞清楚参与者,那么需要做的是与客户代表访谈,并为他假定一个参与者,列出他在系统中要做的事情;再与另一些客户代表访谈,假定其他的参与者和其他客户在系统中要做的事情。通过分析这些假定的参与者在系统中要做的事情,找出共同性,并与客户敲定。

在查找参与者的过程中,可以询问以下问题以帮助确定参者:

  • 谁负责提供、使用或删除信息?
  • 谁将使用些功能?
  • 谁对某个特定功能感兴趣?
  • 在组织中的什么地方使用系统?
  • 谁负责支持和维护系统?
  • 系统有哪些外部资源?
  • 其他还有哪些系统将需要与该系统进行交互?

查找参与者时需要注意的是参与者一定是直接并且主动地向系统发出动作并获得反馈的,否则就不是参与者。

业务主角

业务主角(business actor)是参与者的一个版型,特别用于定义业务的参与者,在需求阶段使用。业务主角是与业务系统有着交互的人和事物,他们用来确定业务范围(注:在软件项目里,业务范围和系统范围是不同的。业务范围反映这个项目所涉及的所有客户业务,这些业务有没有计算机系统参与都客观存在。系统范围则是反映软件将要的那些对应于业务功能的系统功能从功能性需求来说系统范围是业务范围的一个子集。但是一些系统功能则会走出业务范围,例如担任日志。有没有操作日志并不影响目标的达成,客户也不一定会提出这个要求,但从系统角度出发,操作日志会使得系统更加健壮)。业务主角是参与者的一个版型,所以业务主角必须遵守参与者的所有定义。

业务主角的特殊性在于,它针对的是业务人员而计算机用户。在查找业务主角时必须抛开计算机,没有计算机系统这些业务人员也客观存在,在引入计算机系统之前他们的也一直跑得很顺畅。这是因为在初始需求阶段,我们需要获得的是客户的业务模型,根据业务模型才能建立计算机模型。如果在了解业务阶阶段就引入计算机的概念,将会混淆现有业务和将来有计算机参与时的业务。请记住,要建立一个符合客户需要的计算机系统,首要条件是完全彻底地搞清楚客户的业务,而不是预先假设已经有了一个计算机系统,再让客户来假想需要计算机帮他们做什么。

在初始需求阶段,请务必使用业务主角,时时牢记业务主角是客户实际业务里的参与者,而没有计算机系统,没有抽象的计算机角色。业务主角必须在实际业务里能找到对应的岗位或人员。如果你对获得的业务主角不是很自信,请回答以下问题:

  • 业务主角的名称是否是客户的业务术语?
  • 业务主角的职责是否在客户的岗位手册里有对应的定义?
  • 业务主角的业务用例是否都是客户的业务术语?
  • 客户是否对业务主角能顺利理解?

业务工人

业务工人(business worker)处于系统边界之内且确实参与了业务的执行过程。

作为配角,他们的工作就是完成主角的业务目标,只在主角的业务模型中出现,经常出现的地方是领域模型和用例场景。缺少了他们的业务场景就不完整,甚至不能 运行。只有主角没有配角的戏没法演。可通过下面三个问题帮助澄清:

  • 他是主动向系统发出动作的吗?
  • 他有完整的业务目标吗?
  • 系统是为他服务的吗?

这三个问题如果是否定的。那一定是业务工人。

参与者与涉众的关系

涉众(stakeholder),也称为干系人。涉众是与要建设的这个系统有利益相关的一切人和事,涉众的利益要求会影响系统的建设。只要和这个系统有利益关系的都是这个项目的涉众。涉众虽然与这个系统有利益相关,但并不是所有的涉众都是系统的参与者。

参与者是涉众代表。参与者对系统的要求直接影响系统的建设,他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众的利益。

参与者与用户的关系

用户(user)是指系统的使用者,通俗一点说就是系统的操作员,用户是参与者的代表,或者说是参与者的实例或代理。并非所有的参与者都是用户,但是一个用户可以代理多个参与者。

参与者与角色的关系

角色(role)是参与者的职责。角色是一个抽象的概念,从众多参与者的职责中抽象出相同的那一部分,将其命名而形成一个角色。一个角色代表了系统中的一类职责。另外由于一个用户可以代理多个参与者,因此一个用户可以拥有多个职责,也就是可以被指定多个角色。

参与者的核心地位

从上面的描述中可得知,参与者是涉众的代表,它代表涉众对系统的复兴要求,并向系统提出建设要求;参与者通过代理给其他用户或将自身实例化成用户来使用系统;参与者的职责可以用角色来归纳,用户被指定扮演哪个角色因此来获得参与者的职责。

检查点

  • 是否您已找到所有的参与者?也就是说,是否您已经对系统环境中的所有角色都进行了说明和建模?这个得要到找到并说明了所有用例之后才能将其确定。
  • 每个参与者是否至少涉及到一个用例?删除未在用例说明中提及的所有参与者,或与用例无通信关系的甩有参与者。
  • 能否列出至少两名可以作为特定参与者的人员?如果不能,请检查参与者所建模的角色是否为另一个角色的一部分。如果是这样,应该将该参与者与另一参与者合并。是否有参与者担任与系统相关的相似角色?如果有,应该将他们合并到一个主角中,通信关联关系和用例说明参与者和系统是如何相互关联关系的。
  • 是否有两个参与者担任与用例相关的同一角色?如果有,您应该利用参与者泛化关系来为他们的共享行为建立模型。
    特定的参与者是否将以几种(完全不同的)方式使用系统?或者,他使用用例是否出于几个(完全不同的)目的?如果是这样,您也就应该有多个参与者。
  • 参与者是否有直观名称和描述性名称?用户和客户是否都能理解这些名称?参与者的名称要与其角色相符,否则应该对其进行更改。
Advertisements

Written by sevenpad

06/18/2010 在 10:38 下午

发表在 产品相关

Tagged with , ,

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: