我正在开展一个小小的爱好项目，并尝试做一些不同的事情。
我正在建设的系统是一个ERP系统，包括一个产品目录，产品目录，销售数据库，销售日志（类似于数据库，但用于会计目的），打印机，支付合作伙伴和购物篮（购物车） ）。
虽然打印机是硬件，但我需要编写更高级别的代码来打印收据。
我不需要编程的唯一部分是付款合作伙伴。
我有两个问题。
1）向用户出售一堆产品的用例是一个名为“直到销售商品”的用例，或者会被分成几个，例如“添加产品到购物车”和“完成销售” “（将编写销售日志并打印收据）。
2）虽然我正在编制目录，销售数据库，销售日志，购物篮等，但我可以将它们模型化为我的用例中的演员吗？或者是销售人员和付款合作伙伴的唯一参与者？
答案 0 :(得分：3)
用例分析看似简单，但这个问题背叛了一些固有的复杂性。
每个用例必须对所涉及的参与者有意义，因为它必须代表与系统明确定义的交互。当你谈论系统时，即使使用日常语言，每个演员和用例也必须有意义。如果您发现自己难以定义演员或用例，那么系统上下文可能不清楚，因此域模型可能有所帮助。
用例必须代表明确定义的交互，但不一定是完整交互。 <<include>>关系可用于在同一级别上查看完整和部分交互用例的情况。例如，您可以考虑使用buy stuff包含browse products，add product to cart和check out <<xor>> cancel的用例。每个用例都对客户有意义。
（我对你的系统是用于物理交易还是在线交易感到有点困惑;有一个收据和打印的收据似乎暗示前者，购物车作为分析中使用的概念的一部分后者以上假设是一个在线系统。）
但是，在您的情况下，您正在谈论可能被视为系统本身一部分的演员。这通常意味着您正在尝试同时定义系统及其子系统，这在您开始分析之前很好地了解（最终）系统设计的情况下很常见。
您要做的是将分析分为两个级别。在上层（系统）层面，对整个系统的处理非常严格。在您的情况下，您可能需要参与者customer，payment partner，clerk（对于物理交易系统），accountant（也许administrator ），以及上面列出的用例以及update product catalogue，audit sales log等
然后将系统分解为子系统，并对每个子系统进行单独分析。这里的子系统可以是彼此用例中的参与者。例如，Print receipt在系统级别上不是一个有意义的用例，因为它本身并不是整个系统与系统级actor之间的交互，但它作为一个用例是有意义的。打印机子系统，以the作为演员。
在开始子系统细分之前，您不需要完成系统级分析，事实上我认为最好让它们同时处于活动状态 - 尽管这会对分析师/设计师提出更高的要求能够快速切换上下文，并在任何给定时间遵守您正在处理的上下文。
所以，毕竟（p！）我认为你的问题的答案是：
答案 1 :(得分：1)
我认为你需要先退一步。 Actors＆amp;的目的用例首先要问：“谁会使用这个系统？”和“他们为什么要用它？”。你可能开始识别，打印机等作为演员 - 事实上，其中一些可能是 - 但是你有可能会错过关键点。
根据您的描述，我猜Actors及其用例将遵循以下几行：
...等
当您为每个UC设计流程时，您可能会识别系统外部需要与之交互的其他组件 - 例如付款伙伴。如果你愿意，你可以把它们显示为演员（我的偏好不是，但这纯属个人）。
您还将识别系统中实现UC行为的其他元素（例如销售数据库等）。这些是您系统的一部分 - 通常不会显示为Actors。
总而言之：用例旨在帮助您确定系统的目的以及从中获取价值的人 - 而不是构建内部设计组件。
第h
答案 2 :(得分：1)
首先，在这一点上不要考虑编程。想想业务需求是什么。
客户需要：
系统需要：
第一个列表是您的高级用例，第二个列表可能是这些高级用例的一部分，也可能是包含。如果用例的那部分足够复杂（或者只是足够冗长），我可以使用includes来保证将它放入自己的用例中。隐藏其复杂性。
目录，销售数据库，销售日志，购物篮等是演员 - 演员与系统（或用例）互动。我很难想象一个目录与某些东西相互作用。另一方面，客户肯定会与目录进行交互。
演员必须在现实世界中活跃。如果系统代表现实世界中的某些东西，则系统可以是演员。但在现实世界中，目录是惰性的;篮子是惰性的。销售日志和销售数据库代表纸质记录 - 这些记录是惰性的。他们的对象不是演员。
BTW - 是系统的销售人员吗？答案 3 :(得分：0)
用例不是绝对的。你可以在你的系统的第一个草图中有一个模糊的用例，例如Manage Users（我不确定托管案例是一个很好的做法，但这是为了一个例子......）然后打破它更详细的用例图表一直在改进，直到你进入一个基本功能。
至于你的第二个问题，这些听起来像典型的域对象（被建模为基本类图）。除非他们发挥积极作用，否则我认为他们不应该被建模为演员。演员可以是物理人，也可以是与您正在创建的系统交互的其他系统。这些演员可能最终成为所谓的替代课程。
<强>更新
通过the article linked above，似乎使用actor（与播放器同义）来限定要添加角色的目标对象。如果这是正确的，那么这个词就有不同的含义。
角色是一种特殊的对象，可以将行为添加到另一个对象中 对象（演员或玩家）
答案 4 :(得分：0)
没有看过其他答案： - /这是我的：
1）向用户出售一堆产品的用例是一个名为“直到销售商品”的用例，或者会被分成几个，例如“添加产品到购物车”和“完成销售” “（将编写销售日志并打印收据）。
我总是尝试使用一个用例作为“与系统交互，为演员带来价值”。 “出售物品”将具有价值。 “将产品添加到购物车”将没有价值。
我写了“我试着”，因为通常你会按照我的定义开始使用好的用例，但是你会开始添加细节并扩展你的用例......
2）虽然我正在编制目录，销售数据库，销售日志，购物篮等，但我可以将它们模型化为我的用例中的演员吗？或者是销售人员和付款合作伙伴的唯一参与者？
我不仅将演员用于真人，还用于与系统交互的系统。但是术语“数据库”，“日志”等告诉我，你似乎想在你的图表中加入太多细节。
也许一个好的方法是首先考虑创建用例图的原因。
对我来说，大多数时候我的理由是想要了解我必须建立什么样的系统。然后我使用图表作为调节会议的工具。它有助于找到以下三个问题的答案：
就是这样。当它详细介绍时，我使用了一组不同的图表。