我正在做一个小爱好项目,我正在尝试做一些不同的事情.
我正在构建的系统是ERP系统,包括产品目录,销售数据库,销售日志(类似于数据库,但用于会计目的),打印机,支付合作伙伴和购物篮(购物车).
虽然打印机是硬件,但我需要编写更高级别的代码来打印收据.
我不需要编程的唯一部分是支付合作伙伴.
我有两个问题.
1)向用户出售一堆产品的用例是一个名为"直到销售商品"的用例,或者将被分成几个,例如"添加产品到购物车"和"完全销售"(其中会编写销售日志并打印收据).
2)虽然我正在编写目录,销售数据库,销售日志,购物篮等,但我可以将它们建模为我的用例中的演员吗？或者是销售人员和付款合作伙伴的唯一参与者？
用例分析看似简单，但这个问题暴露了一些固有的复杂性。
每个用例必须对所涉及的参与者有意义，因为它必须代表与系统的明确定义的交互。当您谈论系统时，即使使用日常语言，每个参与者和用例也必须有意义。如果您发现自己难以定义参与者或用例，那么系统上下文可能不清楚，因此领域模型可能会有所帮助。
用例必须代表一种明确定义的交互，但不一定是完整的交互。该<<include>>关系可用于在同一级别上查看完全交互和部分交互用例有意义的情况。例如，您可能会考虑使用一个buy stuff包含browse products、add product to cart和的用例check out <<xor>> cancel，其中每个用例都对客户有意义。
（我有点困惑你的系统是用于实体交易还是在线交易；拥有收银台和打印收据似乎暗示着前者，购物车作为分析后者所使用的概念的一部分。假设有一个在线系统。）
然而，就您而言，您正在谈论可能被视为系统本身一部分的参与者。这通常意味着您尝试同时定义系统及其子系统，这在您开始分析之前对（最终）系统设计有很好的了解的情况下很常见。
然后您要做的是将分析分为两个级别。在上层（系统）层面，要非常严格地将系统视为一个整体。在您的情况下，您可能需要 actor customer、payment partner、clerk（对于物理交易系统）accountant（可能还需要administrator）以及上面列出的用例以及update product catalogue、audit sales log等。
然后，您将系统分解为子系统，并对每个子系统进行单独的分析。这里的子系统可以是彼此用例中的参与者。Print receipt例如，在系统级别上不是一个有意义的用例，因为它本身不是整个系统和系统级参与者之间的交互，但作为打印机子系统的用例，它是有意义的，并且直到成为演员。
在开始子系统分解之前，您不需要完成系统级分析，事实上，我认为最好让它们同时处于活动状态 - 尽管这对您作为分析师/设计人员能够进行切换提出了更高的要求快速了解环境，并在任何给定时间严格遵守您正在工作的环境。
所以，毕竟（唷！）我认为你问题的答案是：