【发布时间】：2015-11-18 08:31:55
【问题描述】：
案例（详细）：用户在android应用程序中选择一些文件并向WebService发送SOAP请求以将所选文件设置为收藏夹。
案例（寥寥数语）：用户想将一些文件设置为收藏夹
序列图是：
User-->FileBrowser-->WebService-->DbManager-->Database
那么，下图是正确的还是我遗漏了什么？
【问题讨论】：
【发布时间】：2015-11-18 08:31:55
【问题描述】：
您的图表看起来不错。但是，我从您的另一个问题中注意到，您现在正在混合业务和技术方面。如果你想为业务做一个用例综合（这是最常见的应用），你不能开始混合技术方面。话虽如此，登录不是业务用例。用例简短地描述了参与者在应用它时获得的附加值。在业务层面上，登录只是一个约束，因为它不会增加任何价值。
作为建议：
- 从纯业务角度的用例开始。
- 想想什么才是真正的增值。
- 哪些是利益相关者？
- 他们有什么要求？
- 哪些需求可以综合到用例中？
只有在那之后才开始技术设计。因为您可以在技术级别上使用用例，您可以将登录用例描述为身份验证子系统的一部分。
【讨论】：
你不应该包括某种系统，用户和服务器在它之外吗？我的老师总是对涉及该系统发表评论。 列出系统外的所有用户。用例可以回答：“系统将做什么？”。数据库是否被外部用户/系统使用？在这种情况下，最好将其表示为单独的演员。
也许是在制作用例图之前先写一个完整的用例。
【讨论】：
-
是的，将考虑中的系统 (SUC) 显示为边界是一个优点。仔细观察，用例在 SUC 的边界上，因为它们代表了参与者和 SUC 之间的通信。但将 UC 放在 SUC 边界内也很常见。
两件事不符合UML：
- 包含依赖项应该有一个指向“选择文件”的开放箭头。
- include 一词必须用 «guillemets» 括起来
建议：
- 对用例使用一致的命名约定。通常使用命令式风格，至少有一个动词和一个名词，例如“选择文件”和“选择喜欢的文件”。
- 围绕用例绘制系统边界（矩形），将参与者留在边界之外。在边界内输入描述性名称，例如“Android 应用”。
【讨论】：