Getting started with UML

Transferred from Zhang chuanbo's blog: http://www.cnblogs.com/umlonline/archive/2011/07/12/2104626.html

This article is only for UML cainiao. You are a Chinese Bird and an old bird. Please ignore this article directly!

You only need to read this chapter to learn about UML from a macro perspective and form a UML blueprint in your head. You can have a full understanding of the basic knowledge of UML, the usage and overview of various UML diagrams, and the problems you encounter in your actual work to help you further plan the next step.

1.1 Basic UML knowledge literacy

The full name of the three letters "UML" is "Unified Modeling Language". Direct translation is a unified modeling language.

You may ask: why is it a language? Isn't a great Chinese Character starting with a graphic (pictogram? The language includes text and graphics! In fact, many texts cannot be expressed. Have you ever seen architectural design drawings? There are not many figures in it. Can I express architectural design clearly in words?

In the architecture field, there is a set of standards to describe the design. Similarly, in the software development field, we also need a set of standards to help us do a good job in software development. UML is one of the standards. Note that this is not the only standard, but UML is a standard that everyone admires. Maybe a better standard will replace her in the future!

UML is not a mandatory standard. There is no law that requires you to use UML in software development. We cannot use other standards. Our goal is to make good use of various standards, including UML, to improve our software development level.

UML has evolved from version 1.0 to Version 1.1, 1.2,... to version 2.0 and version 2.x. this book will be based on version 2.x. On the Internet, books, and various UML tools and software, their respective UML versions may be different. You may be confused during the learning process, but it doesn't matter, this course will be described in some key areas 1. X and 2. x.

What is the purpose of UML?

Many people think that the main purpose of UML is software design! Some people think that if you are not a developer, it is hard to understand UML.

However, in my first practical work, I did not apply UML to software design, but to software requirement analysis! At that time, we directly used UML, such as class diagram, sequence diagram, activity diagram, and use case diagram, to communicate face-to-face with the customer about the survey requirements. We have not been able to communicate with customers, but have communicated smoothly. Under our guidance, the customer will soon understand these UML diagrams. Because of the UML diagram, we can communicate with the customer more efficiently and effectively! You may find it amazing. In subsequent chapters, I will reveal the "secrets" behind the magic one by one ".

UML can help us to do software requirement analysis and software design work. In my work, it accounts for about 50% of each other. Of course, this is not necessarily the case in your actual work. UML will take your demand analysis or software design work to another level. This book will introduce the best practices of UML in demand analysis.

The secret is that when UML is applied to software requirement analysis, the learning threshold will be greatly reduced! Syntax complexity is reduced, and you do not need to know the knowledge of software development. As long as you are interested in software requirement analysis, study and apply UML carefully, you will have the opportunity to become a master of Software Requirement Analysis.

UML Classification

UML has many types of diagrams, which can be divided into two types:

Structure digraphs)
Class digraphs)
Object digraphs)
Component Diagram)
Deployment Diagram)
Package digraphs)

Behavior digraphs)
Activity digraphs)
State Machine digraphs)
Sequence digraphs)
Communication Diagram)
Use case diagram)
Timing Diagram)

Why are UML diagrams divided into structural and behavioral patterns?

As the name suggests, a structured graph describes a certain structure, which should be stable and "static" for a certain period of time. A behavior graph describes a certain behavior, is "dynamic.

When analyzing system requirements, we will face a lot of business concepts and there will be some relationships between them. These contents can be viewed as "static", and we can use UML structural diagrams for analysis; at the same time, the business involves a large number of processes, such as processes. The content is "dynamic". We can use the UML diagram of the behavior type for analysis.

In our software design, we need to consider the classes, components, and finally how to deploy the system. These contents can be viewed as "static" and we can use the UMLStructural DiagramTo design;

We also need to consider how the software interacts with the user, how the class, component, module, and other "dynamic" content, we can useBehavior chartTo design;

