Is the class stereotype implicit in an UML class diagram ? Should it be specified?

Question

Commonly I see class diagrams where there is no <<class>> stereotype. Others where there is the common <<interface>> and others with some interesting ones as <<shape>> or <<computer>> and so which for a class diagram I personally don't see the necessity but Ok.

I'm making an UML diagram for a modern algebra project in C++, but as we know the language shouldn't be so influential when working UML. For this project I have recognized the <<interface>> and <<abstract>> stereotypes all fine until this point, but there are structs and classes, I want to do things in the best way possible so I came to ask myself are <<class>> and <<struct>> valid stereotypes?

I kindly thank your answers or comments.

Note: I think struct should be valid because it specifies the type for a certain implementation.

Answer 1

You don't need to indicate to indicate classes explicitly in a class diagram: it's assumed by default, according to UML:

A Class is shown using the Classifier symbol. As Class is the most widely used Classifier, no keyword is needed to indicate that the metaclass is Class.

You are free to define your own stereotypes in UML. They are best documented in a profile diagram that shows how they relate to standard UML elements.

UML is implementation language neutral. It is very typical to define language specific data types (e.g. float, double which do not belong to standard UML) and stereotypes (e.g. class and struct). See for example here a C# profile, for a language in which classes and structs have different semantics.

Be aware that not everything between « », which looks like a stereotype, is a stereotype. It can be a well-defined keyword as well:

• interface is a keyword that refers to something with a clear meaning in the UML metamodel, which is shared between class diagrams and component diagrams.
• enumeration is a keyword that refers to a special kind of type, which needs to be described differently than other basic data types and classes.

Two very important remarks in addidition:

• Introducing language-specific stereotypes makes your design model less general, and bears the risk to get detailed implementation models rather than focusing on the abstract design. You should therefore think about the pros and cons. If your model is language neutral, you could focus on OOD and let it be reused for a java or a C# port for example. If your primary intent is to making an implementation model, it’s of course not a problem.
• In C++ a struct is a class with all members public by default. This is a core language principle. The difference is only about access control. Since in UML you document access control at member level, having a stereotype « struct » that requires all members to be public seems just redundant. I’d advise to use instead unstereotyped classes in UML and decide in the implementation to use a struct or a class depending on member visibility.