1

我有一个场景，客户打电话并在车库预约。在绘制 UML 用例图时，与将此约会放置在系统中相关的参与者是 (a) 客户，还是 (b) 员工？

4

3 回答 3

1

将手指放在键盘和鼠标上的人就是演员。从业务角度来看，打电话的人很重要，但不如与系统交互的客户服务代表重要。

知道参与者是 CSR 有助于屏幕设计师甚至开发人员，因为他们会从这个角度工作，从这个角度询问需求或设计说明，系统会因此变得更好。

于 2012-05-24T01:50:18.697 回答
0

存在冲突的原因是因为你开始绘制这些用例时的项目点。

在您的示例中，您已经知道有一个 CSR 使用“系统”进行预订。

然而，设计可以从头开始。如果发生这种情况，最初的广泛用例将是“客户希望进行预订”。这可能会导致许多不同的情况，即客户将拨打电话号码，自动服务将进行预订，客户到达车库并使用终端进行预订或（如您的情况）与一个企业社会责任（但是那是电话或face2face），他们进行预订。

在许多示例中，客户将是系统中的主要参与者。但是，在您的设计中，CSR 是拿着鼠标/键盘/电话/笔或其他任何东西的人，您不需要设计客户和 CSR 之间的迭代！大多数社会几年前就这样做了:)

于 2012-05-28T11:14:16.230 回答
0

两者都可以。这取决于。没有单一的好方法可以对此进行建模。我个人会选择客户。

顺便说一句，将电话作为系统的一部分包含在内是完全可以的。因此，系统的边界不必由屏幕、鼠标、键盘来定义。打印机也可能包含在系统中。我已经编写了用例，其中用户打印一些信息并将其归档是非常必要的。

谁是这里的重要演员？客户对吗？有趣的是，Alistair Cockburn 用演员和“利益”模型扩展了 Ivar Jacobson 的演员和目标模型。他的建议是，如果用户目标失败，还要考虑谁在乎（或受到伤害）。

让演员恰到好处重要吗？集思广益以找到针对系统的所有用户目标很有用。当你确信你已经找到了所有的目标时，演员就不再那么重要了。你会根据这个决定“编写”一个完全不同的用例吗？是否会根据该决定的结果构建不同的系统？

谁发起互动？是什么事件发起的呢？此事件是客户决定打电话预约。

您可以将客户建模为主要参与者，将员工建模为次要参与者，帮助客户实现用户目标。都使用电话和系统来达到目标​​，客户由员工帮助。他们如何做到这一点正是设计？

另一个考虑是“演员”是一个角色。因此，您可以使用角色 Appointment Maker。有些人非常关心将职称与角色分开，因为职称所扮演的角色通常具有一定的灵活性。

也有人认为在描述用例时使用“系统”是不可取的。他们认为这是一个设计/实施决策，因此他们更喜欢中立的“表演者”。表演者可以是一个系统，也可以是一个人。在用例文本中，他们使用“发起者”和“执行者”，在用例文本的介绍中，他们解释说“发起者”在用例中是约会制定者。

我个人认为，如果将用例描述为好像客户是操作系统的人，那会更好。员工只是将信息从系统传递给客户，反之亦然。

推荐阅读 Alistair Cockburn 的书。他的见解确实帮助我解决了这样的问题。它还有助于理解与用例相关的 UML

于 2012-06-20T13:53:12.687 回答