The so-called "static" and "dynamic" are not absolute. We will further introduce the structural UML and behavioral UML below. Through the following learning, you will first understand various UML diagrams, and you may have many problems. The main purpose of this chapter is to give you a macro understanding of UML, continue reading the following chapters with your questions!

1.2 Structure divisor (UML)

Class digraphs)

See the following class diagram:

Figure 1.1 system class diagram of a mold

This figure is taken from the business concept analysis graph of a mold management system. One rectangle in the figure is a class. These classes are connected by various lines, and these lines represent the relationship between classes.

Class diagrams are the first choice for analyzing business concepts and the most frequently used UML diagrams.

Let's look at the person class diagram below, which is a diagram used in software design:

Figure 1.2 person class diagram

This person class has the following attributes: name, sex, department, and the following operations: work.

Classes have attributes and operations. However, when you use a class chart to analyze a business model, you do not need to use operations. The class in section 1.1 only has attributes.

That is, attribute is an attribute, and operation is an operation.

Object digraphs)

Generally, the object graph is used only in software development. The following content describes the object graph from the development perspective. If you have no development experience, it may be a little difficult to read.

In Figure 1.2, the person class is instantiated using the Code as follows:

Person = new person ();
......

Class is an object after it is instantiated. The object person is an instance of the class person. The above code can be expressed as follows using an object diagram:

Figure 1.3 object graph of the person class

An object chart is similar to a class chart. An object is a class instantiation. "Person: Person" indicates that the object person is an instance of a class person.

An object graph is usually used only when you need to describe complex algorithms. The drawn object graph usually does not have only one object. This graph only draws one object, the purpose is to simplify the object graph as much as possible so that readers can understand what an object graph is.

In the requirement analysis work, there is basically no need to use an object graph. From a rigorous perspective, we should use an object graph in some situations. However, I often use a class graph for processing, this is easier to understand.

Component Diagram)

A component diagram is also called a component diagram. Both names comply with the UML terminology.

A component diagram is a diagram used to describe the physical composition of the software. An automobile consists of physical components such as wheels and engines. A software is often composed of many "physical components" (such as controls and reusable components.

Is a permission Component Design Drawing:

Figure 1.4 Design of a permission component

Fig 1.4A rectangle with such a sign in the upper right cornerIndicates a component, which can contain components.

In software requirement analysis, there are not many situations where component diagrams are required, except in the following cases:

1. the system to be developed needs to interact with third-party systems, original systems, and some old systems. In this case, the interaction requirements can be described in the component diagram.

2. The customer has some special requirements for software design. In this case, the requirements can be described using a component diagram.

The component diagram is sometimes not used independently and used together with the deployment diagram.

Deployment Diagram)

A deployment diagram describes how the system is deployed and how the system is related to other systems, for example:

Figure 1.5 Management System deployment of a 24-hour convenience store

One by oneThree-Dimensional RectangleIs the "Node" in the deployment diagram. One node represents a physical device, and the lines between nodes represent the physical connection between nodes.

Most customers have basic IT environments (such as local area networks, some servers, and some software platforms). The software system needs to be planned based on the current basic IT environment, in this case, we can use the deployment Diagram for this planning.

The requirements of the analysis system cannot ignore the requirements of the system architecture, deployment, and IT architecture. We need to make a plan that best suits the customer's interests based on the current IT infrastructure.

To analyze requirements using component diagrams and deployment diagrams, you must have a certain degree of IT infrastructure knowledge and software design knowledge. If you do not have the relevant knowledge, you can consider supplementing the relevant knowledge.

However, it is not easy to analyze the business and refine functional requirements. Technical professionals are responsible for the analysis of non-functional requirements.

Package digraphs)

Package indicates "packaging". The main purpose of the package diagram is:"Package" class diagram.

When a class chart is used to describe a business concept, many business classes are too large, which makes it difficult to read. In this case, some classes can be put into a "package, organize the business concept diagram through the package diagram.

