preface

UML is for many programmers. Yes, but not fully. This article is a popular science of UML and a systematic introduction of UML knowledge system.

UML is a universal modeling language used to visualize, describe, construct, and document software systems. The integration of a variety of object-oriented modeling methods, the use of graphics and symbols, intuitive expression and display, link different industries/different professional people, build up the industry communication bridge.

There are four types defined in UML and a total of nine views.

View classification in UML

Use case diagram

Describe the system functionality from the perspective of external users and identify the implementers of the functionality.

Static figure

It shows the static structure of the system, especially the relationship between the internal structures of the kinds of things that exist. Contains class diagram, object diagram, package diagram.

The behavior

Describe the dynamic model of the system and the interaction between the components of the object, including interaction diagram, state diagram, activity diagram.

Realize the figure

Describes the composition and distribution of the software implementation system. Including component diagram, deployment diagram.

Graph LR (UML) -- > A C1 (use case diagram) A - - > B1 (static) A - - > B2 (action figure) A - > B3 (figure) B1 - > C2 (class diagrams) B1 - > C3 (object graph) B1 - - > C4 (package diagram) B2 - > C5 (state diagram) B2 - > C6 (interaction diagrams) B2 - > C7 (activity diagram) B3 - > C8 (component diagram) B3 - > C9 (deployment diagram)

The diagram above shows the classification of the nine views of UML. The following describes the nine views.

Use case diagram

First, use case diagrams. So what is a use case?

A use case is a sequence of verbal descriptions of interactions that occur when an actor uses a function of the system. Represents the contract between the people involved in the system regarding the behavior of the system.

Software development process can be divided into requirements analysis, design, implementation and other stages. In the requirements phase, use cases are the communication tool between analysts and customers and the basis for project sizing. In the design stage, use cases are the main input of system functions. In the implementation phase, a use case is a document that verifies the correctness of a class’s behavior. Therefore, object-oriented software development projects are use-case driven.

Writing a use case identifies the following elements

(1) Actor refers to things outside the system that need to use or interact with the system, including people, equipment and external systems. An actor can use multiple use cases, and a use case can be used by multiple actors. In the use case diagram, it is represented by a small person.

(2) Use Cases USE cases are externally visible system functions that describe the services provided by the system. It’s an ellipse.

(3) There is an association between use cases and users. Represented by the following graph:

Related:

There are inclusion, extension, generalization relationships between use cases and use cases.

Contains:

Extension:

Generalization:

(4) Subsystem is used to display some functions of the system, which are closely related.

Here is an example of a use case diagram:

The class diagram

The Class diagram shows the static structure of the model, especially the existing classes in the model, the internal structure of the classes and their relationship with other classes. Class diagrams do not display transient information. Class diagrams are an important part of object-oriented modeling. It is used for both general conceptual modeling of the system classification of applications and for detailed modeling, transforming the models into programming code. Class diagrams can also be used for data modeling.

  • class

Here’s a graph:

In the class diagram:

– private # protected ~ default _ static italic abstract

  • Relationships between classes

In UML class diagrams, the following relationships are common: Generalization, Realization, Association, Aggregation, Composition, and Dependency.

A generalization represents the inheritance relationship between classes, as shown below:

Implementation represents the functionality of a class class that implements the interface interface (which can be multiple). As shown below:

Dependency: For two relatively independent objects, when one object is responsible for constructing an instance of the other object, or depends on the services of the other object, the two objects are mainly dependent on each other. As shown below:

Association: For two relatively independent objects, when there is a fixed correspondence between an instance of an object and some specific instances of another object, the two objects are associated.

Aggregation: Represents a weak ‘owning’ relationship, that is, a has-A relationship, in which an object A can contain an object B, but the object B is not part of an object A. Both objects have their own life cycles.

Composition: Composition is a strong ‘ownership’ relation, and it is a relationship containing -a, which reflects the strict relationship between parts and the whole, and the life cycle of parts and the whole is the same.

Here is an example of a class diagram:

Object graph

There is no need to provide a separate form for object diagrams. A class diagram contains objects, so a class diagram with only objects but no classes is an “object diagram”. However, the phrase “object graph” is useful when describing specific uses of various aspects.

Interaction diagrams

Interaction diagrams are diagrams that describe the relationships between objects and the transfer of information between objects. Typically describes the behavior of a use case, showing the messaging between the objects involved in the use case. Interaction diagrams can help analysts check the user requirements described in each use case, such as whether they have been implemented in the classes that perform these functions, and remind analysts to fill in missing classes or methods.

Sequence diagrams (sequence diagrams), collaboration diagrams (communication diagrams) and interaction overview diagrams are collectively referred to as interaction diagrams. Sequence diagrams focus on the objects exchanging messages in chronological order, and collaboration diagrams focus on how system components work together. Here is a free template for Processon:

Package diagram

A “package diagram” can be composed of any kind of UML diagram, usually a UML use case diagram or a UML class diagram. A package is a UML structure that enables you to organize model elements such as use cases or classes into groups. Packages are described as folders that can be applied to any kind of UML diagram.

State diagram

The state diagram is used to describe the dynamic behavior of an object during its lifetime, which is represented by the sequence of states that an object experiences, the events that cause the state transition, and the actions that occur due to the state transition.

A thread health graph we are familiar with:

Activity diagrams

The activity diagram is one of five diagrams that model the dynamic behavior of the system. Activity diagrams can be used to describe the workflow and concurrent behavior of a system. In fact, an activity diagram can be regarded as a special form of a state diagram, in which an activity state is finished and the next activity is immediately entered. Here are some basic concepts:

  • activity

Can represent the execution of a statement during an algorithm. Care should be taken to distinguish between active and action states in an activity diagram. The action state is atomic, cannot be decomposed, there is no internal transfer, there is no internal activity, the time occupied by the action state is negligible, the purpose of the action state is to perform the entry action, and then move to another state. Active states are decomposable, not atomic, and take a certain amount of time to complete their work. Represented by rounded rectangles:

  • lane

Is the division of regions in the activity diagram. All activities are divided according to the responsibilities of each activity, with each lane representing an area of responsibility. Lanes and activities can make a many-to-one relationship. As shown below:

  • branch

In an activity diagram, for the same trigger event, you can move to different activities based on different alert conditions, and each possible shift is a branch.

  • Bifurcation and confluence

Branching means choosing one of many possible transitions of active state, and if you represent concurrent behavior in a system or object, you can use the modeling elements of branching and joining.

  • Object flow

Objects can appear in an activity diagram as inputs and outputs to an activity. Objects in an activity diagram represent relationships between activities and objects

Here is an example of an activity diagram (using a free template from Processon) :

Component diagram

A component is a physical, replaceable part of a system that complies with a set of interfaces and provides its implementation. A component diagram shows a set of components and their relationships to each other.

There are several types of components:

  • Deployment artifacts such as DLL files, COM+ objects, CORBA objects, EJBs, dynamic Web pages, and database tables.
  • Work product artifacts, such as source code files, database files, and so on, can be used to produce deployment artifacts.
  • The execution component, that is, the component obtained after the system is executed.

The following is a free template from Processon:

Deployment diagram

The deployment diagram also includes configuration diagram and implementation diagram, which can be used to display the topological structure and communication path of computer nodes in the system and the software components running on the nodes. A system has only one deployment diagram, and deployment diagrams are often used to understand distributed systems. Deployment diagrams are described by architecture designers, network engineers, systems engineers, and so on. Here is an example of a simple deployment diagram: