Uml 业务用例和正义用例

业务用例模型与用例模型之间的区别是什么？我应该为一个网站做这两个，但我不明白有什么区别。。。帮助？

也许另一种描述会有所帮助

“业务”和“系统”用例的范围不同。前者包括客户和供应商为完成目标所必须做的一切。其中有些可能涉及系统交互，但有些可能不涉及。例如，在线购买一本书。某些方面将涉及在线完成（例如浏览可用书籍、下单）。但有些不是：挑选库存、包装、装运、签收包裹

业务用例是对整个交互的“黑盒”描述（“购买书”）。完成任务意味着遵循业务流程。过程中的一些步骤将涉及用户-系统交互，而有些步骤则不涉及。如果某个步骤确实涉及用户和系统（“浏览可用书籍”），则该步骤是一个系统用例。对于给定的业务用例，通常会有许多系统用例

那么你两者都需要吗？这要视情况而定

如果您（a）负责完整的业务范围，并且（b）希望将业务能力记录为用例，那么业务UCD和支持的UC定义非常有用。UC描述中的步骤将表示业务流程

如果其他人负责业务级别的定义，那么您可能不需要这样做

最后一件事：有时两者是重合的。例如：买一本电子书。业务需要是客户能够获得他们的书籍。整个过程可以在一个单一的系统交互（选择图书、支付、接收下载）中交付，因此可以在一个单一的系统用例中涵盖。因此，业务和系统用例是等价的

hth.

这样想：

业务UC（用例）绝对不包含任何技术细节。您需要后退一步，以了解业务需求。因此，商业UCs可能类似于：

• 在线管理照片
• 创建个人日志条目
• 在线与其他用户交互
• 与其他用户共享照片

请注意，这些都没有说明将如何完成。在这一点上，它几乎是一个将所需功能的列表，并以主题限定符的形式付诸实施

您可以将它们放入带有参与者的用例模型中，这样您就有了一组非常有用的高级业务UCs。完成对低级别业务UCs的UCs及其前置和后置条件的规范。但目前还不知道路径的细节

系统UC包含这些业务UC的系统级透视图。因此，虽然在线管理照片可能描述上传照片并将其分组到相册中的需要，但系统UCs实际上可能变成：

• 上载图像（具有上载、命名、裁剪和删除的路径）
• 管理相册（具有用于创建、添加图像和删除图像的路径）

这里我们已经进入了技术细节。业务部门可能会考虑存储和交换照片，但您知道，系统感知和处理照片和位图图像的方式几乎没有什么不同。您已经开始考虑上传图像需要做些什么，以及用户可能需要对图像做些什么

---

我希望这有帮助。

Mm。。。仍然很难弄清楚这些。我正在一个社交网络项目上工作（不存在，但想想facebook之类的东西）。用户可以上传图片、制作相册、记录日志——这些是业务UC还是系统UC的一部分？我是否应该更深入一些，比如上传图片会包括命名、组织等？因为它都是在线的，所以你会有重叠。如果是那样的话，我就不会为这种差异而激动——这其实并不相关。重要的是确保在用户目标级别捕获UCs。您已经列出了一些：上传图片、制作相册、创建日志、添加日志条目等。这些都是“业务”UCs。如果您需要将任何步骤捕获为单独的UCs，您可以将其视为“系统”UCs（登录/注销是常见的示例）。然而更重要的是：因为所有的互动都是在线的，所以不要挂断。（ctd…）（…ctd）。专注于确保捕获用户的目标，记录它们，并在需要时分解为较低级别的UCs（但仅在需要时）。谢谢。我已经开始这么做了，但至少现在我知道我走在正确的道路上。：）