Why the importance of UML modeling

Why the importance of UML modeling
If you want to build a dog nest, prepare wood, nails, and some basic tools (such as hammers, saws, and tape ), you can start working. From developing a preliminary plan to completing a dog's nest that meets the appropriate functions, it may be possible to implement it within a few hours without the help of others. As long as the dog's nest is big enough and not leaking, the dog can live. If the desired effect is not met, rework is always acceptable, but it is nothing more than a grievance to the dog.

If you want to build a house for your family and prepare wood, nails, and some basic tools, you can start working, but it will take a long time, in addition, the family must have more demands for houses than dogs. In this case, unless a house has been built for many times, some detailed plans should be prepared in advance before the construction can be successful. At least a brief diagram of what the house looks like should be drawn. If you want to build a qualified house that meets the needs of the family and complies with the local building specifications, You need to draw some construction diagrams, this allows you to clearly understand the purpose of use of the room and the actual details of lighting, heating, and plumbing. After these plans are made, reasonable estimates of the time and materials required for the work can be made. Although you may have built such a house yourself, it would be much more efficient if someone else works together and transfers many key parts of the project out of the package or buys premade materials. Most families are satisfied with the new house as long as they do as planned and do not exceed the time and financial budget. If no plan is made, the new house will not be completely satisfactory. Therefore, it is best to develop a plan in the early stages and handle the changes with caution.

If you want to build a high-rise office building, it would be silly to prepare wood, nails, and some basic tools first. Because the money you use may belong to others, they will demand the scale, shape, and style of the building. At the same time, they often change their minds, even after the project has started. Because the cost of failure is too high, you must make a detailed plan. You are responsible for building design and construction as a large organization, and you are only part of it. The Organization will need various design drawings and models for communication between parties. As long as appropriate personnel and tools are obtained, and actively manage the process of converting the concept of building into an actual building, this building will be built to meet the usage requirements. If you want to continue to engage in construction work, you must balance the use requirements with the actual construction technology and handle the rest issues of the construction team members, neither putting them at risk, and cannot drive them to work so hard that they are exhausted.

The strange thing is that many software development organizations are beginning to want to build a building-style software, but they seem to be scrambling to create a dog's nest during hands-on processing.

Sometimes you are lucky. If you have enough people at the right time and everything else works well, your team may (only possible) launch a dazzling software product. However, in general, it is impossible for all personnel to be appropriate (suitable personnel are often in short supply), and time is not always appropriate (yesterday was always better ), other things are not satisfactory either (often by yourself ). The demand for software development is increasing, but the development team often relies solely on the only thing they really know how to do well-to write program code. Heroic programming has become a legend in this industry. People often think that working harder is a normal response to various crises in development. However, this may not produce the correct program code, and some projects are very huge, no matter how long the work is extended, it is not enough to complete the necessary work.

If you really want to build a software system that is equivalent to a house or building, the problem is not just writing a lot of software. In fact, the key is to develop the right software and consider how to write less software. To produce qualified software, you must have a set of specifications on the architecture, processes, and tools. Even so, many projects start to look like a dog's nest, but then they look like a building for the simple reason that they are the victims of their achievements. If you do not consider the specifications of the architecture, process, or tool, one day the dog's nest will expand into a building and collapse due to its own weight. The collapse of a dog's nest may make your dog angry. Likewise, an unsuccessful building will have a serious impact on the tenants of the building.

The causes of failed software projects vary, and all successful projects are similar in many ways. Successful software organizations have many factors for success. One of them is the adoption of modeling.

Modeling is a proven and widely accepted engineering technology. Building Models of houses and buildings can help users get the impression of actual buildings, and even create mathematical models to analyze the impact of strong winds or earthquakes on buildings.

Modeling is not only applicable to the construction industry. If we don't first construct a model (from a computer model to a physical wind tunnel model, to a prototype of the same size as a physical object), it would be hard to imagine assembling a new aircraft or car. New electrical equipment (from microprocessor to telephone exchange system) must be modeled to a certain extent to better understand the system and communicate ideas with others. In the film industry, plot concatenation board is the core of the product, which is also a form of modeling. Modeling is also required in the fields of sociology, economics, and business management to prove people ?? Or use the minimum risk and cost to test the new theory.

So what is the model? Simply put:

The model is simplified to reality.

The model provides a blueprint for the system. A model can include both a detailed plan and an overall plan of the system at a very high level. A good model includes the main elements that have a wide impact, while ignoring the secondary elements that are irrelevant to the given abstraction level. Each system can be described using different models from different aspects. Therefore, each model is a semantic Closed System Abstraction. The model can be structured, emphasizing the organization of the system. It can also be behavioral, emphasizing the dynamic aspect of the system.

Why modeling? One basic reason is:

Modeling aims to better understand the system being developed.

Through modeling, we need to achieve four goals:

(1) The model helps to visualize the system based on the actual situation or the style required.

(2) The model can regulate the structure or behavior of the system.

(3) The model provides a template to guide the construction of the system.

(4) The Model documented the decisions made. Chapter 4 describes how UML can accomplish these four tasks .]

Modeling is not just for large systems. Even software like a dog's nest can benefit from some modeling. However, it can be clearly stated that the larger the system is and the more complex it is, the greater the importance of modeling. A very simple reason is:

Because you cannot fully understand a complex system, you need to model it.

Human understanding of complex problems is limited. Through modeling, we can narrow down the scope of the research problem, focusing only on one aspect of it at a time. This is the basic method of edsger Dijkstra described a few years ago, "divide and conquer, that is to say, dividing a difficult problem into a series of small problems that can be solved, and solving these small problems solves this problem. In addition, modeling can enhance human intelligence. A properly selected model allows the modeler to work at a higher abstraction level.

The concept of modeling should not be put into practice in any case. In fact, some research points out that most software organizations do not do formal modeling, even if they do little. Based on the complexity of the project, you will find that the simpler the project, the fewer formal modeling.

The term "regular" is emphasized here. In fact, developers even do some modeling work for very simple projects, although not formal. A developer may sketch out his idea on a blackboard or on a small piece of paper to visualize some systems, or the developer may use CRC cards to describe a scenario or a mechanism. There is nothing wrong with using any of these models. If it works, you can use it. However, these informal models are often too casual to provide a common language that is easy for others to understand. The construction industry, motor engineering, and mathematical modeling all have common modeling languages. Using a common modeling language in software development can also benefit the development organization.

Each project can benefit from some modeling. Even in one-time software development-with the support of visual programming languages, you can easily discard unsuitable software. Modeling can also help developers better visualize system plans and help them properly construct them to make development faster. If you do not model a project at all, the more complex the project is, the more likely it will be to fail or construct something wrong. All practical systems have a natural trend: they become more and more complex over time. Although we may think that modeling is not required today, as the system evolves, we will regret this decision, but it was too late.