如何表示商品口味(或产品变体)?

发布于 2025-01-16 14:59:13 字数 943 浏览 4 评论 0 原文

我有以下 UML 图:

Merchandise UML 图

其中 VarietyCategory 可以采用 sizecolour 等值,并且sizeVariety 可以是 SML >颜色可以是绿色红色

现在,我可以根据商品的所有品种类别的笛卡尔积获取每个品种组合的库存(例如,5 个 S-green 商品和 10 个 <代码>M-红色项目)。如何将此信息添加到 UML 图中?

我想我将其视为从 Merchandise 到由所有具有 quantityVarietyCategory 的笛卡尔积定义的空间的可选关联类> 属性指定给定组合的库存,但我不知道如何在 UML 中表达它。

经过一番思考后,我想出了这个,但这似乎并没有完全传达意图,因为我必须根据图的另一部分添加注释来指定多重性,以及选择的约束每个品种类别的品种:

关于如何做到这一点有更好的想法吗?

I have the following UML diagram:

Merchandise UML diagram

Where VarietyCategory could take values like size and colour, and Variety for size could be S, M, L, and for colour could be green, red.

Now I can have a stock per combination of varieties, taken from the Cartesian product of all the variety categories a merchandise have (for example, 5 S-green items and 10 M-red items). How can I add this information to the UML diagram?

I guess I'm seeing this as an optional association class from Merchandise to the space defined by the Cartesian product of all the VarietyCategorys with a quantity attribute specifying the stock for that given combination, but I can't see how to express that in UML.

After thinking a bit I've come up with this, but this doesn't seem to fully convey the intention, as I had to put a note to specify a multiplicity depending on another part of the diagram, along with the constraint of selecting a variety from each variety category:

Flavour added to the diagram

Any better ideas on how to do this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

静待花开 2025-01-23 14:59:13

问题

这确实是服装等某些行业中的常见场景,其中目录中的每件商品的尺寸、颜色和款式都是可配置的。

诸如“Shirt”之类的可配置商品的库存除了出于统计目的之外没有任何意义,但真正重要的是已配置商品的库存,例如{Item:“Shirt”,尺码:“M”,颜色=“白色”,风格:“意大利彩色”}。这里情况更加复杂,因为配置元素是动态的。

您的解决方案

