UML class diagram relationships (generalization, inheritance, implementation, dependency, association, aggregation, and combination)

Connections and differences between inheritance, implementation, dependency, association, aggregation, and combination

These relationships are described respectively:

Inheritance

A class (called a subclass or sub-interface) inherits the functions of another class (called parent class or parent interface) and can add its own new functions, inheritance is the most common relationship between classes or interfaces. in Java, such relationships are identified by the keyword extends, which is generally not controversial during design;

Implementation

It refers to the function of a class to implement interface interfaces (which can be multiple). Implementation is the most common relationship between classes and interfaces. in Java, such a relationship is identified by the keyword implements, it is generally not controversial during design;

Dependency

It can be simply understood that A class A uses another class B, and this relationship is contingent, temporary, and very weak, but changes in Class B will affect A. For example, if someone wants to cross the river and borrow A ship, the relationship between people and the ship is dependent. It is manifested in the Code layer, class B is used as A parameter by Class A in A method;

Association

It represents a strong dependency between two classes or between classes and interfaces, such as my friends and I; this relationship is more dependent than the dependency relationship, with no dependency relationship. The relationship is not temporary and is generally long-term. In addition, the relationship between the two parties is generally equal, and the relationship can be one-way and two-way; it is manifested in the Code layer. For associated Class B, it appears in the form of class attributes in associated Class, it may also be that associated Class A references A global variable of the associated Class B;

Aggregation

Aggregation is a special case of association. It reflects the relationship between the whole and the part, that is, the relationship between has-a. At this time, the whole and the part can be separated, they can have their own lifecycles, some of which can belong to multiple objects, or share multiple objects, such as the relationship between computers and CPUs, and between companies and employees; it is manifested at the code level and is consistent with the Association, which can only be distinguished at the semantic level;

Combination

A combination is also a special case of association. It represents a contains-a relationship, which is stronger than aggregation, also known as strong aggregation; it also shows the relationship between the whole and the part, but the whole and the part are inseparable at this time, and the end of the overall life cycle means that part of the life cycle ends; for example, you and your brain; it is manifested at the code level and is consistent with the Association, which can only be distinguished at the semantic level;

There is no doubt about the relationship between inheritance and implementation. They reflect the vertical relationship between a category and a class, or between a class and an interface; the other four relationships reflect the reference and horizontal relationships between classes and classes, or between classes and interfaces, which is difficult to distinguish, there are many relationships between things. It is very difficult to prepare for positioning. As mentioned above, these relations are all semantic-level, so they cannot be fully differentiated from each other at the code level;

However, in general, the following relationships show the following strengths and weaknesses:Combination> aggregation> association> dependency;

Aggregation and combination are actually associated, but they are two special associations. Because they are the same root, there will inevitably be similarities between them. Let's take a look at the differences between them.

I believe the concept of aggregation and combination does not need to go into details here. You have already understood the following example.

In the story of Jack Cheng, the example of the big goose is very relevant here. I will use it here. The geese like to be lively and afraid of being alone. So they have been living in a group, so they have a group of every one. geese have their own wild geese. Each group has many wild geese. This relationship can be called aggregation. In addition, each wild goose has two wings. The relationship between the wild geese and the wild geese is called combination. it can be seen that the relationship of aggregation is obviously not closely formed. The geese cannot survive because their Group Owners disband the geese, and the geese cannot survive independently because they have the same life cycle.

Aggregation relationship diagram:

Combination relationship diagram:

The differences between the two relationships are as follows:

Different Constructors

Geese:

[Csharp]View plaincopy

1. Public ClassGooseGroup
2. {
3. PublicGoose goose;
6. PublicGooseGroup (Goose goose)
7. {
8. This. Goose = goose;
9. }
10. }

[Csharp]View plaincopy

1. Public class GooseGroup
2. {
3. Public Goose goose;
6. Public GooseGroup (Goose goose)
7. {
8. This. goose = goose;
9. }
10. }

Geese:

[Csharp]View plaincopy

1. Public ClassGoose
2. {
3. PublicWings wings;
5. PublicGoose ()
6. {
7. Wings =NewWings ();
8. }
9. }

[Csharp]View plaincopy

1. Public class Goose
2. {
3. Public Wings wings;
5. Public Goose ()
6. {
7. Wings = new Wings ();
8. }
9. }

