场景:(某种呼叫中心）（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
想知道图表右侧是否应该有一个代表数据库的演员？我错过了什么吗？您如何知道自己已完成用例图？
答案 0 :(得分：4)
演员不包含在系统中，它们是系统的外部。通常，DB在系统中，而不是演员。
例如，在您的情况下，如果技术人员必须知道如何去顾客，则辅助演员可以是谷歌地图，为此他必须看到旅行的地图。在这种情况下，在用例期间，会到达谷歌地图以获取地图。
我知道确保UC完成的唯一方法是审核它们和/或获取客户需求列表并跟踪客户对UC的需求。
希望得到这个帮助。
更多： @Kilian关于功能的评论是一个非常好的评论。通常在我们开始时，我们将用例视为“实现功能的工作流程”或所有用户界面菜单的集合而不是这样。
所以@Waren，我可以建议：
首先尝试使用标题和paragph定义系统，以确定系统的主要任务。系统不仅是您要编写的代码，还包括将为其部署的所有代码（机器，虚拟机，数据库，托架，swicht，过程，DDL，配置文件等）
然后定义系统必须满足的需求，高级别需求（iso术语应见enter link description here）
然后定义actors / stackeholder和继承层次结构以确定所需的角色和权限。不要忘记所有操作需求（监控，备份/恢复，DRS程序，报告，部署等）
然后定义您的用例思维特征或单个附加值并检查整体一致性。关于UC的一个好处是描述“错误/异常”情景。
然后有趣的一点是定义系统模式：安装，生产前的测试，生产，更新/补丁，维护，系统停止和删除。就像那样，您将确保涵盖整个系统生命周期。