我目前正在根据现有的 C++ 代码构建模型。因此，有一个(可动态加载)库必须实现/提供已定义的接口(interface)(类)。所使用的类具有一些纯虚函数，但不可否认的是，它不是纯接口(interface)(在 Java 意义上)，因为它也是包含状态(成员)和一些方法实现的基类。
所以它是 C++ 中的一种混合基类现实，但其主要目的是一个接口(interface)。
注意:我无意生成一些代码，但出于文档目的，模型应该是正确的。
在 EA (12) 中绘制示例时，出现了一些问题:
a)是否有任何重要的理由选择一个类并使其“抽象”(灰色框“Base”)，或者我应该直接使用工具箱中的接口(interface)(紫色框“Base2”)？到目前为止，除了颜色之外，我还没有注意到 EA 中有任何行为差异。
b) 如何抑制写在方法后面的构造型 {abstract} ？当我不将它们设置为“抽象”时，它们不会以斜体字母绘制。但我希望它们是斜体的，没有“{abstract}”。
c)关于类/接口(interface)框的类似问题:接口(interface)不是根据定义抽象的吗？那么为什么 EA 要在这里添加 {abstract} 文本呢？将类名绘制为斜体就足够了。
d) 我猜最左边的箭头(基类的泛化)和最右边的箭头(接口(interface)的实现)是正确的，而中间的箭头则不正确。对吗？
最佳答案
a) 任选其一，但要保持一致。区别有点深奥，除了极少数情况下不值得(YMMV)。
b) 看来您用值 abstract 填充了 Context/Advanced/Multiplicity
c) 是的。接口(interface)是抽象的，如果您查看“详细信息”选项卡，您会看到“抽象”框已被勾选并且无法更改。我不知道那个大括号文本来自哪里。这不是一个刻板印象。我可以这样显示它的唯一方法是将类型从 int 更改为 int {abstract}。
d) 您可以在一个类中很好地实现多个接口(interface)，因此理论上所有连接器都可以。因此 Derived 实现了两个接口(interface)。
编辑 @minastros 发现自己(并私信我)罪魁祸首是 EA 选项中的无数标志之一:
关于interface - 企业架构师和 UML : subtleties when choosing interface or abstract class，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31788202/