Design pattern--1. Overview &uml class Diagrams and time series diagrams

Statement: Design Patterns related articles are organized and modified from the network, the original address: Diagram design mode

3 levels of learning design patterns--

1. Familiar with all design patterns;

2. Can be implemented in code;

3. Apply to the project of the work.

Design Patterns Guide The development of software, learning design patterns first need to understand the relevant UML diagram , the following will be related to the UML class diagram.

It is important to understand the relationship between the classes in the class diagram and the meaning of the lines and arrows between each class.

You should be able to match the meaning expressed by the class diagram with the final code.

First, starting from an example

Take a look at the class diagram below, the relationship between classes is what we need to focus on:

1. The car's class diagram structure is <<ABSTRACT>>, which means that the vehicle is an abstract class;

2. The car has two inheritance classes: cars and bicycles; the relationship between them is the realization of the relationship, using a dashed line with a hollow arrow to indicate;

3. The relationship between the car and the SUV (sports multi-purpose car) is a generalization relationship, which is represented by a solid line with a hollow arrow;

4. Between the car and the engine is a combination of relations, using a solid line with a diamond-shaped arrow representation;

5. Between the student and the class is the aggregation relation, uses the solid line with the hollow Diamond arrow to represent;

6. The relationship between the student and the identity card, using a solid line representation;

7. A bicycle is required for students to go to school, and a bicycle is a dependency that uses a dashed line with arrows.

These six relationships are described below.

Ii. relationship between Classes 1. Generalization Relationship (generalization)

The inheritance structure of a class is represented in UML as: generalization (generalize) and implementation (realize):

The relationship of the inheritance relationship is is-a, and if the two objects can be represented by is-a, it is an inheritance relationship: (...) Be ...).

Eg: Bicycles are cars, cats are animals

The generalization relationship is represented by a solid line with a hollow arrow. As indicated (a inherits from B):

Eg: automobiles are realized in reality and can be used to define specific objects; The generalization relationship between the automobile and the SUV;

Note: In the final code, the generalization relationship behaves as an inherited non-abstract class.

2. Implementation relationship (realize)

The implementation relationship is represented by a dashed line with a hollow arrow;

Eg: "Car" is an abstract concept, and in reality it cannot be used to define objects directly; only the specific subclass (car or bicycle) can be used to define the object.

Note: In the final code, the implementation relation manifests as inheriting abstract class;

3. Aggregation relationship (aggregation)

The aggregation relationship is represented by a straight line with a hollow diamond arrow, such as a aggregation to B, or b consisting of a.

An aggregation relationship is used to represent a relationship between entity objects, which represents a whole part of the semantics, such as a department consisting of multiple employees.

Unlike the combinatorial relationship, the whole and the part are not strongly dependent, even if the whole does not exist, the parts still exist. For example, departments are withdrawn, people do not disappear, they still exist.

4. Composition relationship (composition)

A composite relationship is represented by a line with a solid diamond arrow, such as a composition B, or b consisting of a.

As with aggregation relationships, a composition relationship also represents a whole part of the semantics, such as a company consisting of multiple departments.

But the combinatorial relationship is a special aggregation relationship with strong dependence, and if the whole does not exist, then the part does not exist. For example, the company does not exist, and the department will not exist.

5. Association Relationship (Association)

An association relationship is represented by a line that describes the structural relationships between objects of different classes. It is a static relationship, usually independent of the operational state, generally determined by common sense and other factors; it is generally used to define static, natural structures between objects. Therefore, association relationship is a kind of "strong association" relationship.

For example, a relationship between a passenger and a ticket is an association between a student and a school.

An association relationship defaults to a direction, which means that objects know each other. If the direction is particularly stressed, for example, indicates that a knows B, but B does not know A.

Note: In the final code, the associated object is usually implemented as a member variable.

6. Dependency relationship (dependency)

A dependency is represented by a set of dashed lines with arrows, such as a dependent on B; He describes the relationship that an object uses to another object while it is running.

Unlike association relationships, it is a temporary relationship that typically occurs during run time, and dependencies can change as the runtime changes.

Obviously, the dependence also has the direction, the bidirectional dependence is one kind of very bad structure, we should always maintain one-way dependence, eliminates the bidirectional dependence the generation.

Note: In the final code, the dependency is represented as an incoming parameter to the class constructor method and the class method, and the arrow points to the call relationship. dependencies, in addition to temporarily knowing each other, "use" each other's methods and properties.

Third, time series diagram

In order to show the interactive details between objects, time series diagrams are generally used when learning design patterns.

Time series diagrams (Sequence Diagram) are graphs that display the interaction between objects, which are arranged chronologically. The sequence diagram shows the order in which messages interact between the objects participating in the interaction and their objects.

The sequence diagram includes modeling elements such as: Object (Actor), Lifeline (Lifeline), control focus (focus on control), messages (message), and so on.

For the time series diagram, refer to the online related explanation.

Appendix

In Enterprise Architect (a software that draws UML diagrams), an abstract class is defined (its version is "abstract"):

Design pattern--1. Overview &uml class Diagrams and time series diagrams