What's the difference between a stereotype and a class inheritance in UML?

Question

I'm confused about the difference between something being a "stereotype" and being a "superclass" in UML.

Let's say I want to create a diagram involving a "WidgetMaker." WidgetMaker is clearly an Actor so the UML standard is to stereotype it actor:

<<Actor>> WidgetMaker

But I grew up programming in the Java/Ruby/C++ world. In that world, the relationship is:

class Actor
end

class WidgetMaker < Actor
end

That looks like this in UML:

  Actor
    ^
    |
WidgetMaker

So my question is: why does UML have stereotypes at all when you can just as easily model those concepts using class inheritance, which it also has.

Once we have more "kinds" of actors, the question becomes even murkier:

              Actor
                ^
                |
    ------------------------
    |           |          |
  Person      Robot      Group
    ^
    |
WidgetMaker

versus

<<Actor>> <<Person>> WidgetMaker

Answer 1

A Stereotype is there and used to present more information about the artifact which the documentation or the Classification of the same into a specific block of artifacts may not give. For example, you have identified a Data Class, you might give it the name, explain the attributes and the operations but that itself may not give the full information.The moment you Stereotype it as <>, it specifies full information; Until then it continues as any other class to a developer.

"Stereotypes are used to extend the UML notational elements, to classify and extend associations, inheritance relationships, classes, and components"

A Stereotype provides the capability to create new kind of modeling elements. Stereotypes must be based on elements that are part of the UML meta-model. Some common stereotypes for a class are entity, boundary, control, utility and exception. The stereotype for a class is shown below the class name enclosed in guillemets (i.e. « and », pronounced gee-may). If desired a graphic icon or a specific color may be associated with a stereotype.

Answer 2

As far as I understand, the primary purpose of stereotypes is to enable extension of UML itself (as a modeling language), and not to model anything.

Having said that, I also think that your question implies another possible valid answer: some people prefer to use stereotypes to designate (informally!) certain commonalities between classes. They might do that just because it is easier than subclassing and "good enough" for the purposes of their models.

For example, many software systems have classes that represent so called domain entities (things like companies, customers, purchase orders, products, etc.). Eventually, you might want to have a common class like Entity to derive Company, Customer etc. from. But initially it is likely to be sufficient just to use stereotyped classes like these <<Entity>> Company, <<Entity>> Customer etc. Essentially, it's just a matter of convenience (and cost/benefit!) of your modeling efforts.

Answer 3

In your example Actor probably doesn't need to be implemented as a class, but this may or not always be the case. Stereotype are abstractions that can be applied to most UML elements not just classes.

They encapsulate semantics without implying how those semantics will provided. Another example could be a communications channel stereotyped as HTTP or RPC. They are communicating with the reader how something will be provided without complicating the model with unnecessary detail.

The UML specification provides a number of predefined stereotype, but their real power comes from being able to define your own through profiles. You might label a domain object as an EJB to save yourself specifying all the boiler plate code.