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

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.

Answer 2

I feel that talking about stereotyping without bringing in MOF METALEVELS into this discussion makes it impossible to actually explain the key points.

Stereotyping "lives" in M2 (see "OMG Unified Modeling Language (OMG UML), Infrastructure, Verison 2.4.1"), which is specifically for defining modeling languages. Stereotype lives in this level and not in M1 or M0. in other words, stereotyping is a construct specifically for defining NEW MODELING LANGUAGES, not for defining new domain models.

So, replacing stereotyping with generalization in level M1 may be semantically ok within the scope of domain modeling, but since it is in the wrong metalevel, it is NOT entirely semantically equivalent.

Another point is that stereotyping may be optional or mandatory. Inheritance, however, cannot be optional.

Answer 3

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 4

A good indication of the intent behind stereotypes can be seen in how the OMG has applied them in the SysML or BPMN profiles. Specifically, stereotypes describe a new set of modeling constructs as part of the language for specifying you domain. For example, a Block in SysML is stereotype applied to Class. It brings with it customizations of a class for use in systems engineering. In this case it replaces the use of Class and sets up new relationships to other elements and diagram types, e.g. Block << satisfies >> Requirement (allowed relationship) or a Block can be modeled using an Internal Block Diagram (allowed behavior). A stereotype is not used to model your subject space. It classifies the use of modeling constructs for a vertical or horizontal aspect of systems definition.

Answer 5

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 6

according to https://sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10 if you want to have tagged values you'd need to define them as attributes on a stereotype (since UML 2.0 it is required)

In UML 1.3 tagged values could extend a model element without requiring the presence of a stereotype. In UML 1.4, this capability, although still supported, was deprecated, to be used only for backward compatibility reasons.

Since UML 2.0, a tagged value can only be represented as an attribute defined on a stereotype. Therefore, a model element must be extended by a stereotype in order to be extended by tagged values. To support compatibility with the UML 1.3 some UML tools can automatically define a stereotype to which "unattached" attributes (tagged values) will be attached.

Tag values could be shown in class compartment under stereotype name. An additional compartment is required for each applied stereotype whose values are to be displayed. Each such compartment is headed by the name of the applied stereotype in guillemets.

An interesting reading on stereotypes back from 2003 probably is https://www.semanticscholar.org/paper/Systematic-stereotype-usage-Atkinson-K%C3%BChne/3253db03c11f4f99be580277716d3b78d750618a

This is the abstract:

As one of the UML’s main extension mechanisms, stereotypes play a crucial role in the UML’s ability to serve a wide and growing base of users. However, the precise meaning of stereotypes and their intended mode of use has never been entirely clear and has even generated significant debate among experts. Two basic ways of using UML stereotypes have been observed in practice: One to support the classification of classes as a means of emulating metamodel extensions, the other to support the classification of objects as a means of assigning them certain properties. In this paper we analyze these two recognized stereotype usage scenarios and explain the rationale for explicitly identifying a third form of usage scenario. We propose some notational concepts which could be used to explicitly distinguish the three usage scenarios and provide heuristics as to when each should be used. Finally, we conclude by proposing enhancements to the UML which could support all three forms cleanly and concisely.