创建用例图.我是不是把事情复杂化了？

Question

场景：(某种呼叫中心) (1)客户请求技术人员。(2)请求排队等待技术人员查看。(2b)客户获得关于提交数据的确认电子邮件(3)技术员处理请求(3b)每个人都收到电子邮件(4)请求完成(5)技师为已完成的请求(6)关闭请求提交数据。

所以左边有两个演员。不是每件事都要连在一起的对吧？因此，对于客户来说，获取电子邮件和提交数据是被绘制的。对于技术员演员，他们有处理互动，提交数据和收到电子邮件。

我正在阅读关于UML的文章：http://www.soberit.hut.fi/T-76.115/01-02/palautukset/groups/Fireball/t2/docs/UseCaseMethod.html

想知道图的右边是否应该有一个代表数据库的参与者？我有遗漏什么吗？您如何知道您是用例图完成的？

Answer 1

行为者不包括在系统中，他们是系统的外部成员。通常，DB在系统中，而不是参与者。

例如，在你的例子中，如果技术人员必须知道如何与客户打交道，那么第二个演员可能是谷歌地图，因此他必须在旅行中看到一张地图。在这种情况下，在用例中，可以到达google地图来获取地图。

我知道确保完成UCs的唯一方法是检查它们和/或获得客户需求的列表，并使用UCs跟踪客户需求。

希望能帮上忙。

更多的是：“基连”关于函数的评论是非常好的。通常，当我们开始的时候，我们认为用例是“实现一个功能的工作流”，或者是所有用户界面菜单的集合，但事实并非如此。

所以我可以建议：

• 首先，尝试用一个标题和一个副总来定义该系统，以确定该系统的主要任务。系统不仅是您将要编写的代码，而且是为它部署的所有代码(机器、虚拟机、db、bays、swicht、过程、DDL、配置文件等等)。
• 然后定义系统必须满足的高层次需求(iso术语见在这里输入链接描述 )。
• 然后定义参与者/堆栈持有者和继承层次结构，以显示所需的角色和权限。不要忘记所有的操作需求(监视、备份/恢复、DRS过程、报告、部署等等)
• 然后定义您的用例、思考特性或单个附加值，并检查整个一致性。UC的一个好地方是描述“错误/异常”场景。
• 然后，一个有趣的点可能是定义系统的模式:安装、生产前的测试、生产、更新/补丁、维护、系统停止和删除。就像这样，您将确保涵盖整个系统生命周期。