The aggregate link class contains another class as the parameter.
In the GooseGroup constructor, Goose is used as a parameter to pass in the value. Goose can exist independently of the geese.
Classes in the composite relationship contain the instantiation of another class.
Before instantiating Goose, you must first instantiate the Wings class (Wings). The two classes are closely coupled. They have the same life cycle Wings class (Wings) it cannot exist independently from Goose
Different information Encapsulation
In the aggregation relationship, the client can understand both the geese and geese at the same time, because they are independent
In the composite relationship, the client only recognizes the geese and does not even know the existence of the wings, because the wings are tightly encapsulated in the geese.

Bytes -------------------------------------------------------------------------------------------------------

UML-generalization, association, aggregation, combination, dependency

1. generalization)

1. Description

Represents the inheritance relationship between classes, the inheritance relationship between interfaces, or the Implementation relationship between classes on interfaces. The general relationship is directed from the subclass to the parent class, which is opposite to the inherited or implemented method.

2. Example Diagram

3. Performance

Parent class instance = new subclass ();

4. Example

Class Animal {};

Class Tigger: public Animal {};

Class Dog: public Animal {};

Animal * pAnimal = new Dog;

2. association)

1. Description

For two relatively independent objects, when the instance of one object has a fixed ing relationship with some specific instances of the other object, the two objects are associated.

Indicates the link between a class and a class. Two-way Association and one-way association exist. Two-way Association has two arrows or no arrows. One-way Association has one arrow, indicating the direction of association.

Associations exist in the form of instance variables. In each associated endpoint, there can also be a base (multiplicity), indicating that the class at this end can have several instances.

2. Example Diagram

3. Performance

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.

Associations are implemented using instance variables.

4. Example

// Eg.1

// Unidirectional Association

Class Person {};

Class Friend

{

Person * mpPerson;

};

// Eg.2

// Bidirectional Association

Class;

Class B

{

A * pA;

};

Class

{

B * pB;

};

// Eg.3

// Self-Association

Class C

{

C * pC;

};

3. aggregation)

1. Description:

A strong association is a type of association. Aggregation is the relationship between the whole and the individual. The aggregation relationship is also implemented through instance variables. For example, an automobile, an engine, or a tire consists of an engine object and four tire objects.

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

2. Example Diagram

3. Performance

Like the association relationship, the aggregation relationship is also implemented through instance variables. There is no way to distinguish between associations and aggregation syntactically. In terms of semantics, the difference between the two can be better distinguished.

4. Example

Class CPU {};

Class Memory {};

Class Computer

{

CPU * mpCPU;

Memory * mpMemory;

};

4. composition)

1. Description:

The compositing relationship is also a type of association relationship, which is stronger than the aggregation relationship. The compositing relationship cannot be shared. For example, a person has four limbs and a first class.

Indicates the relationship between the whole and the part of the class. The partial and the whole of the combination have a unified survival period. If the overall object does not exist, some objects do not exist. Some objects have a symbiotic relationship with the entire object.

2. Example Diagram

3. Performance

4. Example

// Same aggregation relationship, but different Semantics

Class Leg {};

Class Arm {};

Class Person

{

Leg mLeg;

Arm mArm;

};

5. Dependency)

1. Description:

For two relatively independent objects, when one object is responsible for constructing an instance of another object or dependent on the service of another object, the two objects are mainly dependent on each other.

Different from associations, dependencies are transmitted to dependency classes in the form of parameter variables. dependencies are unidirectional and bidirectional dependencies must be avoided. Generally, there should be no two-way dependency.

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.

2. Example Diagram

3. Performance

Dependencies are manifested in local variables, method parameters, and calls to static methods.

4. Example

Class Car {};

Class House {};

Class Person

{

Void buy (Car & car ){}

Void buy (House * pHouse ){}

};

Vi. Differences between links

1. Aggregation and combination

(1) Aggregation and combination are a combination, but they only have an additional meaning of the whole-part.

(2) Different parts have different lifecycles.

In the aggregate relationship, the whole part does not have the life cycle of the part, so the part will not be deleted when the whole part is deleted. In addition, multiple parts can share the same part.
In the composite relationship, the whole part has the life cycle of the part. Therefore, when the whole part is deleted, the part will be deleted. In addition, multiple parts cannot share the same part at the same time.

