Preserve stereotype in Java programs
UML has a series of mechanisms that can be used to extend its core concepts, but perhaps the most familiar one is stereotype. Stereotype is generally translated as a "stereotype", which is a modeling element of the extended meta-model semantics. Stereotypes must be based on a specific existing type or class in the Metamodel. Stereotypes can extend the semantics of existing types and classes, but they cannot alter their structure. The default representation of a stereotype is to add a sharp-angled pair of parentheses around the keyword, which is naturally present in some European languages, as it is very much like a two-angle bracket, so a two-angle bracket is also a recognized representation.
Stereotypes apply to almost any element in UML, including classes, attributes, operations, and associations. For example, we can use stereotypes to display classes from a class in a UML diagram. Figure I shows the role of a class in the state design pattern represented by a stereotype, adapted from the book "Designing Patterns". UML defines a large number of standard stereotypes that we can use to define our own stereotypes as well as the standard stereotypes.
Figure I: UML stereotypes are used to represent the role of a class in design mode
The Messagestatus interface in figure I should have let the word interface inside the angle brackets. However, to differentiate between interfaces and other stereotypes, the Together ControlCenter tool used to make UML diagrams in this article has been omitted. This is because interfaces are different from other stereotypes, "interfaces also have attributes similar to classes in the UML Metamodel."
Until UML1.4 (20,001 years September), a graphic element in UML can only have one stereotype. But in UML 1.4, the OMG (object Management organization) cancels this restriction, and now a graphical element can have multiple stereotypes. Many UML tools do not provide this support because they are not able to keep up with this change.
So how does a stereotype affect our Java code? In a sense, the answer is "none at all," because Java does not provide any means for us to categorize classes in this way (the previous articles have discussed interfaces and inheritance, and in UML they all have their own specific representations). But, on the other hand, we can use stereotypes to clarify the meaning of Java code by first agreeing on the meaning of the stereotype, and then including the stereotype in the source code comments as a new javadoc tag, effectively reducing the need for manual writing to illustrate the meaning of Java code Indicates the number of text. The following code fragment is the skeleton code for the sent class, and the stereotype is added to the annotation in the form of a custom Javadoc tag:
In UML, it is not only a class that can constrain its definition by specifying a stereotype. Figure II shows the dependencies between the two classes, using stereotypes to represent the types of this dependency. In this example, the object of the factory class is responsible for creating objects of the item class. The code for the factory class shows how a custom Javadoc tag can explain this dependency succinctly and concisely using stereotypes.
Figure II: UML dependencies for instantiate stereotypes
Symbol Description: In the previous article, we saw the relationship between the three species, where the fourth species appeared. An association relationship is represented by a solid line plus a forked arrow (if the association is one-way), and a generalized relationship is represented by a solid line plus a closed arrow (pointing to a superclass from a subclass), and the realization relationship is represented by a dashed line plus a closed arrow from the class that implements the interface. Now we've seen a combination of the fourth arrow and the line style: the dotted line plus the fork-pointing arrow that represents the dependency.
Actions and properties can also specify stereotypes. As shown in figure three, two operations are raised with stereotypes that indicate whether they modify the value of the property. The source code corresponding to figure three also uses a custom Javadoc tag to illustrate the method's stereotype information.
Figure three: Add UML stereotypes to the operations of a class
After adding a custom Javadoc tag that describes stereotype information in the Java source code, the benefit is not just to reduce the need for hand-written annotations, but also to make it possible for UML tools to process these tags and complete the following tasks:
A more complete UML diagram from Java source code (in the case of no custom Javadoc markup).
Add additional information to the documentation generated by Javadoc.
For example, the modeling tool used in this article togethersoft the Together Controlcentre, which is to preserve various UML class diagram semantic information that cannot be persisted directly in the Java source code.
Other Presentation Methods
As mentioned at the beginning of this article, angle brackets are the default way to display stereotypes. In fact, stereotypes can also be expressed in a way that changes the graphical symbols or shapes. The example in Figure four shows two classes with a <<actor>> stereotype. Cashier uses the < > stereotype's alternative notation to draw the manager class with the default rectangle. When using alternate symbols, it is difficult to list the various properties and operations of the class, so it is usually omitted. There is also a third way of representing a small substitution symbol to the right of the class name within the regular rectangular symbol, but now this representation is not seen very much.
Figure four alternative symbols for:<<actor>> stereotypes
Using alternate symbols in a class diagram to represent a stereotype has a great disadvantage, and it is difficult to understand what the class diagram is saying if it is unfamiliar to the symbols used by the class diagram. In addition, more than one symbol, understand the burden of graphics to add a point. In this series of articles, we focus only on the most common UML class diagram symbols.
In addition to changing the shape of a symbol to indicate that a stereotype has been specified, we can also express the same information by changing the color or texture of the graphic element. Using color means that we can keep regular graphic shapes and symbols while at the same time expressing visual information (if not more) as much as the shape of the change. In addition, simple color schemes are generally easier to master than abstract shapes.
Figure V: Using Color in class diagrams
The color class diagram in Figure five uses a four-color prototype (archetype) combination of Peter Coad and others to define the class.
The pink <<moment-interval>> class represents an event or activity that must be tracked for business or legitimacy reasons in a system. Carsale and Carrental are examples of two pink classes.
The yellow <<role>> class represents the way in which events or activities are involved, for example, Carsalesperson and customer are examples of yellow classes.
A green class can be further divided into <<party>> (usually a person or organization), <<place>> (where the event or activity takes place) and <thing>> (an object that actually involves an event or activity).
The fourth prototype is the Blue catalog-entry-like-description (<<description>>), which represents the difference between the descriptions of cars in the real world and the description in the exhibition catalogue: the car model belongs to the Blue class, It contains a range of values and values that describe all the cars that belong to that category, and each car in reality is represented by the green <<thing>>.
Classes that belong to a particular prototype have more or less similar properties and behaviors, and classes that belong to the same prototype tend to interact with classes of other prototypes in a way that is generally predictable. These features and behavioral patterns can help us quickly build robust, scalable object models, quickly mastering attributes and operations that can be overlooked, and enhance our confidence in the structure of the code. Figure V shows the properties and operations that we might find in the classes of various prototypes, and the typical relationships between the various prototypes.
Conclusion: In this article, we learned some useful concepts in UML, if it does not have a direct equivalence concept in the Java language, how to use these concepts of UML in Java code to retain high-level design ideas. In the next article, we'll say good-bye to the UML class diagram and instead discuss another important graph of UML-interaction diagrams, including sequence diagrams and collaboration diagrams.
Turn from: http://www.uml.org.cn/UMLApplication/UMLApplication30.htm
