【发布时间】：2011-11-02 01:15:15
【问题描述】：
业务用例模型和用例模型有什么区别？我应该为网站制作两者，但我不明白有什么区别......帮助？
【问题讨论】：
标签： uml
【发布时间】：2011-11-02 01:15:15
【问题描述】：
也许另一种描述会有所帮助。
“业务”和“系统”用例的范围不同。前者包括客户和供应商为完成目标而必须做的一切。其中一些可能涉及系统交互 - 但有些可能不会。以在线购买书籍为例。某些方面将涉及在线完成（例如浏览可用书籍、下订单）。但有些不是：挑选库存、包装、运输、签收包裹。
业务用例是对整个交互（“购买书”）的“黑匣子”描述。完成任务意味着遵循业务流程。该过程中的某些步骤将涉及用户与系统的交互，有些则不会。如果步骤确实涉及用户和系统（“浏览可用书籍”），则该步骤是系统用例。通常，一个给定的业务用例会有多个系统用例。
那么你需要两者吗？视情况而定。
如果您 (a) 负责整个业务范围，并且 (b) 想要将业务功能记录为用例，那么业务 UCD 和支持 UC 定义会很有用。 UC 描述中的步骤将代表业务流程。
如果其他人负责业务级定义，那么您可能不需要。
最后一件事：有时两者是重合的。例如：购买电子书。业务需求是让客户能够拿到他们的书。整个事情可以在单个系统交互中交付（选择书籍、支付、接收下载）——因此可以由单个系统用例覆盖。所以业务用例和系统用例是等价的。
第一次。
【讨论】：
-
嗯......仍然无法弄清楚这些。我正在开发一个带有社交网络的项目（不存在，但想像 facebook 之类的东西）。用户可以上传图片、制作相册、写日记——这些是商业 UC 还是系统 UC 的一部分？我是否应该更深入一些，比如上传图片将包括命名、组织等？
-
由于它全部在线，您将有重叠。在那种情况下，我不会对差异感到兴奋——这并不真正相关。重要的是确保您在用户目标级别捕获 UC。您已经列出了一些：上传图片、制作相册、创建日记、添加日记条目等。这些是“商业”UC。如果您需要将任何步骤捕获为单独的 UC，您可以将它们视为“系统”UC（登录/注销是常见示例）。然而更重要的是：由于所有的交互都是在线的，所以不要挂断它。 (ctd...)
-
(...ctd)。专注于确保您捕获用户的目标，记录它们，并在需要时分解为较低级别的 UC（但仅在需要时）。 hth.
-
谢谢。我已经开始这样做了，但至少现在我知道我走在正确的道路上。 :)
这样想：
商业 UC（用例）绝对不包含任何技术细节。而且您需要退后一步来了解业务需求。所以商业 UC 可能是这样的：
- 在线管理照片
- 创建个人日志条目
- 在线与其他用户互动
- 与其他用户分享照片
请注意，这些都没有说明它将如何完成。在这一点上，它几乎是将所需功能的列表放入操作-主题-限定符格式。
您可以将它们与参与者一起放入用例模型中，这样您就有了一组非常有用的高级业务 UC。完成为低级业务 UC 指定 UC 的前置条件和后置条件等。但在这点上，路径的细节是未知的。
系统 UC 包含对这些业务 UC 的系统级视角。因此，虽然在线管理照片可能会描述上传照片并将其分组到相册中的需求，但系统 UC 实际上可能会变成：
- 上传图片（带有上传、命名、裁剪和删除的路径）
- 管理相册（包含创建、添加图像和删除图像的路径）
这里我们已经进入了技术细节。企业可能正在考虑存储和交换照片，但您知道系统感知和处理照片和位图图像的方式几乎没有区别。您已经开始考虑上传图片所涉及的内容以及用户可能需要对这些图片执行哪些操作。
我希望这会有所帮助。
【讨论】：