您的第二个图表通过使用您称为 Flavor 的组合对此进行了很好的建模。因此,对于衬衫,配置变量 (Variety) 的每个可能组合,例如元组 ( "M","white","italian colar) 将是一个不同的您的关联类将保存 Flavor 的库存数量,

Variety 方面的多重性将扣除 1..*。然后约束需要表达这一点。对于Flavor 的出现,关联的Variety 出现的集合的大小与与Merchandise A 全文间接关联的那些出现的大小相同。像你这样的表达式就可以了。另一种选择是用复杂的 OCL 谓词来表达它,考虑到一些缺失的角色名称和多重间接,这是非常困难的,大多数读者无论如何都不会理解它

。不会保留这个解决方案:

  • 它主要弱点是风味似乎独立于商品,而实际上它只对给定的商品有意义(您的约束证明了这一点) 。
  • 管理更复杂的库存并不容易,例如,如果每个仓库都有一个库存。

更好的替代方案

如果您将 Flavor 视为给定 Merchandise 的风味,您可以明确这一点并简化设计:Flavor 将变为配置的商品(而不仅仅是品种的组合),并且可以使其成为商品组合的组件。

然后,您可以在 Flavor 级别简化和存储库存数量。或者,您可以在 FlavorWarehouse 之间的关联类中管理库存数量(对于当前模型,您实际上无法做到这一点)。

在您使用Merchandise的任何地方,您都会使用Flavor来代替,以方便例如配置产品的订购或运输,如果您' d 保持风味独立于商品。

为了避免混淆,最好将 Flavor 重命名为更明确的名称,以提醒您它是您在系统中管理的产品。

The problem

This is indeed a popular scenario in some industries such as apparels, where each item in the catalogue is configurable regarding size, color and style.

The stock of a configurable merchandise such as "Shirt" does not make sense except for statistical purpose, but what really matters is the stock of the configured merchandises, e.g. {Item: "Shirt", size: "M", color="white", style:"italian colar"}. Here it's even more complicated, since the configuration elements are dynamic.

Your solution

Your second diagram models this very well by using a combination that you've called Flavor. So for the shirt, each possible combination of the configuration variables (Variety), e.g. the tuple ( "M","white","italian colar) would be a distinct flavor. Your association would class would hold the stock quantity of the Flavor.

The multiplicity on the Variety side would be by deduction 1..*. The constraint then needs to express that for an occurence of Flavor, the size of set of associated Variety occurrences is the same than those indirectly associated with the Merchandise. A full-text expression like you did is just fine. The other alternative would be to express this with a complex OCL predicate, which is very difficult considering some missing role names and the multiple indirections. Btw, most readers wouldn't anyway understand it.

However, I would not keep this solution:

  • Its main weakness is that the Flavor seems independent from the Merchandise, whereas in reality it only makes sense for a given Merchandise (your constraint proves it).
  • It is not easy to manage more complex stock, for example if you'd have a stock per warehouse.

Better alternatives

If you'd consider Flavor as a flavor of a given Merchandise, you could make this explicit and simplify the design: Flavor would become the configured Merchandise (instead of just a combination of Variety) and could make it a component of the Merchandise composite.

You could then simplify and store the stock quantity at the level of the Flavor . Or you could manage the stock quantity in an association class between the Flavor and a Warehouse (which you could not really do with your current model).

Everywhere you'd use a Merchandise, you'd use a Flavor instead, facilitating for example the ordering or the shiping of configured products, which is much more difficult if you'd keep the flavor independent of the merchandise.

To avoid confusion, it would nevertheless be better to rename Flavor in something more explicit that reminds that it's a product that you manage in your system.

安静 2025-01-23 14:59:13

产品(如 Tesla 的 Model 3)的产品变体(如 Tesla 的珍珠白 Model 3,带运动轮)具有该产品的所有功能(如最高时速 140 英里/小时),此外还有一组属性值槽位产品的变体属性(例如特斯拉 Model 3 中的“油漆”和“车轮”)。下面的类图对此进行了描述:

在此处输入图像描述

该图在类旁边包含数据示例,用于说明其含义。

请注意,使用组合将变体属性与产品以及变体属性值与变体属性相关联意味着这些属性及其值是特定的并且不在产品/属性之间共享。

可以从此模型中读取相应的关系数据库模式:

products( id, vendor_id)
product_variation_attributes( id, product_id, name)
variation_attribute_values( id, product_variation_attribute_id, value)
product_variants( id, product_id, price)
variant_slots( product_variant_id, product_variation_attribute_id, variation_attribute_value_id)

该模型/模式与已确认的答案兼容(模重命名)
https://stackoverflow.com/a/19200349/2795909https://stackoverflow.com/a/24941744/2795909

A product variant (like Tesla's Model 3 in Pearl White with Sport Wheels) for a product (like Tesla's Model 3) has all features of the product (like a top speed of 140 mph) and additionally a set of attribute-value slots for all variation attributes of the product (like "Paint" and "Wheel" in the case of Tesla's Model 3). This is described by the following class diagram:

enter image description here

The diagram includes data samples next to classes for illustrating their meaning.

Notice that using composition for associating variation attributes to products and variation attribute values to variation attributes means that these attributes and their values are specific and not shared among products/attributes.

A corresponding relational database schema can be read off from this model:

products( id, vendor_id)
product_variation_attributes( id, product_id, name)
variation_attribute_values( id, product_variation_attribute_id, value)
product_variants( id, product_id, price)
variant_slots( product_variant_id, product_variation_attribute_id, variation_attribute_value_id)

This model/schema is compatible (modulo renaming) with the confirmed answers
https://stackoverflow.com/a/19200349/2795909 and https://stackoverflow.com/a/24941744/2795909.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文