UML class diagram format

Reposted from: http://www.cnblogs.com/riky/archive/2007/04/07/704298.htmlumlcategory relationship book

1. Association

Bidirectional Association:
C1-C2: both parties know the existence of the other side, can call the other side of the Public attributes and methods.

This is described in the gof design patterns book: although this relationship is applicable in the analysis phase, we think it is too abstract to describe the class relationships in the design patterns, because the link must be mapped to an object reference or pointer during the design phase. Object Reference itself is directed and is more suitable for expressing the relationship we are discussing. Therefore, this relationship is rarely used during design, and associations are usually directed.

The code generated using Rose is as follows:

Class C1
...{
Public:
C2 * thec2;

};

Class C2
...{
Public:
C1 * Thec1;

};

Two-way association shows that both parties have a pointer to each other in the Code. Of course, it can also be a reference or a value.

Unidirectional Association:
C3-> C4: indicates the acquaintance relationship. C3 knows C4 and C3 can call the common attributes and methods of C4. There is no life cycle dependency. It is generally a reference.

The generated code is as follows:

Class C3
...{
Public:
C4 * thec4;

};

Class C4
...{

};

Code with one-way association shows that C3 has C4 pointer, while C4 has no knowledge about C3.

Self-Association (reverse Association ):
Reference yourself with your own reference.

The Code is as follows:

Class C14
...{
Public:
C14 * thec14;

};

That is, there is a reference within your own.

2. Aggregation/Combination

When there is an integral-partial relationship between classes, we can use combination or aggregation.

Aggregation: indicates that c9 aggregates C10, but C10 can leave C9 and exist independently (the existence of this class makes sense in the problematic domain of an application. For more information about this sentence, see the explanation in the combination below ).

The Code is as follows:

Class C9
...{
Public:
C10 thec10;

};

Class C10
...{

};

 

Combination (also known as inclusion): it is usually indicated by solid diamond and solid line arrows, as shown in. It indicates that C8 is tolerated by C7, and C8 cannot be independent from C7. However, this depends on the problem domain. For example, in the field of concerned about automobiles, tires must be combined in the automobile industry because it makes no sense when it leaves the automobile. However, in the shops where tires are sold, even if the tires leave the car, it makes sense, and this can be aggregated. In Agile development, we also said that if a combines B, A needs to know the lifecycle of B, that is, a may be responsible for generating or releasing B, or a knows the generation and release of B in some way.

Their code is as follows:

Class C7
...{
Public:
C8 thec8;

};

Class C8
...{
};

As you can see, code is the same as aggregation. The specific differences may only be distinguished by semantics.

3. Dependency

Dependency:
Some methods of C6 may be used in C5. You can also say that the assistance of C6 must be provided to complete all functions in C5. C5 depends on the definition of C6. It generally contains the header file of C6 in the header file of C5 class. Rose does not generate attributes for the dependency.

Note: Avoid bidirectional dependency. Generally, there should be no two-way dependency.

The code generated by Rose is as follows:

// C5.h
# Include "c6.h"

Class C5
...{

};

// C6.h
# Include "c5.h"

Class C6
...{

};

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

# Include "B. H"
Class
...{
Void func (B & B );
}

What is the difference between dependency and aggregation/combination and association?

Association is a kind of relationship between classes. For example, teachers teach students, husbands and wives, and water bottles are a kind of relationship. This relationship is very obvious and can be obtained directly through analysis in the problem field.

