网上商店的UML领域模型

Question

因此，我正在为学校分配一项任务，我将在其中建模（使用域模型）一个将完整的杂货袋运送到人们家中的网上商店。 (http://www.linasmatkasse.se)。我希望我能在这里更具体一些，但不幸的是，这就是我所拥有的。

我没有收到任何用例，但场景类似于，将包添加到购物车，创建帐户/添加信息，付款。

这是我目前所拥有的：http://i.imgur.com/BIljBtj.png?1

1. 是否有任何冗余？ （我只需要描述网站的模型，不确定要包括多少）。
2. 我可以/应该在 Customer 和 Account、Cart 和 OrderLineItem、Order 和 Cart 之间添加组合吗？
3. 总体上对属性和多重性相当不确定。如有任何反馈或支持，我们将不胜感激。
4. 支付类？需要吗？是否应该包含付款方式？
5. 我应该为支持等人类元素建模吗？
6. 我是否应该对交付进行更多建模
7. 需要客户和订单之间的关联吗？

非常感谢！又...

Answer 1

• 应该是类图。因此，“has”、“contains”等动词应该显示为聚合，“supplies”、“describes”、“makes”应该出现在关联箭头上，前提是这些名称是源中属性的名称（例如箭头）类。 “拥有”应在关联结束时显示为一个点。还将属性名称真正放在关联的结束上。您可以命名整个关联，但这意味着关联本身，没有类的实例，以某种方式存在。如果你想写 cmets，它们将被放在 notes 上。但通常“供应”、“描述”、“制造”、“拥有”、“包含”、“拥有”等词出现在用例图上。如果您想考虑此逻辑或与您合作的客户或销售经理讨论此逻辑，请将其与类图分开。
• 组成
  • Account 和 Cart 之间的那个你做得非常好。因此，您可以，该购物车不存在于其帐户之外，并且任何帐户都只有一个购物车。所以，1比1的复数组合是明智的，包含很多重要的信息。
  • 您创建的客户是无用的。您只需要帐户。
  • 到现在我还不懂OrderLineItem 和ItemList 的用法。如果某些类的使用不明显，那就不好了——至少把 cmets 放在那里或者想想，如果你真的需要它们。
• 付款 - 是的，这是必要的。至于支付方式，将它们放在特定的 Enumeration 类块中，将它们命名为项目并将 Payment 连接到 PaymentMethods。
• 这里没有人为因素！您深入到 IT 模型中，处于编码的边缘。你真的想做一个用例图，不是吗？

• 交货？可能更多关于交付方式和供应商的枚举，从 Account、Order 中看到的 ClientAddress。由您决定是否要覆盖这个或那个范围。

• ItemDescription 应该只连接到 Item

• 您的所有关联都可以通过两种方式导航。这是毫无意义的。选择可导航性。

• 如果类属性是另一个类的实例，则在关联的另一端（归分类器所有）上放置一个点。

• 供应商已连接到订单？您是否也想涵盖与供应商贸易的主题？然后应该有更多关于该主题的课程。它可能是另一个组件和另一个类图。还是有图形错误？