Introduction to UML class diagram symbols

1. Class: Using a three-layer rectangular box.
The first layer displays the name of the class, and if it is an abstract class, it is displayed in italics.
The second layer is the fields and properties.
The third layer is the method of the class.
Note that the preceding symbol, ' + ' means public, '-' denotes private, ' # ' represents protected.
2. Interface: The use of two-layer rectangular box, and the difference between the class diagram is mainly the top <<interface>> display.
The first line is the interface name.
The second line is the interface method.
3. Inheriting class (extends): represented by a hollow triangle + solid line.
4. Implementation interface (implements): represented by a hollow triangle + dashed line
5. Association (Association): represented by a solid arrow, for example: Swallows and climate
6. Aggregation (Aggregation): Represented by a hollow diamond + solid Arrow
Aggregation: Represents a weak ' owning ' relationship, which shows that a object can contain a B object, but that the B object is not part of a object, such as: Company and employee
Combo (composition): Represented by a solid diamond + solid Arrow
Combination: The relationship between the part and the whole, and the life cycle is the same. For example: Man and hand
7. Dependency (Dependency): indicated by a dashed arrow, for example: animals and oxygen
8. Cardinality: The numbers at both ends of the line indicate that the class at this end can have several instances, such as: A bird should have two wings. If a class can have countless instances, it is represented by ' n '. Association, aggregation, and composition are cardinality

The relationships between classes

UML divides the relationship between classes into the following 5 types.

Association: There is a specific correspondence between Class A and instances of Class B

Dependency: Class A accesses the services provided by Class B

Aggregation: Class A is a global class, Class B is a local class, and the object of Class A is composed of objects of Class B

Generalization: Class A inherits Class B

Implementation: Class A implements the B interface

Association (Association)

Association refers to a particular correspondence between classes, represented by arrows with solid lines in UML. In contrast to the number of classes, the association

Can be divided into the following three kinds:

One-to-one correlation

One-to-many associations

Many-to-many associations

Note: Associations also have to be divided into one-way and two-way associations

Dependency (Dependency)

Dependency refers to the invocation relationship between classes, represented in UML with dashed arrows. If Class A accesses the properties or methods of Class B,

Or class A is responsible for instantiating Class B, it can be said that class A relies on Class B. Unlike association relationships, you do not need to define Class B properties in Class A.

Aggregation (Aggregation)

Aggregation refers to the relationship between the whole and the part, which is represented in UML with a diamond-shaped arrow with a solid line.

Aggregation relationships can also be divided into two types:

The clustered subsystem is allowed to be disassembled and replaced, which is a common aggregation relationship.

Clustered subsystems are not allowed to be disassembled and replaced, and this aggregation is called a strong aggregation relationship or a constituent relationship.

Note: Strong aggregation (composition) can be represented by a solid diamond-shaped arrow with solid lines.

Generalization (generalization)

Generalization refers to the inheritance relationship between classes, which is represented in UML with a triangular arrow with solid lines.

Implementation (Realization)

Implementation refers to the relationship between a class and an interface, which is represented in UML with a dashed triangle arrow.

The following is a description of the GOF design pattern:

The arrows and triangles represent the subclass relationship.

A dashed arrow line indicates that one class instantiates an object of another class, and the arrow points to the class of the object being instantiated.

An ordinary arrow line indicates an acquaintance (acquaintance is also called an association or reference), meaning that an object knows only another object. Acquaintances may request each other's operations, but they are not responsible for each other, it only indicates a loosely coupled relationship between objects.

An arrow line with a diamond at the end represents an aggregation (aggregation), meaning that an object owns another object or is responsible for another object. Generally we call an object to contain another object, or a part of another object. Aggregation means that the aggregation object and its owner have the same life cycle.
Abstract class names are represented in italics, and abstract operations are also represented in italics. The diagram can include pseudo-code that implements the operation, which will appear in a box with a pleat and a dashed line to connect the pleat box to the operation implemented by the code.

UML class Diagram Relationships Daquan 1, association

Bidirectional Association:
C1-C2: Refers to both sides know each other's existence, can call each other's public properties and methods.
This is described in the GOF design pattern book: Although this relationship is applicable in the analysis phase, we feel that it is too abstract to describe the class relationship within the design pattern, because the association relationship must be mapped to an object reference or pointer in the design phase. Object references are inherently self-contained and better suited to expressing the kind of relationship we are talking about. Therefore, this relationship is less used in the design time, the association is generally a direction.
The code generated by using Rose is this:

