我试图描述一个用例,系统中的几个actor可以执行相同的活动。 e.g。
让我们说(作为一个例子)我想让用例“更新客户端”,但是几个已确定的参与者可以做到这一点。
Manager
Chief Executive
Customer Service Representative
System Administrator
Clerk
- 我是否需要通过他们扮演相同用例的角色描绘所有这些角色?
Manager ------------------------------> |-----------------|
Chief Executive ----------------------> | |
Customer Service Representative ------> | (Update Clients)|
System Administrator -----------------> | |
Clerk --------------------------------> |_________________|
- 我是否需要为每个演员制作不同的用例?
|-----------------|
| |
Manager ------------------------------> | (Update Clients)|
| |
|_________________|
|-----------------|
| |
Chief Executive ----------------------> | (Update Clients)|
| |
|_________________|
...
|-----------------|
| |
Clerk --------------------------------> | (Update Clients)|
| |
|_________________|
我是否需要通过使用“普通”演员来全球化所有演员(如果是这样,我该怎么做?)?
|-----------------|
| |
General Actor ------------------------> | (Update Clients)|
| |
|_________________|
答案 0 :(得分:2)
这个问题可能有更多方法,但遵循建议似乎最符合逻辑。
在这种情况下,您应该只使用一个带名称的Actor,例如User
。作为演员,你不会在公司中增加所有不同的职位。
但这并不意味着你必须总是只有一个Actor,见下图:
将用例绑定到业务流程图更为重要。因此,您可以记录支持业务流程所需的所有用例。
从BPMN模型到用例的链接很重要,因为您可以记录,用户需要使用系统的情况/过程。有些事情发生在建模系统(IS)之外,需要运行特定的用例。
但是用例与程序中的类或方法不同。当您查找用例时,您可能会在第一阶段和第二阶段对其进行建模,以寻找它们之间的关系 - 请参阅图片"检查客户数据","编辑客户&# 34;和"编辑客户资料"所有包括"更新客户端"用例。
所以我认为你不必担心你建模的用例比最后程序中的屏幕或方法要多。稍后您可以使用Include,Extends ...对用例内部进行建模,然后您可以记录它们的共同点。
答案 1 :(得分:-1)
创建一个新的actor,其他所有用户都可以从中扩展,因此关联关系适用于扩展的actor。阅读有关泛化的更多信息。