Uml 规范化与多重继承

我必须模拟一种情况，在这种情况下，我希望使用专门化来确保类在某种程度上是规范化的，但是：

面临多重继承问题的风险，特别是从长远来看

需要从中派生符合XML的UML模型（a.o.，只允许一个超类）

简化的情况如下（另见下图）：我们有零件，如门、螺栓、车轮等，还有工具，如钻头、梯子和更大的机械。所有这些都可以用于一般流程，如订单、装运等。因此，我希望有一个超类（Powertype，也许？）来表示它们，比如Item

工具和零件都有带有序列号的专用类。因此，我认为SerializedPart和SerializedTool都继承的带有SerialNumber的SerializedItem类将确保我们拥有的所有序列化“东西”至少携带相同的信息。但是，我还需要这些序列化项至少携带与其更通用部分相同的信息，因此我将引入多重继承

我已经考虑过制作项目类接口。这至少可以缓解一些（许多，所有？）多重继承问题。这就是另一个原因：除了属性SerialNumber之外，我还希望强制所有序列化的专门化都与制造商有聚合关系。不允许聚合到接口，因此我觉得我无法使用与超类的一个关系来强制执行此关系

因此，我有以下考虑/问题：

• 有两个不相交的项“分支”，对序列化专门化的内容几乎没有技术治理
• 项类作为接口，但很少通过序列化专门化使用制造商
• 所有的类都是具体的，但是当试图从模型中派生XML类时，必须解决多个继承问题

你更喜欢哪种选择，为什么？我遗漏了什么考虑因素吗

---

我只是不想把

SerializedItem

作为超类。没有任何东西是泛化所指的序列化的东西。事物可以符合序列化协议，这与实现接口（可能称为

Serializable

）相同。如果您碰巧处理可序列化的内容而不关心它们的内容，那么您只需要处理

serializable

，并且只知道数字

基本上，您应该将

SerializedItem

作为一个接口（最终将其重命名为

Serializable

），删除向上的泛化，并实现两个水平泛化

这可能不是一个终极比率。但对我来说，这种方法听起来更合理。

如果你想要一个（独立于平台的）信息设计模型（精神上类似于概念模型），那么你应该使用多重继承，如果这反映了你的问题领域的概念

根据这种基于模型的工程方法，您的模型是一个非常好的设计模型，可以用作制作（特定于平台的）实现模型的基础，例如Java类模型或XML模式模型

---

要创建XML模式模型，必须选择特定的映射。特别是，您需要选择一个映射来解析多重继承模式，另请参见。

如果选择将项类建模为接口，您将如何将其映射到XML模式？另外，请注意，接口是一个实现建模概念（例如，用于创建Java类模型），而不是一个通用的OO设计概念。在将类模型转换为XSD模型时，我经常看到的是类层次结构正在扁平化。结果是不再有继承，只有具体的类。因为对于使用XSD的开发人员来说，这使事情变得更容易。在我看来，您的一些（或大多数）类也可以设置为抽象类。为什么你认为不能用接口进行聚合？@GerdWagner我在考虑用转换算法将它们压缩到类中，从而得到一个基于类似上面描述XSD结构的UML模型。@GeertBellekens项类确实是抽象的，但我觉得其他的似乎更具体。我们有螺栓，它们是零件，还有更昂贵的零件。我承认，我们正在讨论如何在一个类中将它们组合在一起，但我喜欢管理服务/程序中是否只允许序列化项的功能。关于聚合，这是w.r.t.可能是抽象的SerializedItem类，但它应该包含一个具体的制造商。也许这可以通过一个制造商接口来实现？在当前的图中，所有类都是具体的。没有“更具体”的感觉。类要么是具体的（可以有该类型的实例，而不是子类型），要么是抽象的（只能存在该类型的一个子类型的实例）。在许多情况下，只有最低级别的类是具体的，而所有其他类都是抽象的。如果

SerializedItem

成为接口，则没有理由使用

制造商的接口。从接口引用具体类是完全合法的。