3

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

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

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

在此处输入图像描述

  1. 有没有裁员？（我只需要描述网站的模型，不确定要包括多少）。
  2. 例如，我可以/应该在客户和帐户、购物车和 OrderLineItem、订单和购物车之间添加组合吗？
  3. 一般来说，属性和多重性非常不确定。任何反馈或支持在这里表示赞赏。
  4. 支付等级？需要吗？它应该包括付款方式吗？
  5. 我应该对支持等人为元素进行建模吗？
  6. 我应该模拟更多的交付吗
  7. 客户和订单之间是否需要关联？

非常感谢！再次...

4

1 回答 1

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

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

  • ItemDescription 应该只连接到 Item

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

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

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

于 2014-02-05T08:47:55.810 回答