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

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 2

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.