(3) The aggregation relationship is the "has-a" link, and the combination relationship is the "contains-a" link.

2. Association and aggregation

(1) It is represented at the code level and is consistent with the association. It can only be distinguished at the semantic level.

(2) The difference between Association and aggregation is mainly in terms of semantics. The two objects associated are generally equal. For example, if you are a friend of mine, aggregation is generally not equal.

(3) Association is a structured relationship, that is, an object is associated with another object.

(4) Association and aggregation depend on the problem domain. For example, tires must be combined in the automobile field, it makes no sense when it leaves the car. However, in the shops where tires are sold, even if the tires leave the car, it makes sense, and this can be aggregated.

3. Association and dependency

(1) A strong dependency between two classes or between classes and interfaces, such as my friends and I; such a relationship is more dependent than the dependency, and does not have any dependency relationship. The relationship is not temporary and generally long-term, and the relationship between the two parties is generally equal.

(2) In dependency relationships, we can simply understand that A class A uses another class B, and this relationship is contingent, temporary, and very weak, but changes in Class B will affect.

4. comprehensive comparison

These relationships are semantic-level, so they cannot be fully differentiated from each other at the code level. However, in general, the strength and weakness of these relationships are as follows:

Combination> aggregation> association> dependency;

Certificate -----------------------------------------------------------------------------------------------------------------------------------------------

UML line arrow

Link

The following examples show various relationships for a specific purpose. Although the syntax is correct, these examples can be further refined to include more semantics within their effective scope.

Dependency)

An "use" Relationship between entities implies that after a specification of an object changes, other instances dependent on it may be affected (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 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.

Figure D

Association)

A structured relationship between objects 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 (Figure E) To an instance scope variable, as shown in the code 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.

Figure E

 

Aggregation)

Aggregate (Figure FIs 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.

Figure F

 

Composition)

Synthesize (Figure G) Is a special form of aggregation, suggesting that "local" is responsible for the lifetime of the "whole. Synthesis is not shared. Therefore, although local data may not be destroyed as a whole, it is either responsible for keeping the Department alive or destroying it. 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 ".

Figure G

 

Generalization)

Generalization (Figure H) Represents the relationship between a more general element and a more specific element. Generalization is a UML element used to model inheritance. In JavaExtendsKeyword to directly represent this relationship.

Figure H

 

Implementation)

Instance (Figure I) Link specifies 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 Java applications, the implementation relationship can be directly usedImplementsKeyword.

Figure I

 

Certificate -----------------------------------------------------------------------------------------------------------------------------------------------

UML class diagram relationships include association, dependency, generalization, implementation, etc. Are you familiar with their representation methods? This article is like introducing the representation of UML class diagram relationships.

AD:

This section describes how to express a UML class diagram relationship, including Association, aggregation, generalization, implementation, and dependency, we hope that you can have a certain understanding of the Presentation Methods of UML class diagrams through this section. The following is a detailed introduction.

UML Basics

1: Types of UML inter-class relationships

2: Join

A uml class diagram link describes the discrete connections between objects or instances in the system. It associates with information about the relationships between objects in the system.

2.1 Association notation

2.2 aggregation and combination

3: Generalization, inheriting [Generalization]

Generic relationships in UML class diagrams are the relationships between general descriptions of class elements and specific descriptions. The specific descriptions are based on general descriptions and are extended.

4: Implement [realization]

The implementation relationship in a UML class diagram link a model element (such as a class) with another model element (such as an interface). The interface is only a description of the action rather than a structure or implementation.

5: dependency [Dependence]

Dependency in a UML class diagram relationship indicates the semantic relationship between two or more model elements. It only connects the model elements themselves and does not need a group of instances to express their meaning. It indicates a situation where changes to the provider may require or indicate changes to customers in the dependency.

5.1 types of Dependencies

Access: Allow one package to access another package [access]

Binding: assign values to template parameters to generate a new model element [bind]

Call: declare a class to call methods of other classes [call]

Export: declare an instance to [derive] from another instance]

Youyuan: allows one element to access another element, regardless of the visibility of the accessed element [friend]

Introduction: Allow one package to access the content of another package. Add the alias [import] to the components of the unaccessed package]

Instantiation: about the life of an instance of another class generated by a class method [instantate]

Parameter: the relationship between an operation and its parameters [parameter]

Implementation: description and the ing relationship between them [realize]

Precision: declare the ing relationship between two elements at different levels. [refine]

Sending: Relationship between the sender and receiver [send]

Tracking: Declares connections between elements in different models without precise trace ing [trace]

Use: declare to use a model element requires another existing model element to correctly implement the user's functions (call, instantiate, parameter, send) [use]

6: Constraints

Constraints in UML class diagrams can be used to represent non-local relationships, such as restrictions on the associated path. Constraints can be particularly used to express existing features (if X exists, the C condition is true) and general features (for all Y in y, condition D must be true ).

7: instance

An instance is a running entity with an identity, that is, it can be differentiated from other running entities. It has a value at any time, and the operation value on the instance will also be changed.

Certificate -----------------------------------------------------------------------------------------------------------------------------------------------

There is a relationship between the class and the class:
(1) Generalization)
(2) Association)
(3) Dependency)
(4) Aggregation)
UML diagram and application code example:
1. Generalization)
[Generalization]
Represents the inheritance relationship between classes, the inheritance relationship between interfaces, or the Implementation relationship between classes on interfaces. The general relationship is directed from the subclass to the parent class, which is opposite to the inherited or implemented method.
[Specific performance]
Parent class instance = new subclass ()
[UML diagram] (Fig. 1.1)
Figure 1.1 generalized relationship between Animal class and Tiger class and Dog class
[Code performance]
Class Animal {}
Class Tiger extends Animal {}
Public class Test
{
Public void test ()
{
Animal a = new Tiger ();
}
}
2. Dependency)
[Dependency]
For two relatively independent objects, when one object is responsible for constructing an instance of another object or dependent on the service of another object, the two objects are mainly dependent on each other.
[Specific performance]
Dependencies are manifested in local variables, method parameters, and calls to static methods.
[Real-world example]
For example, if you want to screw the screw, do you want to use (that is, rely on) the screw driver to help you complete the screw (screw) work?
[UML representation] (Figure 1.2)
Figure 1.2 dependency between the Person class and the Screwdriver class
[Code performance]
Public class Person {
/** Screw */
Public void screw (Screwdriver screwdriver ){
Screwdriver. screw ();
}
}
3. Association)
[Association]
For two relatively independent objects, when the instance of one object has a fixed ing relationship with some specific instances of the other object, the two objects are associated.
[Specific performance]
Associations are implemented using instance variables.
[Real-world example]
For example, for customers and orders, each order corresponds to a specific customer, and each customer corresponds to a specific order. For example, for companies and employees, each company corresponds to a specific employee, each employee corresponds to a specific company
[UML diagram] (Fig. 1.3)
Figure 1.3 association between companies and employees
[Code performance]
Public class Company {
Private Employee employee;
Public Employee getEmployee (){
Return employee;
}
Public void setEmployee (Employee employee ){
This. employee = employee;
}
// Company operation
Public void run (){
Employee. startWorking ();
}
}
(4) Aggregation)
[Aggregation]
When object A is added to object B and becomes an integral part of object B, object B and object A are clustered. Aggregation is a type of association. It is a strong association, emphasizing the relationship between the whole and the part.
[Specific performance]
Like the association relationship, the aggregation relationship is also implemented through instance variables. There is no way to distinguish between associations and aggregation syntactically. In terms of semantics, the difference between the two can be better distinguished.
[Differences between Association and aggregation]
(1) The two objects involved in the Association are at the same level. For example, people and bicycles are associated rather than aggregated, because people are not composed of bicycles.
The two objects involved in an aggregation relationship are at an unequal level. One represents the whole and the other represents the part. For example, the computer and its display, keyboard, motherboard and memory are clustered, because the motherboard is part of the computer.
(2) For two objects with a clustering relationship (especially a strong clustering relationship), the overall object will restrict the lifecycle of the object that consists of it. Objects of a partial classification cannot exist independently. The lifecycle of an object depends on the lifecycle of the object of the entire class. When the entire lifecycle disappears, the partial lifecycle disappears. For example, if Michael's computer is stolen, all the components of the computer do not exist, unless Michael has removed some computer components (such as hard disks and memory) beforehand.
[UML diagram] (Fig. 1.4)
Figure 1.3 computer and component Aggregation
[Code performance]
Public class Computer {
Private CPU;
Public CPU getCPU (){
Return cpu;
}
Public void setCPU (CPU cpu ){
This. cpu = cpu;
}
// Enable the computer
Public void start (){
// Cpu operation
Cpu. run ();
}
}

