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

Goble

this link might helps sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10 – Regardant

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.

Lonnylonslesaunier

I really agree that it MAYBE a matter of conveniece, but it is worrisome for me that there seems to be few evidence to prove that. Would anyone please could name some words or docs ? – Sedentary

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.

Chappie

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.

Laellaertes

Other than an icon and color, what is this "full information?" Why can't that happen just by subclassing a classthat has the meta-properties of color and icon defined? And if I want to create a specific type of Data, how do I know whether to stereotype it <<Data>> or subclass the Data class? – Goble

You should think of stereotypes as a way to group classes under a common purpose: boundary classes, control classes, utility classes, etc. It is not changing the nature of your class, rather helping to document it. – Glaab

That makes it sound more like a static attribute. But WidgetMaker is an Actor, it doesn't just act like an Actor or have Actor-ness. – Goble

This does not answer the question IMO. – Dareece

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.

Addie

Answer 5

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.

Penetration

this discussion: it is not a discussion. Please take the tour to learn what Stack Overflow is. – Frumpy

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.

Feeney