Is an example of a package diagram:

Figure 1.6 package diagram

In the figure, the folder is like a "package", and the lines between packages represent the relationship between packages.

1.3 behavior-oriented UML (behavior digoal)

The activity diagram, state machine diagram, and sequence diagram describe the process from three different perspectives. They are three different tools for analyzing the business process. The following describes them one by one.

Activity digraphs)

We will get up to work and draw an activity chart, which may be like this:

Figure 1.7 activity chart from getting up to going out to work

An edge box in the activity diagram represents an "activity", and an arrow line between multiple activities indicates the activity sequence. This diagram only expresses a sequence flow, the activity chart can also express the branch structure.

If you have learned a flowchart before, you will find that the activity diagram is similar to the flowchart.

The activity diagram may be one of the three UML diagrams that can represent the process closest to our habits of thinking. Next we will learn the other two diagrams that can express the process.

State Machine digraphs)

A state machine diagram is also called a state chart, but the name of the state chart does not translate the meaning of the machine.

The state machine diagram shows the process from the perspective of how the status of an item changes. the approval process for a ticket is as follows:

Figure 1.8 leave handling process

The entire approval process for asking for leave is centered on the "ticket" object. with different approval stages, the ticket has different statuses.

When analyzing business processes, we will find that many processes are actually centered around an item. In this case, we can consider using a state machine diagram.

Sequence digraphs)

You go to the restaurant for dinner and order the waiter to deliver the food. The process is shown in the sequence diagram as follows:

Figure 1.9 ordering order

The figure contains three "Villains". The text descriptions (for example, customer) under each "villain" indicate the roles they represent. There are some line links between the role and the role, indicating how the role interacts.

This figure indicates that after a customer delivers a food to the waiter, the waiter delivers the food information to the cook, then the cook cooks and finally delivers the food to you.

The ordering process involves several steps, each of which is under the responsibility of different roles. If you encounter a similar situation, you can consider using a sequence chart for analysis.

The advantage of analyzing with the sequence diagram is that it can clearly express the roles involved in the entire process, the relationship between roles and roles, and how each role is involved in this process.

Communication Diagram)

In uml1.1, the English name of the image is collaboration digoal; In uml2.x, the English name is communication digoal. Translate the English name directly. The original English name can be translated into a collaboration diagram, and the new English name can be translated into a communication diagram.

A communication diagram is another method of sequential diagram.

The ordering order diagram. If you use a communication diagram to draw it, it can be expressed as follows:

Figure 1.10 ordering communication Diagram

The three "little people" sub-tables represent three roles: customers, waiters, And chefs. There is a straight line between roles to indicate a relationship between them. Text and arrows with serial numbers indicate information transmitted between roles.

The Order diagram emphasizes the order, and the communication diagram emphasizes the relationship between each other. I think the sequence diagram is more practical and easier to understand than the communication diagram. In the demand analysis work, I basically do not use the communication diagram.

Use case diagram)

Is an example image:

Figure 1.11 use case diagram

The use case diagram shows what roles can do through the software system. We can use the use case diagram to systematically express the vast majority of requirements of the software system.

Timing Diagram)

A time sequence chart is also called a time chart. A time sequence chart is a standard term in UML, and a time chart is not a standard term.

A sequence chart is a chart that shows the status of a thing changing over time. For more information, see:

Figure 1.12 changing the switch status of a lamp over time

The following figure shows that the light is turned off from 0 s to 30 s. The light is turned on in 30-60 s, and the light is turned off in 60 s.

In practice, I have not tried the time chart.

The following table summarizes the application of various UML diagrams in the requirement analysis work:

Table 1.1 actual application of various UML diagrams

The above table is based on my work experience and I believe it will apply to many situations. However, the work experience, situation, and environment of each person are not the same. The above table is for reference only.

