UML usage experience and summary

Today, we finally started using UML for project analysis, and found that the time overhead for using UML is not as high as we previously thought.

Review the experience of using UML is always intermittent. To sum up, there are the following factors:

1. No environment using UML
2. No abstract analysis habits
3. Insufficient UML knowledge

In the face of complex projects, all we need to do is abstract. There are many abstract methods, and the idea is benevolent and wise. UML provides an appropriate abstract model.

We will provide a quick understanding of UML knowledge for practical purposes from the following aspects:

1. 4 + 1 model in UML
2. Dependency in UML
3. Packages in UML

Other legends in UML

1. Activity digraphs)
2. Activity digraphs)

 

4 + 1 model in UML

In fact, I personally do not fully understand the 4 + 1 model. I mentioned it here only to provide a foreshadowing for the deep learning of UML in the future.

(The 4 + 1 model was invented by a person named kruchten, but there are other versions of the 4 + 1 model on the Internet: Use Case view, logic view, process view, impementation view and deployment view)

Logic view: abstracts the components of the system. The focus is on how the system is formed and how the components of the system interact. The commonly used class views, object digraphs, sequence digrams, and communication digrams all belong to logic views.

 

Process view: describes various activities in the system. A typical view is activity digraphs ). I personally think the activity diagram is very similar to the flowchart, and the purpose is to clearly describe the activities in the system.

 

Development View: describes the system structure from the developer's perspective. A typical view is the component view)

 

Physical view: This view focuses on the top structure of software components on hardware and communication between components. A typical view is a deployment view)

 

Use Case view: describes system use cases. A typical view is the use case view)

 

Dependency in UML

In fact, the essence of analysis is to analyze dependencies. Therefore, figuring out the representation of dependencies in UML is not far from using UML for actual modeling. (However, many UML textbooks do not seem to pay much attention to this. Most of them may not use UML for substantive modeling ).

Dependency closeness from high to low

Inheritance)

 

Composition)

Aggregation)

Association)

Dependency)

 

Through the above lines, we can connect abstract and specific things to form a common and complex system.

The inheritance, association, and dependency relationships can be stored in the dailyCode.

For example, the Code of the inheritance relationship

 
Class myclass1 {public string name {Get; Set ;}} class myclass2: myclass1 {}
 

Association/combination code

 
Class myclass2 {public string name {Get; Set ;}} class myclass1 {public myclass2 OBJ {Get; Set ;}}
 

Dependency code

 

 
Class myclass1 {...} class myclass2 {void dosomething (myclass2 OBJ) {} void dosomething2 () {myclass1 obj1 ;...}
 

 
Void myclass1 dosomething3 ()
{...}}
 

In my opinion, the relationship between combination and aggregation is more conceptual dependency.

Combination

It is emphasized that the myclass1 type is composed of the myclass2 type. The implementation of the code is similar to the Association.

 

 

 

 

 

Aggregation relationship

It is emphasized that the myclass1 type has the myclass2 type. In turn, if the myclass2 type does not exist, the existence of the myclass1 type will not be affected.

 

Packages in UML

Package is an ideal way to represent the system function structure. At the initial stage of system design, you can model the system at the package level, and then refine the system design. Maps to code, and the package corresponds to namespace.

For example, we use the following package to intuitively reflect the functional architecture of the system using the service.

Activity digraphs)

The activity diagram is usually used in combination with use case to describe the detailed steps of the Business Process in the use case.

Sequence digraphs)

A Sequence Chart can reflect the intercommunication between components in the system. In most cases, the sequence diagram and the communication diagram can be exchanged. Compared with the sequence diagram, the traffic diagram is more compact. Because the tools in the hand do not provide a template for the communication diagram, so I will only mention it here.

 

From the above figure, we can find that when we use UML to represent our system, some information will always be lost. There may be important details here. If so, I suggest you try again.

For a complex system, it is impossible to express every part of the system in UML. As an architect, its responsibility is to make trade-offs.

References

1. 4 + 1 Model

 

 

Related tools

1. Visio
2. Star UML