Six relationships of UML class diagrams and uml class diagrams

Six relationships of UML class diagrams and uml class diagrams

I have completed about 1/3 of the rebuild series. In these articles, I used some simple class diagrams to describe the rebuild policy. In subsequent articles, I may introduce it with a slightly more complex UML class diagram. But before that, I think it is necessary to first introduce the six relationships in the UML class diagram. These six relationships are: Inheritance (Inheritance), Implementation (Implementation), Dependency (Dependency), Association (Association), Aggretation (aggregation), and Composition (combination ). In these six relationships, dependency, association, aggregation, and combination are confusing. I will also explain the differences between them.

Introduction to UML class diagrams

UML is the abbreviation of Unified Modeling Language. It is translated into Chinese as "Unified Modeling Language" and is a standardized Modeling Language for Object-Oriented software. It is a graphical language that supports modeling and software system development. It provides modeling and visualization support for all stages of software development, from Requirement Analysis to specification, to construction and configuration.

Different software in different organizations have different types of UML. Basically, all UML software includes the following four types:

1. use case diagram
2. Class Diagram
3. activity diagram
4. Sequence diagram UML class diagram

A uml class diagram is used to show a group of objects, interfaces, collaboration, and relationships between them. A class chart describes a static relationship that is valid throughout the lifecycle of the system. It is the most common graph in object-oriented system modeling.

UML tools

There are a lot of tools and software for UML on the market. I will not introduce them much if you have different tastes. My most commonly used UML tool is Visio.

Of course, as a. NET developer, Ultimate Visual Studio also provides the UML modeling function.

Inheritance)

Inheritance indicates that a class (Interface) inherits the functions and attributes of another class (Interface) and describes the relationship between the parent class (Interface) and the subclass (interface.
The inheritance describes the "is a kind of" relationship. For example, Manger is a kind of Employee, and Manager inherits all the functions of Employee (such as card sign-in and work execution) and attributes (for example, employee name and start time ).

In UML, the inheritance is represented by a solid-line hollow arrow, which points to the parent class (interface ).

 

Implementation)

Implementation indicates that the class implements the interface function.

In UML, the inheritance is represented by a dotted-line hollow arrow, which points to the interface.

Differences between inheritance and implementation

Although both C # relay and implementation are represented by symbols (extends represents inheritance in java and implements represents implementation), there are still some differences between the two.

1. Inheritance occurs between "Class and Class" or "interface and interface". For example, the subclass inherits the parent class, and the Child interface inherits the parent interface.

Subclass inherits the parent class:

public abstract class Animal{        }public class Bird : Animal{        }

The sub-interface inherits the parent interface:

public interface ITransportation{    void Move();}public interface IVehicle : ITransportation{        }

2. Implementation occurs between "class and interface". For example, a class implements an interface method.

Public interface IVehicle: ITransportation {} public class Car: IVehicle {public void Move () {Console. WriteLine ("Car running ...");}}

3. in C #, multi-inheritance is actually multi-implementation.

Unlike the C ++ syntax, C # classes cannot inherit multiple classes at the same time. C # Only inherits one class, but multiple interfaces can be implemented at the same time.
For example, the Controller class in ASP. net mvc inherits the ControllerBase class and implements IActionFilter, IAuthenticationFilter... .

public abstract class Controller : ControllerBase, IActionFilter, IAuthenticationFilter, IAuthorizationFilter,    IDisposable, IExceptionFilter, IResultFilter, IAsyncController, IAsyncManagerContainer{}

Dependency, association, aggregation, and Dependency are the most basic relationships between objects.
When an object (caller) needs to call the method of another object (called) to complete some work, the dependency is established.

In UML, dependencies are represented by dotted arrows, which point to the depended party.

For example, in Web Service, the Client needs to call the Service operation, which indicates that the Client depends on the Service.

Association indicates the Association between multiple objects.
Each object has its own lifecycle, and there is no subordination between objects.

In UML, associations are expressed in a straight line.

For example, Student and Teacher belong to "Association". Multiple Student can be associated with one Teacher, and one Student can be associated with multiple Teacher.
However, there is no "subordinate" or "include" relationship between Teacher and Student.

Aggregation reflects the relationship between the whole and the part, that is, the "has-a" relationship.
The whole and the part can be separated, that is, both the whole and the part can have their own lifecycles.

In UML, the aggregation relationship is represented by a hollow diamond arrow, and the arrow points to the whole.

For example, a Department has multiple employees. As a whole, the Employee in the Department is part of the Department.
Both Department and Employee have their own lifecycles. When a Department is revoked, the Employee can be transferred to another Department or quit.
When the Employee is transferred to another Department or resigned, the Department still exists.

Composition is the relationship between the whole and the part, that is, the "is-a" relationship.
A composite relationship is a more powerful aggregation relationship, and the whole and part cannot be separated.
When the overall life cycle ends, it also means that part of the life cycle ends.

In UML, the composite relationship is represented by a solid diamond arrow, and the arrow points to the whole.

For example, a house has multiple rooms, which are part of the house. The life cycle of a room depends on the life cycle of the house. When the house is demolished, the room does not exist.

Differences between dependency, association, aggregation, and combination

Dependency, association, aggregation, and combination can all be referred to as "dependency ".
When the relationship between objects is Association, Aggregation, or Composition, the dependency between objects is also established.
They show different levels of Dependency strength. These four relationships show the following levels of strength: Composite> Aggregation> Association> Dependency.

Association, aggregation, and combination are three relationships that are often confusing. The biggest difference between these relationships is the object lifecycle.

1. Relationship: each object has its own lifecycle, and there is no subordination between objects.
2. Aggregation relationship: the whole and part cannot be separated, and both the whole and part can have their own lifecycles.
3. Composite relationship: the whole and the part cannot be separated. When the overall lifecycle ends, it also means that part of the lifecycle ends. Are these relationships necessary?

Today, some readers have asked the following question: are these symbols necessary?
My answer is: it varies with the team. It depends on the way the team communicates and communicates with each other, and on the ability of the team members.
UML is a communication language. You can use it to fuzzy express a piece of content. You can also accurately describe the content as long as other members of the team can understand what you mean.
Communication is guided by results. You do not have to stick to the communication method, but it is especially important to express the results accurately and effectively. The "accuracy" here does not mean to use UML Symbols accurately, it means that others can understand what you express accurately.

I personally think: when it comes to key models in the system, it is still important to express the relationship with exact symbols.
For example, in a procurement system, you have a purchase application → purchase order process. The purchase application is created after the user selects the product and supplier, and the purchase order is generated by the approved purchase application.
There are three pairs of links:
1. Relationship between procurement application and procurement application details
2. Relationship between purchase order and purchase order details
3. Relationship between purchase application and purchase order

From the business point of view, 1 and 2 are a combination, and 3 is an association. If 1, 2, and 3 are understood as dependencies in general terms, some problems may occur.
During the design process, if we correctly describe these three pairs of relationships, the following actions can be summarized based on the exact relationship when deleting a document:

1. When deleting a purchase application, the purchase application is also deleted (because they are a combination relationship)
2. When a purchase order is deleted, the Order details are also deleted (because they are a combination)
3. When a purchase order is deleted, the purchase application is not affected (because they are associated)