1.4 How to Learn UML well?

Misunderstanding of UML

Misunderstanding 1: I think UML is mainly used for software design.

As you can see in the previous article, UML is not only used for software design, but also for demand analysis. This book specifically describes how to use UML in demand analysis.

Misunderstanding 2: the customer cannot understand UML. It is of little practical significance to apply UML in requirement analysis.

I still have such doubts when I am not familiar with UML, and I find that UML is a good bridge to communicate with the customer!

In fact, UML is not hard to understand. The customer can understand it immediately after a slight explanation. In all my project requirement analysis work, I use the UML diagram to communicate with the customer directly, and the requirement specification signed by the customer contains a large number of UML diagrams.

UML can intuitively, visually, and rigorously describe business concepts, business processes, and customer expectations and needs. As long as you guide the customer a little, the customer will easily understand the UML, even take the initiative to use UML to communicate with the project team. I have met a customer who asks us for a UML drawing tool. After seeing the power of UML, I want to use it in my own work.

Misunderstanding 3: The UML syntax is complicated and difficult to learn and apply.

Some UML documents and books may make UML too complex. The official UML standard documents are indeed boring and confusing. When I first started learning UML, I also read some UML books and thought that UML has too many syntaxes, is too complicated, and is too confusing!

In actual work, there are not many UML syntaxes that are frequently used, and they are easy to grasp. When we use UML in demand analysis, we need to have less syntax (a little more syntax to use UML in software design ).

The "20% principle" is fully applicable here. The UML syntax we often use only accounts for of the total syntax, and this book will focus on the practical UML syntax.

Misunderstanding 4: UML is not used much.

Many people advocate UML, but many people do not agree with UML. The reason for disapproval is that some people have learned UML and found that the role they play in their actual work is not very great. Sometimes they do not need UML for better results.

I dare not say that UML can help us solve all the problems. At least from my years of experience, UML is still very helpful for improving my demand analysis capabilities.

Some people feel that UML is not easy to use. I think the reason is that they only grasp the shape of UML and do not understand the god of UML. The common syntax of UML can be learned in a few days, but it is not so easy to implement "thinking in UML" and requires long-term training.

My Learning Experience

I never heard of UML when I was in college. I started to contact UML two or three years after I came out to work. At that time, I felt like I had found the New World and wanted to explore it! I was lucky at the time. My boss was a UML guru who led me to the project requirement analysis. I quickly learned the power of UML and quickly mastered UML with his words and deeds.

After that project, I independently worked on multiple project management and demand analysis tasks. None of the projects did not use UML, and I taught UML knowledge to other members of the project team without reservation. After years of work, I have further honed myself and gained a deeper understanding of the application of UML in practical work, forming my own method.

Most of my UML knowledge comes from work practices. Although I have read some books during this period, I have little help. Of course, my biggest benefit is my UML enlightenment teacher. He taught me UML in his practical work and helped me embark on the path of self-growth.

My biggest experience in UML learning is that practice is too important! If you have an instructor, you will get twice the result with half the effort! I hope this book will become a good helper for you to learn and apply UML in your actual work!

Difficulties in UML Learning

The difficulty of learning UML lies not in Learning grammar, but in changing thinking habits. UML is a new tool, but it also represents a new and advanced way of thinking. If you cannot master this method, you can only learn the form of UML, but did not grasp its mind.

To make good use of UML, You need to cultivate the following capabilities at ordinary times:

1. Ability to express in writing.

2. Inductive summary.

3. "Object-Oriented" thinking and abstraction capabilities.

You can take advantage of various opportunities to increase your skills by 1st or 2nd, such as writing more project documents, writing diaries or blogs, and thinking more about and summarizing your work gains and losses.

The 3rd capabilities are a bit false, and you may have learned relevant knowledge in college. The best way to train this kind of ability is to use multi-application class diagrams, and use instances to understand what is called "object-oriented "!