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

Xiaobian to share with you what the principles of UML modeling, I believe most people do not know how, so share this article for your reference, I hope you read this article after a lot of gains, let us go to understand it!

Various engineering disciplines have a rich history of modeling applications. These lessons have led to four basic principles of modelling, which are described below:

First, the choice of what model to create has a profound impact on how problems are tackled and how solutions are formed.

In other words, choose your model well. The right model will clearly show the toughest development problems and provide insights that cannot easily be obtained elsewhere; the wrong model will lead people astray and spend energy on unrelated problems. Putting software problems aside for a moment, suppose we are trying to solve a problem in quantum physics. Such as the interaction of photons in spacetime, which is full of amazingly difficult mathematical problems. Choose a different model, and all of a sudden the complex problem becomes feasible (though not easy to solve). In this field, this is precisely the value of Feynmann diagrams, which provide graphical representations of very complex problems. Similarly, in a completely different domain, suppose a new building is being built and you are concerned about the effects of high winds on it. If you build a physical model and test it in a wind tunnel, you can find something interesting about it, even though the small model doesn't accurately reflect the larger object. So if you're building a mathematical model and then simulating it, you'll know something different; it's also possible to get more new scenarios than if you used a physical model. By rigorously and continuously experimenting with the model, you will have more confidence in the system that has been modeled, and in fact it will work as well as expected in the real world.

For software, the model chosen will greatly influence the perception of the domain. If you build a system from the database developer's perspective, you might notice an entity-relationship model that puts behavior into triggers and stored procedures. If you build a system from the point of view of a structured developer, you may end up with an algorithm-centric model that contains the flow of data from process to process. If you build a system from an object-oriented developer's point of view, you might end up with a system whose architecture centers around a set of classes and interaction patterns that indicate how classes work together. Executable models are a great help for testing. While any of these approaches may be correct for a given application system and development culture, experience has shown that object-oriented approaches outperform in building resilient architectures, even for systems that use large databases or compute cells. Despite this fact, it is important to emphasize that different approaches will lead to different kinds of systems, with different costs and benefits.

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

If a building is being built, sometimes it is necessary for investors to see the building from a macro perspective and feel the overall effect of the building. Sometimes it is necessary to carefully consider details, such as the installation of complex and difficult pipes or the installation of rare structural elements.

The same is true for software models. Sometimes a quick, concise and executable user interface model is just what is needed, and sometimes you have to be patient with bits, for example, describing cross-system interfaces or solving network bottlenecks. In any case, ***'s model should be such that it allows you to choose the level of detail based on who is observing and why. Analysts or end-users focus on the "what," developers focus on the "how." Each of these people visualizes the system at different times and in different levels of detail.

* **

A physical model of a building is of limited value if it does not respond in the same way as a real building; a mathematical model of an aircraft, assuming only ideal conditions and *** manufacturing, may mask some potentially fatal real-life features of a real aircraft. *** There are models that clearly relate to reality, and when the connection is weak, there is an ability to know exactly how these models are disconnected from reality. All models simplify reality; but the key is not to obscure any important details.

The Achilles heel of structured analysis in the software domain is that there is no fundamental connection between the analysis model and the system design model. Over time, this unfillable fracture can cause inconsistencies between the conceptual and implementation phases of the system. In object-oriented systems, almost independent system views can be linked into a complete semantic whole.

Fourth, a single model or view is insufficient. Each important system *** is approximated from multiple perspectives by a small group of almost independent models.

If a building is under construction, you will find that no single set of drawings can describe all the details of the building. Floor plans, elevations, electrical plans, heating plans, and piping plans are required as a minimum. And, in any kind of model, it is necessary 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 models can be studied and constructed separately, but they are still interrelated. As with building, you can study the electrical design drawing separately, but you can also see how it maps to the floor plan and how it interacts with the pipe layout in the piping design.

The same is true for object-oriented software systems. To understand the architecture of a system, several complementary and interlocking views are required: a use case view (which reveals the requirements of the system), a design view (which captures the vocabulary in the problem space and solution space), an interactive view (which shows the connections between parts of the system and between the system and its environment), an implementation view (which describes the physical implementation of the system), and a deployment view (which focuses on the engineering problems of the system). Each view may have structural and behavioral aspects. Together, these views represent 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 expressing static design views will dominate; for graphical user interface-intensive systems, static and dynamic use case views will be important; in hard real-time systems, dynamic process views will be especially important;***, in distributed systems, such as web-intensive applications, implementation models and deployment models will be most important.

The above is "UML modeling principles what" all the content of this article, thank you for reading! I believe that everyone has a certain understanding, hope to share the content to help everyone, if you still want to learn more knowledge, welcome to pay attention to 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.