企业架构师＆amp; UML：选择接口或抽象类时的细微之处

Question

我目前正在使用现有的C ++代码构建模型。有一个（动态可加载的）库，因此必须实现/提供定义的接口（类）。使用的类有一些纯虚函数，但它确实 - 不是纯接口（在Java意义上），因为它也是一个包含状态（成员）和一些方法实现的基类。

所以它在C ++ reality 中是一种混合基类，但在其主要目的中是一个接口。

注意：我不打算生成一些代码，但该模型应该用于文档目的。

在EA（12）中绘制示例时，会出现一些问题：

a）是否有任何重要的理由选择课程并使其“抽象”。 （灰色框＆＃34; Base＆＃34;），或者我应该直接使用工具箱中的界面（紫色框＆＃34; Base2＆＃34;）？到目前为止，除了颜色之外，我还没有注意到EA中的任何行为差异。

b）如何抑制方法背后写的构造型{abstract}？当我不将它们设置为＆＃34; abstract＆＃34;时，它们不是用斜体字母绘制的。但是我想要它们斜体，没有＆＃34; {abstract}＆＃34;。

c）关于类/接口盒的类似问题：按定义抽象接口是不是？那么为什么EA在这里添加{abstract}文本呢？将类名称斜体绘制就足够了。

d）我猜最左边的箭头（基类的概括）和最右边的箭头（接口的实现）是正确的，而中间的箭头则不正确。正确？

Answer 1

a）采取其中一种，但要保持一致。差异有点深奥，除了罕见的情况不值得（YMMV）。

b）看起来您使用值abstract

填充了Context / Advanced / Multiplicity

c）是的。界面是抽象的，如果您查看“详细信息”标签，您会看到Abstract框已勾选并且无法更改。我不知道卷曲的括号文本来自哪里。这不是刻板印象。我可以这样展示的唯一方法是将类型从int更改为int {abstract}。

d）您可以在一个类中实现多个接口，因此理论上所有连接器都可以。所以Derived实现了两个接口。

编辑由于@minastros发现了自己（和PMed me），罪魁祸首是EA选项中的众多标志之一：

Answer 2

正如托马斯所提到的，接口在技术上是一个抽象类，尽管抽象类并不总是一个接口。如果你有一个未实现的操作（方法），那么这个类是抽象的，所以如果没有实现任何操作，那么该类也是抽象的。 “抽象类”通常只被认为是具有部分实现的类，因为这样的抽象类与接口不同。但是，没有实现的类 - 接口 - 从技术上讲也是一个抽象类。

这可能是EA将{abstract}属性放在界面上的原因（它不是图中的刻板印象，它是一个属性 - 刻板印象使用＆lt;＆gt;）。我不会自己做，因为不言而喻。