UML Questions about 'abstract' and stereot

hi every body i'm trying to understand UML but there are some questions about it

In UML what is the significance of tagging a class with the stereotype <<abstract>>?

and how to express this constraint as an invariant,

回答1:

A stereotype "abstract" does not exist - an abstract class should be depicted using italic font. Abstract means that a class cannot be instantiated. It needs a subclass to do so. So as a pseudo-code constraint this would mean

for all instances i of MyAbstractClass holds: i.actualClass != MyAbstractClass

or in ocl for MyAbstractClass holds

self.allInstances()->forAll(i: MyAbstractClass | i.classifier <> self)

As the word 'abstract' was not displayed in your first question version, I expanded on stereotypes in general:

First of all: When learning UML, stereotypes should not be the first things you look into. They are rather complex.

Stereotypes or keywords (both denoted with <<MyStereotype>>) do not have a general meaning. It is defined by the specific stereotype. Commonly you cannot express a stereotype as an invariant instead.

But some other aspects of UML can be shown the same way: A class from the UML Metalevel is marked with <<metaclass>> even though it does not have a stereotype or even is of different actual type. The Stereotypes themselves are shown with a <<stereotype>> marker (even if they are instances of a special class).

An example for a custom stereotype could be "Service". You could mark classes with it which represent a Service. There could be a constraint which tells you that a "Service" must implement a special Interface. In this case you could express this constraint as a (boring) invariant. But probably it is even just a marker. In the latter case you can use a keyword as replacement.

回答2:

I realize this thread is a couple of years old, but I came to it when it was referenced by someone else, as supporting the assertion that the «abstract» stereotype isn't supported by the UML spec. That assertion isn't quite accurate, and I'd like to explain why. I'll start by clarifying what abstract classes are.

Abstract classes are definitions of classes that don't include complete implementation. Therefore, abstract classes can't be directly instantiated; they have to be specialized (inherited). Abstract classes are notated by italicizing the class name and the methods that are abstract, and additionally by optionally adding an {abstract} property to the class name and/or to the operations (methods, we usually say, but methods are actually the "method" by which the operation is implemented) that are abstract.

Interfaces are abstract classes with no implementation; their notation is different from other types of abstract classes (don't italicize, use the «interface» keyword, and notate all the specialization arrows with dotted lines). So, as Christian says here, there is standard notation for abstract classes--at least, there is in class diagrams.

Now, while it is true, as Christian also says, that the «abstract» stereotype doesn't exist, it is also true that you can create it if you want to, and that doing so is supported by the UML spec. It's unlikely that you'll have a reason to (at least in class diagrams), but you still can.

A stereotype is an "extensibility mechanism" for UML (there are three: stereotypes, tagged values, and constraints). It allows you to more specifically define some sort of element. Stereotypes are applied to classes (metaclasses actually, metaclasses are classes whose instances are also classes). A number of stereotypes are pre-defined "Standard Stereotypes" (in UML 1.4 they were called "Standard Elements"). Examples of these are «metaclass» (again, a class whose instances are also classes) and «file» (a physical file in the context of the system developed).

Stereotypes are a type of keyword. The spec (Superstructure 2.0, Annex B, p. 663) has this to say about keywords:

UML keywords are reserved words that are an integral part of the UML notation and normally appear as text annotations attached to a UML graphic element or as part of a text line in a UML diagram. These words...cannot be used to name user-defined model elements where such naming would result in ambiguous interpretation of the model. For example, the keyword “trace” is a system-defined stereotype of Abstraction (see Annex C, “Standard Stereotypes”) and, therefore, cannot be used to define any user-defined stereotype.

In UML, keywords are used for four different purposes:

To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form...

To distinguish a particular kind of relationship between UML concepts (meta-association) from other relationships sharing the same general graphical form...

To specify the value of some modifier attached to a UML concept (meta-attribute value)...

To indicate a Standard Stereotype (see Annex C, “Standard Stereotypes”)...

Keywords are always enclosed in guillemets («keyword»), which serve as visual cues to more readily distinguish when a keyword is being used...In addition to identifying keywords, guillemets are also used to distinguish the usage of stereotypes defined in user profiles. This means that:

Not all words appearing between guillemets are necessarily keywords (i.e., reserved words), and

words appearing in guillemets do not necessarily represent stereotypes.

In other words, you can create any stereotype that you want, so long as it isn't a keyword. Since "abstract" is not a keyword, it follows that you can create an «abstract» stereotype.

In order to do so, however, you would have to go to some trouble, more trouble in UML 2.0 and above than in UML 1.4. UML 1.4 simply stated that a stereotype was an extension mechanism for the UML spec. One could simply define the stereotype, apply it to whichever part of the UML metamodel one wanted, and document the change. UML 2.0 wanted to formalize the relationship of a stereotype to a UML metaclass (any item on a UML diagram is a metaclass, and part of the UML metamodel). So, they came up with Profiles. This sample diagram shows how profiles work:

Now, that black arrow may look a bit strange, since you don't see it in any context but this one. UML 2.0 introduced the concept of an Extension, which it defines as "used to indicate that the properties of a metaclass are extended through a stereotype." This black arrow indicates an extension.

I'll quote Tom Pender (The UML Bible, Wiley Publishing, 2004) for an explanation of this diagram, since he does a better job than the spec (and I certainly can't improve on it):

It shows that a Component is extended by a Bean stereotype, which is required. The Bean stereotype is an abstract type, with two subtypes - Entity and Session. Each instance of Component, therefore, must be extended by an instance of either the Entity stereotype or the Session stereotype. Remember that a stereotype is a kind of class that can have properties - in this case, a Session stereotype has an attribute named state. This corresponds to a tagged definition whose value specifies the state of the Session. The tagged value is an enumeration, StateKind, which has either a stateless or stateful value.

The Component has a constraint on it, displayed in the note attached to the Component symbol, which states that a Component cannot be generalized or specialized.

The diagram also shows that an Interface metaclass is extended by the Remote and Home stereotypes. The EJB package has a constraint, displayed in the note that sits in the package, that states a Bean must realize exactly one Home interface.

So, you can indeed use an «abstract» stereotype if you have reason to go to the trouble of creating it. The main reason that anyone might want to is to represent an abstract class in some place other than a class diagram.