为财务软件设计领域模型（class 图）
Designing a domain model (class diagram) for a financial software
在准备软件工程考试期间，我在一次旧考试中遇到了以下任务：
您为客户创建了一个新的财务软件，其任务之一是执行税务计算。客户已将以下要求传达给您：
- 系统必须能够：
- 计算和显示不同国家和税率的增值税（德国 19%、奥地利 20%、瑞士 8%）。
- 根据国家特定税 table 计算并显示所得税（德国、奥地利、瑞士单独 table）。
- 系统必须允许用户：
- 填写税务相关数据（增值税总额，所得税年收入）
- 在网络打印机上打印税收计算结果。
- 将税收计算结果发送给相应的税务局。
任务 1：在域模型（class 图）中捕获客户传达的需求，其中包含以下信息：classes，属性、方法、关系、多重性、关系名称。
解法：
我不确定如何定义正确的 classes、关系和多重性。但我试过了，得出了以下不完整的解决方案：
第一次更新：
第二次更新：
有人可以帮我解决这个问题吗？谢谢:)
查看您的图表
我建议你看你的第一个图表，如果真的符合要求，就把它作为练习留给cross-check：
- “一个税率由一个国家组成”（顶部组成）。因此，国家不会独立于税法而存在。这真的是你的意思吗？要求中是否有任何内容表明每个国家/地区只有一种税率？
- “税率由（可选的）所得税率和（可选的）增值税税率组成”（中间的双重组成）。哦！？
- “每个所得税率都有自己的税种”（下图）。类别的想法不是将相似的所得税税率分组吗？
- “一个税率集合了多个税务机关，一个税务机关可能出现在多个集合中”（聚合）。为什么要在税码中汇总管理？
第一条评论：在您的课程中阅读关联、聚合和组合之间的区别。原则上聚合和组合的使用是例外的，必须有充分的理由使用它。
还有一些问题：
- 关系的名称在哪里？
- 什么要求证明税务管理是合理的？如果说的有道理，那不应该和国家有关吗？
- 打印某些元素真的是域模型的一部分还是已经属于某些user-interface？
第二条建议：仅显示您可以从需求中合理推导出的元素，并避免任何user-interface相关行为。
编辑： 经过我们在评论部分的交流，您的最终图表更好地展示了您最初想要展示的内容。您可以为 1 个类别添加多重性 1..* 比率。您还可以添加一个分隔符，以便显示 类 与 属性 和操作部分一致，即使两者之一为空。设计仍然是基本的，因为所有 properties/attributes 都是 public，这是不推荐的（但我想你这样做是为了避免在你的设计中有很多额外的 getters/setters）。
替代方法：
您的叙述描述了一个use-case，即执行税收计算，包括输入计算数据、打印和发送。参与者可能是您客户的一些办事员，也可能是税务局。
我在阅读叙述时按时间顺序找到了 类 的以下候选对象：增值税、国家/地区、税率、所得税、“country-specific 税 tables”、总金额，年收入，税收计算，税务局。让我们仔细看看：
- 税务局很不清楚：每个税务局都有网络打印机吗？相关税务机关是如何确定的？每个国家有一个办事处，还是组织可以更复杂？
- 增值税和所得税非常不同：
- 对于增值税，有 different rates per country。适用费率始终已知，根据适用费率和毛值计算。
- 对于所得税，叙述中提到 country-specific 税 tables：这意味着税率可能无法提前知晓，但取决于应税收入水平。 （例如，在 Austria there is a minimum, and beyond it's flat rate; but in France 中，有正常费率，前 50 万欧元有优惠费率）。实际上，所得税要复杂得多，因为它可能还取决于企业的法律形式，或者收入的用途（re-invested 与分配），但为了练习，让我们保持简单。措辞含糊不清是每个国家有一个 table 还是几个。
- 如果您愿意，您仍然可以概括税收的概念，考虑到在此练习中，它的金额是根据基本金额（总金额或年收入）计算的。
- 税收计算并不完全清楚：它只是用户界面，还是计算实际上是某个域对象。这会给我们：
这将导致图表如下：
在准备软件工程考试期间，我在一次旧考试中遇到了以下任务：
您为客户创建了一个新的财务软件，其任务之一是执行税务计算。客户已将以下要求传达给您：
- 系统必须能够：
- 计算和显示不同国家和税率的增值税（德国 19%、奥地利 20%、瑞士 8%）。
- 根据国家特定税 table 计算并显示所得税（德国、奥地利、瑞士单独 table）。
- 系统必须允许用户：
- 填写税务相关数据（增值税总额，所得税年收入）
- 在网络打印机上打印税收计算结果。
- 将税收计算结果发送给相应的税务局。
任务 1：在域模型（class 图）中捕获客户传达的需求，其中包含以下信息：classes，属性、方法、关系、多重性、关系名称。
解法：
我不确定如何定义正确的 classes、关系和多重性。但我试过了，得出了以下不完整的解决方案：
第一次更新：
第二次更新：
有人可以帮我解决这个问题吗？谢谢:)
查看您的图表
我建议你看你的第一个图表，如果真的符合要求，就把它作为练习留给cross-check：
- “一个税率由一个国家组成”（顶部组成）。因此，国家不会独立于税法而存在。这真的是你的意思吗？要求中是否有任何内容表明每个国家/地区只有一种税率？
- “税率由（可选的）所得税率和（可选的）增值税税率组成”（中间的双重组成）。哦！？
- “每个所得税率都有自己的税种”（下图）。类别的想法不是将相似的所得税税率分组吗？
- “一个税率集合了多个税务机关，一个税务机关可能出现在多个集合中”（聚合）。为什么要在税码中汇总管理？
第一条评论：在您的课程中阅读关联、聚合和组合之间的区别。原则上聚合和组合的使用是例外的，必须有充分的理由使用它。
还有一些问题：
- 关系的名称在哪里？
- 什么要求证明税务管理是合理的？如果说的有道理，那不应该和国家有关吗？
- 打印某些元素真的是域模型的一部分还是已经属于某些user-interface？
第二条建议：仅显示您可以从需求中合理推导出的元素，并避免任何user-interface相关行为。
编辑： 经过我们在评论部分的交流，您的最终图表更好地展示了您最初想要展示的内容。您可以为 1 个类别添加多重性 1..* 比率。您还可以添加一个分隔符，以便显示 类 与 属性 和操作部分一致，即使两者之一为空。设计仍然是基本的，因为所有 properties/attributes 都是 public，这是不推荐的（但我想你这样做是为了避免在你的设计中有很多额外的 getters/setters）。
替代方法：
您的叙述描述了一个use-case，即执行税收计算，包括输入计算数据、打印和发送。参与者可能是您客户的一些办事员，也可能是税务局。
我在阅读叙述时按时间顺序找到了 类 的以下候选对象：增值税、国家/地区、税率、所得税、“country-specific 税 tables”、总金额，年收入，税收计算，税务局。让我们仔细看看：
- 税务局很不清楚：每个税务局都有网络打印机吗？相关税务机关是如何确定的？每个国家有一个办事处，还是组织可以更复杂？
- 增值税和所得税非常不同：
- 对于增值税，有 different rates per country。适用费率始终已知，根据适用费率和毛值计算。
- 对于所得税，叙述中提到 country-specific 税 tables：这意味着税率可能无法提前知晓，但取决于应税收入水平。 （例如，在 Austria there is a minimum, and beyond it's flat rate; but in France 中，有正常费率，前 50 万欧元有优惠费率）。实际上，所得税要复杂得多，因为它可能还取决于企业的法律形式，或者收入的用途（re-invested 与分配），但为了练习，让我们保持简单。措辞含糊不清是每个国家有一个 table 还是几个。
- 如果您愿意，您仍然可以概括税收的概念，考虑到在此练习中，它的金额是根据基本金额（总金额或年收入）计算的。
- 税收计算并不完全清楚：它只是用户界面，还是计算实际上是某个域对象。这会给我们：
这将导致图表如下：