我正在从事一个小的业余项目，正在尝试以略微不同的方式进行操作。
我正在构建一个ERP系统，其中包括收银机、产品目录、销售数据库、销售日志（类似于数据库，但用于会计目的）、打印机、支付合作伙伴和购物篮（购物车）。
虽然打印机是硬件设备，但我需要编写更高级别的代码来打印收据。
唯一不需要编程的部分是支付合作伙伴。
我有两个问题。
1）将一堆产品销售给客户的用例是否被命名为“在收银台出售商品”的一个用例，还是应该细分为几个用例，例如“添加产品到购物车”和“完成销售”（将销售日志写入并打印收据）？
2）虽然我正在编写目录、销售数据库、销售日志、购物篮等程序，但我可以将它们视为用例中的参与者吗？或者只有销售人员和支付合作伙伴才是参与者？
我认为你需要先退后一步。演员和用例的目的首先是要问：“谁会使用这个系统？”以及“他们为什么会使用它？”你可能会将打印机等识别为演员-实际上，其中一些可能确实是-但你会错过关键点。
根据您的描述，我猜测演员及其用例如下：
当您设计每个用例的流程时，您可能会确定需要与之交互的其他外部组件-例如支付合作伙伴。如果您愿意，可以将这些显示为演员（我个人不喜欢，但纯属个人偏好）。
您还将识别系统中发挥实现 UC 行为作用的其他元素（例如销售数据库等）。 这些是系统的一部分 - 通常不会显示为 Actors。
因此，总之：用例旨在帮助您确定系统的目的以及谁从中获得价值 - 而不是构建内部设计组件。
希望对您有所帮助。
首先，不要在这个阶段考虑编程。考虑业务需求是什么。
客户需要：
系统需要：
第一个列表将是您的高级用例，第二个列表将是这些高级用例的一部分或包含在其中。如果用例的某个部分足够复杂（或者只是足够冗长），以至于需要将其放入自己的用例中，则使用包含。隐藏复杂性，就像这样。
至于目录、销售数据库、销售日志、购物篮等是否是参与者 - 参与者与系统（或用例）进行交互。我很难想象目录会与某些东西进行交互。另一方面，客户肯定会与目录进行交互。
一个演员必须在现实世界中是可行的。如果一个系统代表现实世界中的某些东西，那么这个系统可以被视为一个演员。但在现实世界中，目录是惰性的；篮子也是惰性的。销售日志和销售数据库代表纸质记录-它们是惰性的对象而不是演员。用例不是绝对的。你可以有一个模糊的用例，比如“管理用户”（我不确定管理用例是否是一个好的实践，但这是为了举例而已...）在系统的第一次草稿中，然后将其分解成更详细的用例图，沿途完善细节，直到你得出一个基本功能。
至于你的第二个问题，这些听起来像典型的领域对象（要建模为基本类图）。我认为它们不应该被建模为演员，除非它们扮演着积极的角色。演员可以是物理人员，也可以是与你创建的系统交互的其他系统。这些演员可能最终成为所谓的替代类。
更新
通过上面链接的文章, 看起来演员（同义词为player）是用来限定要添加角色的目标对象的。如果这是正确的话，那么这个词就有了不同的含义。
角色是一种特殊的对象，它为另一个对象（演员或播放器）添加行为
没有看其他答案的情况下，这是我的回答：
1）销售一堆产品给客户的用例是否应该命名为“在收银台出售物品”，还是应该分成几个用例，比如“将产品添加到购物车”和“完成销售”（这将写入销售日志并打印收据）。
我总是尝试使用用例作为“与系统交互并为参与者带来价值的过程”。 “销售商品”将具有价值。“将产品添加到购物车”将没有价值。
我写“我尝试”，因为通常你会从符合我的定义的好用例开始，但然后你开始添加细节并扩展你的用例...
2）虽然我正在编写目录、销售数据库、销售日志、购物篮等程序，但我可以将它们建模为用例中的参与者吗？或者唯一的参与者是销售人员和支付伙伴吗？
我不仅将演员用于真实人员，还将其用于与您的系统交互的系统。但“数据库”、“日志”等术语告诉我，您似乎想在图表中加入太多细节。
也许一个好的方法是首先考虑创建用例图的原因。
对我来说，大多数时候的原因是我想要对我需要构建的系统有一个初步的印象。然后我使用图表作为主持会议的工具。它有助于找到以下三个问题的答案：
就是这样。当需要更详细的信息时，我会使用不同的一组图表。
