【问题标题】:Design a transfer pattern in inventory management设计库存管理中的转移模式
【发布时间】:2019-09-06 10:01:58
【问题描述】:

我正在为库存管理软件设计类图。基本上它有 3 个概念:ItemBox 和一个类关联 Distribution,如下所示。

一个项目可以放置在多个不同数量的盒子中。一个盒子可以有很多物品,当然,数量不同。并且它们之间的关系只有在一个盒子确实有一个项目,其数量在 Distribution 类中记录为 distributedQuantity 时才形成。

现在我正在努力设计一个类来记录从一个盒子到另一个盒子的转移项目。我们称其为转账概念,包括执行日期和转账数量。

将特定物品从第一个盒子转移到第二个盒子时可能会发生某些情况:

  • 在第一个框中:如果转入的数量与框内的数量相等,则删除它们之间的链接。否则只修改 Distribution 类中的分布数量。

  • 在第二个盒子里:如果这个商品和盒子之间已经有链接了(也就是说这个盒子已经有这个商品了),会修改分配数量。否则,一个新的链接形式。

最初,我尝试将 Transfer 与 Distribution 联系起来,因为这个概念同时包含 Item 和 Box 的数据。但它只适用于第一个和第二个盒子都转移了物品的情况。

我不知道这是否有标准(事务)模式。

【问题讨论】:

  • Inventory 在该模型中的哪个位置?

标签: java flutter uml


【解决方案1】:

Transfer 的实例用于记录Distribution 实例发生的历史。有两种方法可以对此进行建模。

1.复制 Transfer 中的所有信息

不要将 Transfer 与任何可删除的内容相关联,因为如果将其删除,您将丢失信息。我想 Item、Box 和 Distribution 的实例都可以删除。复制 Transfer 属性中的所有信息。这意味着 Transfer 具有存储在其属性中的项目、第一个盒子、第二个盒子和 transferQuantity 的所有信息。类转移没有任何关联。

2。不要删除对象,而是将它们标记为已死

在这种方法中,您不会删除任何对象,您只是将它们标记为已死,而当它们不应该再存在时。您可以通过添加一个布尔属性“dead”(或“deleted”)来做到这一点。现在,您可以将 Transfer 与 Item 和 2 Boxes 相关联。让 Transfer 具有属性“transferredQuantity”。这种方法的缺点是,当您需要使用额外的类和关联来扩展模型时,您需要经常意识到模型中有死对象,这可能会影响多重性。

【讨论】:

  • 我想我会采用第二种方法,因为我忘记提及的是 Item 在 time 期间已经没有被删除。感谢您提出 Transfer 与 1 Item 和 2 Boxes 的关系。它可以在我的情况下工作。
猜你喜欢
  • 2011-12-11
  • 1970-01-01
  • 2013-09-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-05-21
  • 2011-07-07
相关资源
最近更新 更多