Class C1
... {
Public
C2* theC2;

};

Class C2
... {
Public
C1* theC1;

};

Two-Way association in the code of the performance of both sides have a pointer to each other, of course, can also be a reference or value.

One-Way Association:
C3->C4: Indicates an acquaintance relationship, meaning that C3 knows C4,C3 can invoke the public properties and methods of C4. There is no life-time dependency. is generally represented as a reference.
The generated code is as follows:

Class C3
... {
Public
c4* theC4;

};

Class C4
... {

};

The one-way association code behaves as C3 has C4 pointers, and C4 is ignorant of C3.

Self-correlation (reflexive Association):
Himself by quoting himself, with a reference of his own.
The code is as follows:

Class C14
... {
Public
c14* theC14;

};

is to have a self-reference within yourself.
2. Aggregation/Combination
When there is a whole-part relationship between classes, we can use combinations or aggregations.

Aggregation: Represents the C9 aggregation C10, but C10 can leave the C9 and exist independently (independently of the meaning that this class exists in the problem domain of an application. How to solve this sentence, please see the following in the combination of explanations).
The code is as follows:

Class C9
... {
Public
C10 theC10;

};

Class C10
... {

};

Combination (also known as containment): The general is a solid diamond plus solid line arrows, as shown, indicates that C8 is C7 tolerant, and C8 can not leave C7 and independent existence. But this is depending on the problem domain, for example, in the field of care for cars, tires must be combined in the car category, because it is meaningless to leave the car. But in the business of selling tires, even if the tires leave the car, it makes sense, and it can be aggregated. In "agile development" also said that a combination B, then a need to know the life cycle of B, that is, may be responsible for generating or releasing B, or a in some way to know the generation and release of B.
Their code is as follows:

Class C7
... {
Public
C8 theC8;

};

Class C8
... {
};

You can see that the code and the aggregation are the same. Specific how to distinguish, may only be used to distinguish the meaning of words.
3. Reliance

Depend on:
Refers to C5 may need to use some of the methods of C6, can also say, to complete all the functions of C5, must have C6 method of assistance. C5 relies on the definition of C6, which typically contains the C6 header file in the header file of the C5 class. Rose does not produce a property on the dependency relationship.
Note that you want to avoid two-way dependencies. In general, there should be no bidirectional dependencies.
Rose generates the following code:

C5.h
#include "C6.h"

Class C5
... {

};

C6.h
#include "C5.h"

Class C6
... {

};

Although Rose does not generate attributes, it is generally formally a method in a that uses the object of B as a parameter (assuming a depends on B). As follows:

#include "B.h"
Class A
... {
void Func (B &b);
}

What is the difference between dependency and aggregation \ combination, correlation, etc.?
Association is a relationship between classes, such as teachers teaching students, husbands and wives, water bottles and so on is a kind of relationship. This relationship is very obvious and can be derived directly from the analysis in the problem area.
Dependency is a weak association, as long as one class is used to another class, but the relationship to another class is not too obvious (it can be said that the "uses" the Class), it can be regarded as a dependency, dependence can be said to be an accidental relationship, rather than the inevitable relationship, that is, "I used it in some way, But in reality I don't have much to do with it. " Like me and the hammer, I had nothing to do with the hammer, but I used it when I was going to nail a nail, and it was a dependency that depended on the hammer to nail the nail.

