Interface UML-接口、抽象类还是。。。？

我的程序有一些抽象的“模块”。 假设它是一个GUI模块。 它只包含模块及其类型的接口，以便与其他模块兼容（在其他模块中，我可以使用GUI模块及其类型，而不必担心它的实现）

所以我有这样的想法：

GUI::Component //represent the abstract component (button, label etc.)
//so it's only the base class for components

GUI::Clickable //if any component is clickable, it must inherit from it

GUI::Button : public Component, public Clickable
GUI::Label : public Component

但即使是

标签

或

按钮

也只有虚拟方法（我猜它们是模块的接口）。GUI模块的实现，例如，

SomeGUIImp

必须声明

SomeButton:public GUI:：Button

和

SomeLabel:public GUI:：Label

（由于对象工厂，它们对用户是透明的）

我不想更改代码中的任何内容，我只想为它制作一个合适的UML图

所有这些元素（

组件、可点击、按钮）都是界面吗？还是抽象类

我想以某种方式表明，
标签
和
按钮
比
组件
更“抽象”（用户可以更直接地使用，更具体）

此外，最好能显示可点击的
和组件
之间的区别（它是所有组件的抽象基础）

当前解决方案（不确定）
我不能说100%的原因，但在我看来，
可点击的
可能是一个界面，
组件
是一个抽象类，
按钮
只是一个普通类

但这显示了模块内部的关系，忽略了<代码>按钮>代码>（仅具有纯虚方法），这只是一些模块实现的声明（
），因为C++没有接口概念，当类为100%抽象（虚拟）时，可以将其建模为接口或抽象类。在您的描述中，这些类在语义上更接近接口，所以用这种方式对它们进行建模是很好的。您所采取的方向看起来非常好。
规则非常简单-只有纯虚拟方法的类是接口，有部分纯虚拟方法的类是抽象类，没有虚拟方法的类是实现类。如果这不适合你的设计，你可能应该重新考虑一些事情。例如，如果您认为
按钮既是接口又是常规类，那么您可能应该将其分为两个不同的类—一个用于接口，一个用于实现