仓库管理器：一个库存的分析模式

这里，我们开发了一个库存模式——仓库管理器，它满足对可重用性和可扩展性所期望的要求。这个模型不仅考虑了系统的静态视图，还考虑了它的动态方面。因为一个库存控制系统不能被完全地模型化(除非顾及到整个制造系统中几个其他方面的问题)，所以模型中也包含了制造系统的一些功能性部分（非库存方面）的作用。这个模型可以作为开发一个完整的制造系统模型的起点或是作为一个语义分析模式（Semantic Analysis Pattern）的实例,这种实例实际上是一个领域范围内可以使用的最小应用。这个模式也是一个组装模式，我们识别出了两个原子模式：基本库存(Basic Inventory)和物品分布(Item Distribution)。

现实需求

一个库存系统应当具备的基本功能或用途可以总结如下：

把不同类型的货物分开。如：物料或零部件与成品。

跟踪仓库中的每个物品。可能需要几种类型的数量。库存（onHand）数量指示了物品的现存数量。定购（onOrder）数量指示了将来有多少物品可以入库。保留（reserved）数量指示了为订单保留的数量。可获得数量是库存数量与保留数量的差额，它暗示了一个员工以后可以使用的数量。在更复杂的系统中，可能还会用到其他类型的数量。

跟踪物品的位置。库存应该记录物品在特定位置上的分布。

由这些功能的本质所决定，几乎所有其他子系统都会对库存中记录的数量有影响。一些对库存系统有直接影响并更新库存记录数据的功能是：采购、接收、物料的分发、审计、报废、发运、制造。

原子模式

我们从定义一个跟踪物品的库存模式——基本库存模式开始。

物品是任何我们想知道它的存在位置和数量的东西。每一个物品属于一个唯一的类型，这个类型提供了一个标识，如：物品号（物品编码，型号）。库存(Inventory)类持有每个物品我们所关注的各种数量。这可以被认为是一个原子模式，如语义分析模式（SAP），它既可以单独存在，又可以作为一个更大模型的一部分。它的动态方面在组装模式中显示。

货物管理器的类模型

仓库(Stock)和零部件/产品(Component/Product)通过一个聚合关联发生关系。库存(Inventory)类中的数量(quantities)属性是仓库(Stock)与零部件/产品(Component/Product)类的结合点，不同的链接，有不同的值。这个模型允许设计者定义不同类型的仓库，作为单独的物品集合；例如，零部件仓库，产品仓库。库存的不同类型可以归纳为一个库存(Inventory)类。

物品被划分成两个不同的类型：成品和用于制造产品的零部件。其他的划分方法也是可能的。产品(Product)类中的“型号(model)”属性，用来作为一个唯一的标识符，其他属性描述了顾客选择时可能用到的特征，如颜色等。零部件(Component)类具有物品序号，描述，类型等属性，物品序号用来做唯一的标识符。产品(Product)和零部件(Component)通常是多-多的聚合关系（一个型号的产品使用几种类型的零部件，一种类型的零部件可以被用在几种型号的产品中），不过这与库存模型无关。

物品(Item)类被划分成产品(Product) 和零部件(Component)子类的原因是：在这两个实体的管理中，存在着很多不同。例如，产品是由一些零部件制成的，在制造过程中，库存系统需要跟踪零部件数量的变化。换句话说，零部件库存比产品库存更复杂。另一方面，两者又在一些方面有相同之处，例如，都需要跟踪手头（onHand）数量（合计的总数量）和实际的存放位置。这里可以应用泛化关系，定义库存(Inventory)类为一个父类，含有共同的特征，而产品库存(ProductInventory)和零部件库存(ComponentInventory)类作为子类，含有每一种不同库存类型的独特特征。图3的模型中也包含了从动态分析中引申出的操作，这将在下一部分描述。

动态分析

这是不够的，我们也需要动态模型来显示库存怎样随时间而变化。在动态模型中，我们定义了为完成通用的操作而应该具有的一般特征。具体的库存系统的其他特征可以从该模型的基本配置中派生。

当零部件或产品入库时，通过调用add_to_stock操作，它们的手头数量（onHand）增加。当零部件或产品出库时，通过调用remove_from_stock，它们的手头（onHand）数量减少。而add_to_stock操作根据预定的规则，决定物品放在哪儿。当零部件或产品被放到某个特定的仓库区域时，操作add_to_localStock增加局部的手头数量（localonHand）。相似地，remove_to_localStock减少局部手头数量。

零部件或产品可以从一个仓库区域迁移到另一个仓库区域，操作transfer执行这个动作。因为所有的移动操作既可以应用到零部件（由Component类表示），又可以应用到产品（由Product类表示）上，所以我们把这个操作放在父类Inventory中。当零部件或产品移出某个仓库区域时，remove_from_localStock操作被用来更新局部手头数量（localonHand）。相反情况下，使用add_to_localStock操作。

最复杂的库存变化发生在制造过程中。我们首先假设顾客的订单已经被处理，并形成了一张表单。表单中详细指示了在制造某种类型的产品时所需的零部件--什么型号的，以及每种型号的数量；这张表单就是生产指令单。当物料员根据生产单备料时，根据生产指令单上指示的数量，所需零部件保留数量的值增加。当零部件从仓库区域实际被领出时，保留数量和手头数量的值减少了。当制造过程结束时，产品库存中的手头数量增加了。通常，生产指令单从处理到结束，需经历几天时间。备料、领料到制造等阶段使人们知道生产指令单正处于什么状态。

结论

产生的模型满足了以下的约束：

该模式可以用于跟踪不同类型仓库中目标物品的数量和它们的分布位置。

其他动作产生的影响可以通过调用适当的操作反映出来。如图书馆的例子中指出的那样，对库存产生影响的动作在不同的应用中可以是不同的。

尽管该模式是用制造业中的术语描述的，但它仍可以用来表示诸如图书馆、商务活动、或者其他相似的地方的库存。

文档，如顾客订单，和其他一些东西，被认为是与库存系统相互作用的外部系统的组成部分，因此没有在模式中表示出来。

为了使该模式能够在多个领域里应用，我们省略了：

◇ 物品的细节，如结构和描述。

◇ 存放位置的细节。

◇ 描述内部动作的文档，例如，在不同位置间货物的迁移。

◇ 异常处理，例如，保留数量比实际能获得的数量大，订单取消等。

◇ 提示低库存水平的报警。

◇ 历史信息。

◇ 资金流动。

◇ 当库存物品为液体形态时的处理（度量液体时应该使用不同的方法）。

◇ 这些方面应该通过其他模式来增加，或者是开发一个包含它们的完整框架。