The combination is a whole-part relationship, which is obvious in the problem domain, and can be obtained by direct analysis. For example, tires are part of a car, leaves are part of the tree, hands and feet are part of the body of this relationship, a very obvious whole-part relationship.
Several of these relationships (associations, aggregations/combinations, dependencies) may appear in code in another class in the form of pointers, references, values, and so on, but logically they have the difference.
It is also stated here that the so-called relationships are only valid in a problem domain, leaving the problem domain, which may not be the case, for example, in a problem domain, I am a carpenter, need to take a hammer to work, perhaps the whole question is the description of how I nailed the table with the hammer, nailed the chair, nailed the cupboard Since the whole problem is to describe this, I and the hammer is not only accidental dependence, I and the hammer relationship becomes very close, may rise to a combination of relations (let me suddenly think of the martial arts swordsman Sword, the sword died ... ）。 This example may be a bit absurd, but it is also to illustrate the truth that relationships and classes are all set up in a problem area, leaving the problem domain and they may no longer exist.
4. Generalization (inheritance)

Generalization relationship: Used when two classes have generalized relationships, such as fathers and children, animals and tigers, plants and flowers.
The code rose generates is simple, as follows:

#include "C11.h"

Class C12:public C11
... {
};

5, here by the way to mention the template

The code for the above diagram corresponds to the following:

Template<int>
Class C13
... {
};

Repeat here again, in fact, after reading the above description, we should understand the relationship between the relationships and specific to the code is how, so-called repetition, is only the above extension, such as A and B has a "1-to-many" of the repetition, there is a list in a, which holds the B object's n references , that's it.
Well, to here, already put the above diagram of the relationship is finished, I hope you can have some gains, I also spent a lot of time ah (drawing, generate code, write to the blog, alas, a sweat). But it's worth it if you can get a thorough understanding of these relationships in UML class diagrams. :)
+++++++++++++++++++++++++++++++++++++++++++++++++++++

In UML modeling, it is important to understand the elements that appear on the class diagram. The developer must understand how to convert the elements appearing on the class diagram into Java. With Java as the representative of some examples of the Internet, here are some basic personal collection and summary:

Basic element Symbols:

1. Class (Classes)

The class consists of 3 components. The first one is the class name defined in Java. The second is a property (attributes). The third is the method provided by the class.

You can attach a visibility modifier before the property and operation. A plus sign (+) indicates a public visibility. A minus sign (-) indicates private visibility. #号表示受保护的可见性. Omitting these modifiers indicates visibility with the package level. If the property or operation has an underscore, it is static. In an operation, you can list the parameters it accepts as well as the return type, as shown in:

2. Packages (Package)

A package 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 typically have logical packages that are primarily used to organize your models. You'll also have a physical package, which is converted directly to the Java package in the system. The name of each package uniquely identifies the package.

3. Interface (Interface)

An interface is a collection of operations that specifies the services provided by a class. It corresponds directly to an interface type in Java. The interface can be represented by one of the following icons (above a circle symbol, the circle symbol below is the interface name, the middle is a straight line, the line below is the method name), or it may be represented by a standard class with <<interface>> attached. Typically, you know the relationship to other classes based on what the interface looks like on the class diagram.

Relationship

1. Dependency (Dependency)

A "use" relationship between entities implies that the specification of an entity changes and may affect other instances that depend on it. More specifically, it can be converted to any type of reference to a class or object that is not within the scope of the instance. This includes a local variable, a reference to an object obtained through a method invocation (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 represent the relationship between packages and packages based on the relationships between the classes in those packages.

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, hinting is a two-way navigation capability. In Java, the association is converted to an instance-scoped variable, just as the code shown in the Java area of Figure E. Additional modifiers can be attached to an association. The multiplicity (multiplicity) modifier implies a relationship between instances. In the model code, an employee can have 0 or more timecard objects. However, each timecard only belongs to a single employee.

3. Aggregation (Aggregation)

Aggregation is a form of association that represents a global/local relationship between two classes. Aggregation implies that the whole is conceptually at a higher level than the local, and the association implies that two classes are conceptually at the same level. Aggregations are also converted to an instance-scoped variable in java.

The difference between association and aggregation is purely conceptual, and is strictly reflected in semantics. Aggregation also implies that there are no loops in the instance diagram. In other words, it can only be a one-way relationship.

4. Synthesis (composition)

Synthesis is a special form of aggregation that implies a "partial" lifetime responsibility within the "whole". The composition is also unshared. Therefore, although the local does not have to be destroyed with the overall destruction, but the overall responsibility to maintain a local survival, or be responsible for destroying it.

Local cannot be shared with other whole. However, the whole can transfer ownership to another object, which will then assume the lifetime responsibility. The relationship between employee and timecard may be better represented as "compositing" rather than "associative".

5. Generalization (generalization)

Generalization represents a 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.

6. Implementation (REALIZATION)

An instance relationship specifies a contract between two entities. In other words, one entity defines one contract and the other guarantees the performance of the contract. When modeling a Java application, the implementation relationship can be expressed directly with the Implements keyword.

Like aggregation is also divided into: non-shared aggregation, shared aggregation, composite aggregation, etc.

Introduction to UML class diagram symbols