Class (Class)
Class (Figure A) is a blueprint for an object, which contains 3 components. The first is the class name defined in Java. The second is attributes. The third is the method provided by this class.
A visibility modifier can be attached prior to attributes and operations. The plus sign ( ) indicates a common visibility. The reduction (-) represents private visibility. # 号 Represents protected visibility. These modifications indicate some visibility of the package (packet) level. If the attribute or operation is underline, it indicates that it is static. In operation, it can be listed in the same manner, and the return type, as shown in the "Java" area of Figure A.
Figure A
Package
The package (Fig. B) is a combination mechanism for conventional use. One package in UML directly corresponds to a package in Java. In Java, a package may contain other packages, classes, or both. When modeling, you usually have a logical package, which is mainly used to organize your model. You will also have a physical package that converts it directly into a Java package in the system. The name of each package has a unique identifier for this package.
Figure B
Interface
The interface (Figure C) is a collection of operations that specify a service provided by a class. It corresponds directly to an interface type in Java. The interface can be represented either the icon of Figure C, or can be represented by a standard class that is attached << interface >>. Typically, depending on the appearance of the interface on the class map, you can know the relationship with other classes.
Figure C
relationship
The following example will independently display a variety of relationships for a particular purpose. Although the syntax is correct, these examples can be further refined, including more semantics within their effective range.
Dependency
A "use" relationship between the entity suggests that after the specification of an entity changes, it may affect other instances depend on it (Figure D). More specifically, it can be converted to any type of reference to a class or object not in the instance scope. This includes a local variable that references an object of an object obtained by method call (as shown in the following example), or reference to a static method of a class (there is also an example of that class). It is also possible to use "dependence" to indicate the relationship between the package and the package. Because the package contains classes, you can represent the relationship between the package and packets according to the relationship between the various classes in those packages.
Figure D
Association
A structured relationship between the entity indicates that the object is interconnected. The arrow is optional and it is used to specify the navigation capabilities. If there is no arrow, hints is a two-way navigation capabilities. In Java, the association (Figure E) is converted to a variable of an instance scope, just like the code shown in the "Java" area of Figure E. Other modifiers can be attached to an association. MultiPlicity modifiers implies the relationship between examples. In the demonstration code, Employee can have 0 or more Timecard objects. However, each Timecard only belongs to a single EMPLOYEE.
Figure E
AGGREGATION
The polymerization (Fig. F) is a form of association, representing the overall / partial relationship between two classes. The aggregation suggests that the overall concept is at a higher level than the local level, while the association suggests that both classes are conceptual at the same level. Aggregation also converts an instance scope variable in Java.
The difference between associations and aggregates is purely conceptual and strictly reflected in semantics. The aggregation also implies that there is no loop in the example figure. In other words, it can only be a one-way relationship.
Composition
Synthesis (Figure G) is a special form of polymerization, implies "local" in "overall" survival duties. Synthesis is also non-shared. Therefore, although local does not have to be destroyed with the overall destruction, the whole is either responsible for maintaining local survival status or is responsible for destroying it. Partially sharing with other overall sharing. However, the whole can turn all rights to another object, and the latter will follow the survival duties.
The relationship between Employee and Timecard may be more suitable for "synthesis" instead of representing "association."
Figure G
Genericization
Ultrafining (Figure H) represents a more generalized element and a more specific element relationship. Uml elements are used to model inheritance. In Java, use the extends keyword to directly represent this relationship.
Figure H
Realization
Example (Figure I) The relationship specifies a contract between two entities. In other words, an entity defines a contract and another entity guarantees to fulfill the contract. When modeling the Java application, the realization relationship can be represented directly with the imports keyword.
Figure G
Precise mapping
As described herein, elements on the UML class can be accurately mapped to the Java programming language. Members of the development team can use this accuracy to strengthen communication and obtain consensus on system structured design.