Dependency is a weak Association. When one class uses another class, but the relationship with the other class is not too obvious (it can be said that the class is "uses ), we can regard this relationship as dependency, and dependency can also be said to be an accidental relationship, rather than an inevitable relationship, that is, "I accidentally used it in a method, but in reality, I have little to do with it ". For example, I have nothing to do with a hammer, but I used it when I had to nail it. This is a dependency that relies on a hammer to complete the dingtalk.

A combination is a whole-part relationship. In the problem domain, this relationship is obvious and can be obtained through direct analysis. For example, tires are a part of a car, leaves are a part of a tree, and hands and feet are a part of the body. This relationship is very obvious as a whole-part relationship.

The preceding relationships (Association, aggregation/combination, and dependency) may appear in the code in the form of pointers, references, values, and so on in another class, but logically, they have the above differences.

It should also be noted that the so-called relationships are valid only in a problem domain. If the problem domain is left, these relationships may not be valid, for example, they may be in a problem domain, I am a carpenter and need to work with a hammer. The whole problem may be described as how to pin the table, chair, and cupboard with a hammer. Since the whole problem is described as follows, the relationship between me and the hammer is not only accidental dependencies, but the relationship between me and the hammer has become very close and may rise to a combination relationship (reminds me of the sword of martial arts novels, the sword is dead ...). This example may be a bit ridiculous, but it is also to illustrate the truth that, like links and classes, they are all established in a problem field and leave this problem field, they may no longer exist.

4. generalization (inheritance)

Generalized relationship: This is used if two classes have generalized relationships, such as parent and child, animals and tigers, plants and flowers.
The code generated by Rose is as follows:

# Include "c11.h"

Class C12: Public C11
...{
};

5. The template is mentioned here by the way.

The code for the above figure is as follows:

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

Let's talk about the degree of repetition. In fact, after reading the above description, we should be clear about the relationship between the various relations and what the code is like, the so-called degree of repetition, it is just an extension above. For example, if a and B have a "one-to-many" repetition degree, there is a list in a that stores n references of object B, that's all.

Now, I have finished the class graph relationship above. I hope you will get something better. I have also spent a lot of time (drawing, generating code, writing to blog, alas, a sweat ). However, it is worth it if you can thoroughly understand the relationships of UML class diagrams. :)

++ ++

In UML modeling, it is essential to understand the elements that appear on a class diagram. Developers must understand how to convert elements on the class diagram to Java. Java is used as a representative to combine some online instances. Below are some basic collection and summary of the individual: basic element Symbol: 1. Class (classes) class contains three components. The first is the class name defined in Java. The second is attributes ). The third is the method provided by this class. You can append a visibility modifier before attributes and operations. The plus sign (+) indicates public visibility. Minus (-) indicates private visibility. # Indicates protected visibility. Omitting these modifiers indicates visibility at the package level. If an attribute or operation has an underscore, it indicates that it is static. In the operation, you can also list the parameters it accepts and the return type, as shown in:

2. package is a combination mechanism for common purposes. A package in UML corresponds directly to a package in Java. In Java, A package may contain other packages, classes, or both. During modeling, you usually have a logical package, which is mainly used to organize your model. You will also have a physical package, which is directly converted into a Java package in the system. The name of each package uniquely identifies the package.

3. An interface is a collection of operations that specify the services provided by a class. It directly corresponds to an interface type in Java. The interface can be expressed by the icon below (the circle symbol above, the interface name below the circle symbol, the line in the middle, and the method name below the line ), it can also be represented by a standard class appended with <interface>. Generally, you can know the relationship with other classes based on the interface in the class diagram.

Dependency: 1. A "use" Relationship Between dependencies indicates that the specification of an object may affect other instances dependent on it. 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 obtained through method call (as shown in the following example ), or reference a static method of a class (there is no instance of that class at the same time ). You can also use "dependency" to indicate the relationship between packages. Because the package contains classes, you can express the relationship between packages and packages based on the relationships between classes in those packages.

2. a structured relationship between Association entities indicates that objects are connected to each other. The arrow is optional and is used to specify the navigation capability. Without arrows, it implies a two-way navigation capability. In Java, the Association is converted to an instance-scope variable, just like the code shown in the "Java" Area in Figure E. You can append other modifiers to an association. The multiplicity modifier implies the 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.

3. Aggregation is a form of association, representing the overall/local relationship between two classes. Aggregation implies that the whole is at a level higher than the local level, while association implies that two classes are at the same level in concept. Aggregation is also converted to an instance scope variable in Java. The difference between Association and aggregation is purely conceptual and strictly reflected in semantics. Aggregation also implies that there is no loop in the instance diagram. In other words, it can only be a unidirectional link.

4. Composition synthesis is a special form of aggregation, which implies the lifetime responsibilities of "local" within "Overall. Synthesis is not shared. Therefore, although local data may not be destroyed as a whole, it is either responsible for local survival or destruction. It cannot be shared with other entities. However, ownership can be transferred to another object as a whole, and the latter will assume the responsibility for survival. The relationship between employee and timecard may be more suitable for "merging", rather than "associating ".

5. generalization indicates the relationship between a more generalized element and a more specific element. Generalization is a UML element used to model inheritance. In Java, the extends keyword is used to directly represent this relationship.

6. Implement (realization) an instance relationship specifying a contract between two entities. In other words, one entity defines a contract, and the other entity guarantees the performance of the contract. When modeling a Java application, the implementation relationship can be expressed directly by the implements keyword.

Like aggregation is also divided into: Non-shared aggregation, shared aggregation, composite aggregation and so on. And other content.