Represents Java inheritance and interfaces in UML

In UML, Java inheritance and interfaces are represented in the previous article.ArticleIn JavaProgramming LanguageAnd UML class diagrams indicate the differences between classes, attributes, operations, and associations. Let's take a look at how to represent two important Java concepts in UML-inheritance and interfaces.

Inheritance

In Java, we can declare one extends class and one or more interfaces. The following describes how to express these concepts in UML.

Below is the basic skeleton of the three Java classes. The first class is the payment abstract class that represents a certain payment method. The other two classes expand the payment class and describe two different payment methods:

/** Abstract class that describes the payment method */
Abstract Public class payment {
Public payment (){}

Public payment (bigdecimal amount ){
This. Amount = amount;
}

Public bigdecimal getamount (){
Return amount;
}

Public void setamount (bigdecimal amount ){
This. Amount = amount;
}

Private bigdecimal amount;
}

/** A subclass that extends the payment class and describes the payment method of a credit card */
Public class creditcardpayment extends payment {
Public creditcardpayment (){
}

Public creditcardpayment (bigdecimal amount ){
Super (amount );
}

Public String getcardnumber (){
Return cardNumber;
}

Public void setcardnumber (string cardNumber ){
This. cardNumber = cardNumber;
}

Public Boolean authorize (){
Return false; // temporarily unavailable
}

Private string cardNumber;
}

/** A subclass that extends the payment class and describes the cash payment method */
Public class cashpayment extends payment {
Public cashpayment (){
Super ();
}

Public cashpayment (bigdecimal amount ){
Super (amount );
}

Public bigdecimal getamounttendered (){
Return amounttendered;
}

Public void setamounttendered (bigdecimal amounttendered ){
This. amounttendered = amounttendered;
}

Private bigdecimal amounttendered;

Public bigdecimal calcchange (){
Return amounttendered. Subtract (Super. getamount ());
}
}
 

Figure 1 shows the same three classes in UML. In the operation and attribute declaration, details such as types and parameters are not displayed, so that the overall structure of the class and the relationship between classes are displayed more clearly.

 

 

 

Figure 1: General UML relationships

The extends keyword in Java declares the inheritance relation, which is equivalent to the "generalization" (also translated as "generalization") Relation in UML. In UML graphics, the subclass is represented by a solid-line closed arrow of the superclass. Figure 1 adds an additional sale class to better illustrate the differences between the General UML relationship and the arrows used in the UML relation. Another difference between a link and a general link is that there is no need to describe multiple or role names at both ends of a general link.

Obviously, UML class diagrams are better than three JavaSource codeThe file clearly and intuitively shows the inheritance relationships between the three classes. If you want to discuss the design ideas with others, it is better to draw a UML sketch than to use it directly.CodeIt is much simpler and faster.

Some people may say that the system's class structure is in their minds, and they only need to use Java code directly. In fact, this statement is obviously not true for a large system. Even for a small systemProgramWithout a UML diagram, it's hard to make sure that everyone understands the class structure diagram in your mind.

In UML, the identifier of an abstract class is that the class name is displayed in italic. It is difficult to distinguish whether the font is italic when you manually draw a UML sketch on a whiteboard or paper. For this reason, some people suggest adding {abstract} in the lower right corner of the class name to indicate the difference.

Others think that writing {Abstrac t} on the whiteboard is too cool. They tend to break the UML conventions. Adding a 0 in the lower right corner of the class name indicates zero instances, if 1 is written in this position, it indicates that this class is a singleton class (there is always only one instance class). If n is written in this position, it indicates that it is an enumeration class (a class with a fixed number of instances, such as the day of the week, the color of the rainbow, and so on ). However, none of these are standard UML and can only be used to draw UML diagrams manually. It seems that they cannot be supported by the UML modeling tool.

Historical Knowledge: UML was first invented by a working group of rational. ration is the producer of the UML modeling tool rose. UML was publicly available at the oopsla meeting in 1995. Subsequently, OMG (Object Management Organization) adopted UML specifications in 1997. It is easy to understand that the OMG task group responsible for developing UML specifications contains representatives from almost all mainstream UML tool vendors. Therefore, apart from strictly following standardized UML software tools, it is strange to find nonstandard UML Symbols on some books or webpages.