Certificate -----------------------------------------------------------------------------------------------------------------------------------------------

Relationship between class charts and class charts

1. Class Diagram and object Diagram

Class digraphs are graphs showing classes, interfaces, and their static structures and relationships. The most basic unit is a class or interface.

A class chart not only represents the relationship between classes (or interfaces), but also between objects. The following is a typical class diagram:

A class chart is generally divided into several parts: Class Name, attribute, and method. The following is a separate explanation.

(1) Class Name

The Car above is the class name. If the class name is a positive character, it indicates that the class is a specific class. If the class name is italic, it indicates that the class is an abstract class.

(2) attribute list

The attribute can be public, protected, or private. The icon in front of "public" is a diamond, "protected" corresponds to a diamond key, and "private" corresponds to a diamond lock. Of course, this is just a manifestation. I use Rational Rose. If other software is used, +,-, and # may be used to indicate: + represents public,-represents private, and # represents protected.

(3) method list

The methods can be public, protected, or private. The icon in front of "public" is a diamond, "protected" corresponds to a diamond key, and "private" corresponds to a diamond lock. Of course, this is just a manifestation. I use Rational Rose. If other software is used, +,-, and # may be used to indicate: + represents public,-represents private, and # represents protected.

For static attributes, the attribute name is underlined. As shown in.

In addition, a class chart can represent the relationship between classes and between objects. The difference between the two is that the object name in the object graph is underlined.

2. Relationships in class diagrams

(1) Generalization: Generalization and Generalization

Generalization indicates the inheritance relationship between classes, the inheritance relationship between interfaces, and the Implementation relationship between classes and interfaces. If embodied in the Java language, it is to reflect the extends and implements keywords. The typical class diagram is as follows:

(2) Association: Association

An Association describes the connection between a class and a class. It indicates that a class knows the attributes and methods of another class. Associations can be unidirectional or bidirectional. In Java, one-way associations are implemented by holding the reference of the associated object in the form of instance variables. Generally, two-way associations are not recommended. The following is an example of a one-way Association.

The above class diagram shows the relationship between the rider and the horse. One instance variable type in Rider is Horse.

Each connection has two endpoints. The above Rider and Horse are endpoints, and each endpoint can have (optional) a base (multiplicity), indicating that this class can have several instances. This is similar to the 1: n, m: n relationships in the database. We can add the base number to the above example:

It indicates the 1-to-n relationship between the rider and the horse.

(3) Aggregation: Aggregation relationship

An aggregate is a part of an association and a very strong association. The aggregation relationship shows the relationship between the whole and the part. For example, the relationship between cars, doors, and engines. :

Like the association relationship, the aggregation relationship is also implemented through instance variables. From the perspective of syntax, the Association and aggregation relationships cannot be determined.

(4) Composition: compose

A composite relationship is also a type of association relationship, which is more enhanced than an aggregation relationship. As mentioned above, an aggregation relationship represents the relationship between the whole and the part. A composite relationship represents an inseparable relationship between the whole and the part based on the aggregation relationship. That is to say, the whole object must be responsible for representing the lifecycle of some objects.

"The whole object is responsible for keeping part of the objects that represent them alive, and in some cases it is responsible for destroying part of the objects that represent them. Objects that represent the whole can sometimes be passed to another object, which is responsible for representing the lifecycle of some objects. In other words, some objects can only form a combination with one object at a time. And the latter is exclusive for its lifecycle ." -- Java and Mode

Let's take the relationship between people and arm as an example. The class diagram of the composite relationship is as follows:

(5) Dependency: Dependency

Dependency indicates that one class depends on the definition of another class. The dependency is in the single direction. People who eat apple are dependent on apple. The class diagram is as follows:

In general, the dependent object is usually stored in the object in the form of local variables and method parameters. Unlike the association relationship, it does not exist in the object in the form of member variables. This is worth noting. In addition, each dependency has a name. The above dependency is named eats.

The preceding figure shows the relationship between a class chart and a common class chart.