Shulou(Shulou.com)06/02 Report--

This article mainly shows you "how to choose a good model from the principle of UML modeling", the content is simple and clear, hoping to help you solve your doubts, the following let the editor lead you to study and learn "how to choose a good model from the principle of UML modeling" this article.

All kinds of engineering disciplines have a rich history of modeling. These experiences form the four basic principles of modeling, which are described as follows:

First, choosing what model to create has a profound impact on how to solve the problem and how to form a solution.

In other words, choose the model well. The right model will clearly show the thorniest development problems and provide insights that cannot be easily obtained elsewhere; the wrong model will lead people astray and focus on unrelated issues. Putting the software problem aside for the time being, suppose we are trying to solve a problem in quantum physics. Such as the interaction of photons in space-time, which is full of surprisingly difficult mathematical problems. Choose a different model and all the complex problems become feasible at once (though not easy to solve). In this area, this is precisely the value of Feynmann diagrams, which provide a graphical representation of very complex problems. Similarly, in a completely different field, if a new building is being built, it will be concerned about the impact of high winds on it. If a physical model is established and tested in a wind tunnel, although the small model does not accurately reflect the large physical object, some interesting things can be found from it. Therefore, if you are building a mathematical model and then simulating it, you will know something different; you may also get more new scenarios than using the physical model. Through rigorous and continuous experiments with the model, the system that has been modeled will be more trusted, and in fact, it will work as well as expected in the real world.

As far as software is concerned, the model chosen will greatly affect the perception of the domain. If you build a system from the point of view of a database developer, you may pay attention to the entity-relation model, which puts behavior into triggers and stored procedures. If you build a system from a structured developer's point of view, you may get an algorithm-centric model that contains data flow from processing to processing. If you build a system from an object-oriented developer's point of view, it is possible to get a system whose architecture centers on a set of classes and interaction patterns that indicate how classes work together. Executable models are of great help to testing. Any of the above methods may be correct for a given application system and development culture, and experience has shown that object-oriented approaches excel in building resilient architectures. this is true even for systems that use large databases or computing units. Despite the facts, it is important to emphasize that different approaches will lead to different types of systems, and the costs and benefits will be different.

Second, each model can be represented at different levels of precision.

If a building is being built, it is sometimes necessary for investors to see what the building looks like and feel the overall effect of the building. And sometimes the details need to be carefully considered, such as the laying of complex and intractable pipes, or the installation of rare structural components.

The same is true for software models. Sometimes a fast, concise and executable user interface model is just what is needed, and sometimes you have to be patient with bits, such as describing cross-system interfaces or solving network bottlenecks. In any case, the model should look like this: it allows you to choose its level of detail based on who is observing and why. Analysts or end users mainly consider the question of "what to do", while developers mainly consider the question of "how to do it". These people have to visualize the system at different times and at different levels of detail.

Third, the model of * * is related to reality.

If the physical model of a building cannot respond in the same way as a real building, its value is limited; the mathematical model of an aircraft, if it only assumes ideal conditions and manufacturing, it may mask some of the potential and deadly realistic features of the real aircraft. * there are models that can clearly connect with reality, and when the connection is weak, you can know exactly how these models are out of touch with reality. All models simplify reality; but one thing to remember is that simplification does not obscure any important details.

The fatal weakness of structured analysis in the software field is that there is no basic relationship between the analysis model and the system design model. Over time, this unfillable crack will cause inconsistencies between the conception phase and the implementation phase of the system. In an object-oriented system, almost independent system views can be linked into a complete semantic whole.

Fourth, a single model or view is insufficient. Each important system is approached from multiple perspectives with a small set of almost independent models.

If you are building a building, you will find that no single set of blueprints can describe all the details of the building. At least floor plans, elevations, electrical drawings, heating drawings and plumbing drawings are required. And, in any kind of model, you need to grasp the scope of the system from multiple perspectives (such as blueprints for different floors).

The key phrase here is "almost independent". In this context, it means that various models can be studied and constructed separately, but they are still interrelated. As with the construction of a building, you can study the electrical design individually, but you can also see how it maps to the floor plan and how it interacts with the pipe layout in the pipe plan.

The same is true of object-oriented software systems. In order to understand the architecture of the system, several complementary and interlocking views are needed: usage view (revealing the requirements of the system), design view (capturing words in the problem space and settlement space), interactive view showing the relationship between the various parts of the system and between the system and the environment), implementation view (describing the physical implementation of the system) and deployment view (focusing on the engineering problems of the system). Each view may have structural and behavioral aspects. Together, these views depict the software blueprint as a whole.

Depending on the nature of the system, some models may be more important than others. For example, for data-intensive systems, models that express static design views will dominate; for graphical user interface-intensive systems, static and dynamic use case views are important; in hard real-time systems, dynamic process views are particularly important; and in distributed systems, such as Web-intensive applications, implementation models and deployment models are the most important.

The above is all the contents of the article "how to choose a good model from the principle of UML modeling". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.