Inheritance allows a class to use the attributes and methods of another class, just like using its own attributes and methods. When this type of Inheritance Mechanism emerged for the first time, it was generally considered an ideal method to reuse existing code. Unfortunately, the inheritance tree with a large scale becomes very fragile. modifying a part of the inheritance tree will cause a series of joint and multiple reflections in the entire inheritance tree. In object-oriented programming, if effective encapsulation is to be implemented, changes should be made locally, that is, changes in one place will not cause changes in other places. The modification of the inheritance tree causes changes elsewhere, which violates the above design philosophy. The UML diagram makes it easy for us to grasp the inheritance relationship diagram, thus facilitating the application inheritance relationship. So when is the inheritance relationship suitable? According to Java design, perform the following checks for superclass A and subclasses B:

Article from [SVN Chinese technical network] forwarding please keep this site address: http://www.svn8.com/uml/jc/lt/uml200906286903.html

 

The proposition "B is a role played by a" is not true.

B never needs to be transformed into objects in some other categories.

B expands rather than overwrites or discards A's behavior.

A is not just a tool class (some practical functions that can be reused ).

For a problem domain (specific business object environment): A and B define the same type of objects, or user transactions, roles, entities (groups, locations, or other things ), or similar category of other objects.

If any of the above judgments is not true, it may be inappropriate to define a and B as an inheritance relationship. Switching to an association relationship may be more stable and correct. For example, Figure 2 violates the first judgment, because "an employee is a role assumed by a person" is created. In addition, it violates the second judgment, because an employee may indeed change his/her category (identity), for example, at some point it may be a customer. In this way, a person who is both a customer and an employee must have two independent objects to describe the information stored in the person class, this poses a risk of data inconsistency between two data copies.

Interface

The interface concept in Java programming language can also match the UML concept. The interface in UML is an inheritance form, but this inheritance form is different from the inheritance implemented in Java through the keyword extends.

In Java, the extends keyword describes an inheritance form that inherits both interfaces and actions. This type of inheritance is sometimes called sub-classing. Unlike other object-oriented programming languages, Java classes can only inherit from one class. Many times, people who design UML diagrams are familiar with multiple programming languages and often introduce the idea of multi-inheritance, such as the multi-inheritance idea of C ++. Generating a UML diagram from an existing Java code (called reverse engineering in this process) won't cause multiple inheritance issues. However, if a Java programmer is required to implement a UML class diagram with multiple inheritance, the problem may occur. If the superclasses in Multi-inheritance are pure abstract classes, this class can be described using Java interfaces. However, if only this type of conversion is used, it is not enough to convert all the multi-inheritance in the UML class diagram into single-re-inheritance, in this case, you must modify the UML class diagram and recreate the modeling.

Although JAVA does not support multiple inheritance in languages such as C ++, it supports multiple interfaces. This inheritance declared by implements, a Java keyword, only inherits interfaces. This inheritance is sometimes called sub-typing. In UML, the relationship between classes that implement interfaces and interface definitions is called the realization relationship. A dotted line closed arrow is used to indicate that the class that implements interfaces points to interfaces. The UML diagram of the interface itself is the same as that of a common class, but the name must contain "<interface> ". Figure 4 is modified by Figure 1, and the payment class is replaced by an interface. (Realization Name Description: The most common Chinese Translation of realization is "Implementation ". However, Java implements are also called "implementations ". To avoid confusion, all vertices in this article use English directly ).

Interfaces can be extended from one or more other interfaces. UML generalized relationships (solid closed arrows) can be used to describe these relationships, as shown in Figure 5.

UML also supports another interface symbol, that is, the interface is represented by a circle (after the connection is added, it becomes a lollipop). However, this notation is mostly used in UML component diagrams, it is rare in UML class diagrams.

If a UML diagram has a large scale and a large number of classes implement a common interface, the entire UML diagram may be messy. The book "Java design" proposed a simplified method, which was later adopted by the author of the book "streamlined object modeling". This is in the class that implements interfaces, use the interface name to replace the method inherited from the interface, but this is not a standard method. Unfortunately, there seems to be no tool to support this conversion.

 

Conclusion: inheritance and interfaces are very useful mechanisms in the Java language. We have seen that the general and realization relationships of UML can be used to visualize the two concepts of Java. In addition, some non-standardized representation methods can greatly simplify the UML diagram. In the next article, we will learn how to retain UML semantic information that cannot be directly expressed in Java programs.
Article from [SVN Chinese technical network] forwarding please keep this site address: http://www.svn8.com/uml/jc/lt/uml200906286903_2.html