UML Basic Elements

Class diagrams are the most common diagrams in object-oriented system modeling, and class diagrams show a set of classes, interfaces, collaborations, and relationships between them. Class diagrams are used to model the static Design view of a system. In UML, classes are represented as rectangles, with descriptions of names, attributes, operations, and relationships. Next we will give a comprehensive description of the performance of each element within the class. Class: In UML the class is represented by a rectangle, and the name of the class is represented by a string. The
abstract class is changed by changing the class name to a class that cannot be inherited by the Italic table (leaf class, enclosing class) by adding the leaf feature description under the class name. Properties: Properties are listed in the column below the class, and you can display only the property names. The
static property is represented by an underscore in the property name.
attribute complete syntax for other features: [Visibility] Property name [': ' type] [multiplicity] [' = ' initial value] [{attribute string]}] The
cannot override properties by adding the leaf feature description to the attribute string.
Action: Properties are listed in the second column below the class, and you can display only the name of the operation. The
Static action is also represented by an underscore under the name, as well as a static property. The
Abstract operations are also represented in italics by the abstract class.
Operation feature Complete syntax: [Visibility] Action name [([orientation] parameter name ': ' parameter type [' = ' default]]] [': ' return type] [{feature string}]
An operation that cannot be overridden uses a feature string to add the leaf.
Visibility: Visibility by adding a specific symbol representation before a property or method name. (~)

in a public (+) private (-) protected (#) package

Next we'll look at the relationship between classes. Dependency (dependency) is a use relationship, and he describes a change in the statute of things that may affect another thing that uses it. The individual considers that the use of another class in a parameter or method body is a dependency on that class. Use a
Generalization (dependency) is used to describe the relationship between subclasses and parent classes. is a kind of
An association (association) is a structural relationship that describes an object associated with another object. has a bidirectional association (association) can find B objects through a object, and B objects can also find the association of a object as a two-way association.
A one-way association (direction-association) can find a B object through a object, but the association of a object cannot be found by a B object as a one-way association.
The aggregate (aggreation) A object is a constituent part of a B object, but a object may be part of a C object, and this association is an aggregation.
A group (composition) A object is a constituent part of a B object, unless the B object transfers a object to another object, a object can only be part of a B object, and the association is a combination.

1.1 Classes (Class)

The class (Figure A) is the blueprint for the object, which contains 3 components. The first is the class name defined in Java. The second one is the attribute (attributes). The third is the method provided by the class. You can attach a visibility modifier before a property or operation. A plus sign (+) indicates public visibility. A minus sign (-) indicates private visibility. #号表示受保护的可见性. Omitting these modifiers indicates a package (package) level of visibility. If an attribute or action has an underscore, it indicates that it is static. In an operation, you can list both the parameters it accepts and the return type, as shown in the "Java" area of Figure A. Figure A

1.2 packs (Package)

The package (Figure B) is a general purpose combination mechanism. A 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 logical packages that are used primarily to organize your models. You will also have the physical package, which is directly converted to the Java package in the system. The name of each package uniquely identifies the package. Figure B

1.3 Interface (Interface)

An interface (Figure C) is a collection of operations that specifies the services provided by a class. It corresponds directly to an interface type in Java. Interfaces can be represented either by the icon in Figure C or by a standard class attached to <<interface>>. Typically, you can know the relationship to other classes, depending on what the interface looks like on the class diagram. Figure C

2 Relationship

The following example will show the relationships independently for a specific purpose.

Although the syntax is correct, these examples can be further refined to include more semantics within their valid range. 2.1 Dependence (Dependency)

A "use" relationship between entities implies a change in the specification of an entity and may affect other instances that depend on it (Figure D). More specifically, it can be converted to any type of reference to a class or object that is not in the scope of an instance. This includes a local variable, a reference to an object obtained through a method call (as shown in the following example), or a reference to a static method of a class (without an instance of that class). You can also use dependencies to represent the relationship between packages and packages. Because the package contains classes, you can indicate the relationship between packages and packages based on the relationships between the classes in those packages. Figure D

2.2 Association (association)

A structured relationship between entities indicates that objects are interconnected. The arrows are optional and are used to specify navigation capabilities. If there are no arrows, the hint is a two-way navigation capability. In Java, an association (Figure E) is converted to a variable of an instance scope, just like the code shown in the "Java" area of Figure E. Additional modifiers can be attached to an association. The multiplicity (multiplicity) modifiers imply a relationship between instances. In the demo code, the employee can have 0 or more timecard objects. However, each timecard only belongs to a single Employee. Figure E

2.3 Aggregation (Aggregation)

Aggregation (Figure F) is a form of association that represents a global / local relationship between two classes . Aggregation implies that the overall concept is at a higher level than the local one, and the association implies that two classes are conceptually at the same level. Aggregations are also converted to an instance scope variable in Java. The difference between association and aggregation is purely conceptual and is strictly reflected in semantics. Aggregation also implies that there is no loop in the instance diagram. In other words, it can only be a one-way relationship. Figure F

2.4 Synthesis (composition)

The difference between synthesis and polymerization
Synthesis and aggregation are special cases of association. Aggregation is used to denote a "owning" relationship or a relationship between a whole and a part, while synthesis is used to represent a much stronger "owning" relationship. In a synthetic relationship, the part and the whole life cycle are the same. A synthesized new object fully possesses the control over its constituent parts, including their creation and destruction. In terms of programming language, new objects that are combined are absolutely responsible for the memory allocation and memory release of the components.

Man and his legs are a good example.

Synthesis (Fig. g) is a special form of aggregation, implying " Local" within the " whole" life-cycle responsibility . Synthesis is also not shared. Therefore, while the part does not necessarily have to be destroyed with the destruction of the whole, the whole is either responsible for maintaining a partial survival state or for destroying it. Local cannot be shared with other whole. However, the whole can transfer ownership to another object, which then assumes the lifetime responsibility. The relationship between employee and timecard may be more appropriate to be expressed as "compositing" rather than as "association." Figure G

2.5 generalization (generalization)

Generalization (Figure h) represents the relationship between a more generalized element and a more specific element. Generalization is a UML element that is used to model inheritance. In Java, this relationship is represented directly by the extends keyword. Figure h

2.6 Implementation (realization)

Instance (figure I) a relationship specifies a contract between two entities. In other words, one entity defines a contract and the other entity guarantees the fulfilment of the contract. When modeling a Java application, the implementation relationship can be represented directly by the Implements keyword. Figure I

Turn from: http://www.uml.org.cn/oobject/201005122.asp

Http://hi.baidu.com/lei55022033/blog/item/8f259c172a2913094b90a7ea.html