Fireball UML war demand analysis (Chapter 1 UML) 1st structured UM

Note: "fireball-UML war demand analysis" is a book I have written on demand analysis and UML. I will share with you the content of the previous chapters on CSDN, the total number of words is tens of thousands, and dozens of images are displayed. You are welcome to read the document in sequence. Thank you! This book has been sold in major online bookstores and bookstores. Thank you for your attention. ---------

Note: "fireball-UML war demand analysis" is a book I have written on demand analysis and UML. I will share with you the content of the previous chapters on CSDN, the total number of words is tens of thousands, and dozens of images are displayed. You are welcome to read the document in sequence. Thank you! This book has been sold in major online bookstores and bookstores. Thank you for your attention. ---------

Note:

Fireball-UML war demand analysis is a book I have written on demand analysis and UML. I will share the previous chapters on CSDN, the total number of words is tens of thousands, and dozens of images are displayed. You are welcome to read the document in sequence. Thank you! This book has been sold in major online bookstores and bookstores. Thank you for your attention.

Bytes ------------------------------------------------------------------------------------------------------------------------------

Chapter 1 UML

Summary: 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.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. class diagrams may be UML diagrams with the highest usage.

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.
Attribute has features, features, and other translations. Operation is also called a method. However, this book follows the UML Chinese Terminology standard, 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.

The Person class in. 2 is instantiated using Code as follows:
Person 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. We will explain the object graph again in the class chapter.

Component Diagram)A component diagram is also called a component diagram. Both names comply with the UML terminology.
A car is composed of physical components such as wheels and engines. A software is often composed of many "physical components" (such as controls and reusable components, A component diagram is a diagram used to describe the physical composition of the software. Is a permission Component Design Drawing:

Figure 1.4 Design of a permission component

. 4. A rectangle with such a sign in the upper right corner represents a component. The component can then contain the component.
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

In the figure, three-dimensional rectangles are the "nodes" 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 a Package diagram is to "Package" A 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.

Please refer to the next section ......

Author: Zhang chuanbo

Innovation workshop entrepreneurship classroom lecturer

Senior consultant from a Huawei team

Fireball-UML war demand analysis author

Founder of www.umlonline.org