I have some abstract “module” for my program.
Let’s say it’s a GUI module.
It contains only the interface for the module and its types – for compatibility with other modules (in the other module I can use GUI module and its types, not bothering about it’s implementation).
So I have sth like that:
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
But even a Label or Button have only virtual methods (I guess they are interfaces of the module). The GUI module impementation’s e.g. SomeGUIImp has to declare SomeButton : public GUI::Button and SomeLabel : public GUI::Label (and they will be transparent for user, because of the object factory).
I don’t want to change anything in the code, I just want to make a proper UML diagram for it.
Are all that elements (Component, Clickable, Button) interfaces? Or abstract classes?
I would like to show somehow , that the Label and Button are “less abstract” (can be used by user more directly, are more specified) than Component.
Also, it would be nice to show the difference between Clickable (it’s functionality) and Component (it’s an abstract base for all components).
Current solution (not sure of it)
I can’t say 100% why, but in my opinion, maybe the Clickable is an interface, Component is an abstract class and Button is just the regular class.
But that shows the relations inside the module, ignoring that Button (which have only pure virtual methods) also is just the declaration for some module’s implementation?
Since C++ doesn’t have the notion of an interface, when a class is 100% abstract (virtual) you can model it both as an interface or as an abstract class. In your description these classes are closer semantically to interfaces, so modeling them that way would be good. The direction you are taking seems very good IMHO.