Enterprise Architect & UML: subtleties when choosing interface or abstract class

Question

I am currently building a model from existing C++ code. There is a (dynamically loadable) library that must therefore implement/provide a defined interface (class). The class which is used has some pure virtual functions, but it is - admittedly - not a pure interface (in the Java sense) as it is also a base class containing state (members) and a few method implementations.

So it is kind of a hybrid - base class in C++ reality, but an interface in its main purpose.

Note: I do not intent to generate some code, but the model should be correct for documentation purposes.

When drawing an example in EA (12), some questions arise:

a) are there any important reasons to prefer a class and make it 'abstract' (gray box "Base"), or should I directly use an Interface from the toolbox (purple box "Base2")? So far I could not notice any behavioral difference in EA except the color.

b) How can I suppress the stereotype {abstract} written behind the methods? When I do not set them to "abstract", they are not drawn in italic letters. But I want them italic, without the "{abstract}".

c) Similar question concerning the class/interface boxes: aren't interfaces abstract by definition? So why does EA add the {abstract} text here? It was sufficient to draw the class name italic.

d) I guess that the most left arrow (generalization of a base class) and the most right arrow (realization of an interface) are correct, and the middle one is not. Right?

Answer 1

As Thomas mentions, an interface is an abstract class technically, although an abstract class isn't always an interface. If you have even one operation (method) that isn't implemented, the class is abstract, so it follows that if none of the operations are implemented, the class is also abstract. An "abstract class" is often only thought of as a class with partial implementation since such an abstract class is different from an interface. However, a class with no implementation--an interface--technically is also an abstract class.

That's probably why EA puts the {abstract} attribute on an interface (it isn't a stereotype in the diagram, it's an attribute--stereotypes use <>). I wouldn't do it myself, since it goes without saying.

Answer 2

a) Take either, but be consistent. The difference is a bit esoteric and except for rare cases not worth while (YMMV).

b) It looks like you filled Context/Advanced/Multiplicity with the value abstract

c) Yes. Interfaces are abstract and if you look at the Details tab you'll see that the Abstract box is ticked and can't be changed. I have no idea where that curly bracketed text comes from. It's not a stereotype. The only way I could show it like that was to change the type from int to int {abstract}.

d) You can well implement more than one interface in a class so theoretically all connectors are fine. So Derived implements two interfaces.

Edit As @minastros found out himself (and PMed me) the culprit was one of the zillion flags in the EA options: