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

This article mainly shows you the "UML modeling process need to pay attention to what problems", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "what problems need to pay attention to in the process of UML modeling" this article.

Misunderstandings in UML Modeling

By understanding and avoiding the misunderstandings of UML modeling, you can develop software more effectively by yourself, your project team, and your organization. In the process of revealing these common misunderstandings, I have expressed many principles of AgileModeling (AM). AgileModeling used to be called ExtremeModeling (XM). I hope what I give you is spiritual food.

Whether you follow a heavyweight approach, such as EnterpriseUnifiedProcess (EUP), or a lightweight development process, such as ExtremeProgramming (XP), UML modeling is indispensable in software development. But unfortunately, it is full of fallacies and myths. This comes from various aspects, from the erroneous research of theorists, the cultural deposition in the field of information technology for decades, the hype of software tool developers, and the standards of organizations such as ObjectManagementGroup (OMG) and IEEE. This month, I'm going to reveal the misunderstandings in UML modeling and point out the corresponding facts.

Myth 1: UML modeling is equivalent to writing documents

This is probably one of the destructive forces, because developers can use this as an excuse to give up UML modeling altogether. Many good software developers will say that they don't want to waste their time on these "useless" documents. They indulge in coding and create fragile and shoddy systems. In addition, even many conscientious developers now find UML modeling a nuisance and are reluctant to learn the corresponding UML modeling techniques.

Fact analysis: "model" and "document" are conceptually irrelevant-you can have a model that is not a document and a document that is not a model. A design drawing is a model, whether drawn on the back of a napkin, written on a whiteboard, in a ClassResponsibilityCollaboration (CRC) card, or a rough prototype of the user interface based on a flow chart recorded on newspapers and post-it notes. Although these are not documents, they are all valuable models.

UML modeling is much like planning: the value of planning lies in the planning process, not in the plan itself; the value is reflected in the activities of UML modeling, not in the model itself. In fact, models are not part of the formal documentation in your system and can be discarded after completing their mission. You will find that there are only a few models worth keeping, and it must be very *.

Myth 2: you can consider everything from the beginning

This saying was popular in the 1970s and early 1980s, when many managers today learned to develop software. Superstition on this point can lead to a considerable amount of time in the upfront to model everything in UML in order to get everything right, trying to "freeze" all requirements before coding begins (see myth 4), so that you suffer from "analytical paralysis"-you don't dare to move forward until the model is very bad. Based on this point of view, the project team developed a lot of documentation, rather than what they really wanted-to develop software that met their needs.

Factual analysis: how can we get out of this misunderstanding? First of all, you must realize that you can't consider all the details. Second, recognizing that coders may disapprove of the work of UML modelers (which is possible, in fact, the work done by UML modelers accounts for only a small part of the real value), they may say that the model does not reflect the real situation. Third, realize that no matter how good your initial specification is, the code is destined to get out of sync with it quickly, even if you model your own UML and code yourself. A basic truth is that the code will always be consistent with the code. Fourth, realize that iterative methods (small-scale UML modeling, writing some code, doing some tests, and possibly doing a small working version) are the guidelines for software development. It is the basic principle of modern heavyweight software development process (such as EUP) and lightweight (such as XP).

Myth 3: UML modeling means that a heavyweight software development process is required

Project teams that enter this misunderstanding (often associated with misunderstanding one) often give up even UML modeling completely because such a software development process is too complex and heavy for them. This is no less than a natural disaster.

Fact analysis: you can replace it in an agile way. For more information on simple UML modeling with simple tools, see AgileModeling (AM). Also, you can discard your model and do UML modeling in a basic way when the mission is over (for example, from the desk to the whiteboard). You can easily UML modeling if you want.

Myth 4: demand must be "frozen"

This request often comes from senior managers who want to know exactly what they can get from the project team. The advantage is that by identifying requirements early in the development cycle, you can know exactly what you want; the downside is that they may not get what they actually need (incomplete or wrong requirements, translator).

Factual analysis: change will happen. Due to the change of priority and the gradual development of a better understanding of the system, there will be changes in requirements. As opposed to freezing requirements, estimate the risk of project success, try to accept changes and act accordingly, as recommended by XP.

Myth 5: design is unchangeable

Like myth 4, every developer must strictly follow the "design", causing the developer to do the wrong thing or do the right thing in the wrong way in order to conform to the "design". Or simply ignore the design, negating all the possible benefits of the design. By freezing the design, you cannot further benefit from what you have learned in the course of the project. Another big trend is to develop a large number of documents rather than actual software, using document-oriented CASE tools rather than application-oriented tools that bring practical value to the project.

Fact analysis: in fact, designs are often modified based on feedback from developers and database administrators because they are the people closest to the actual application and usually have a better understanding of the technical environment than UML modelers. We have to face the fact that no one is perfect, and the work they do cannot be perfect. Do you really want to fix an imperfect design without correcting its errors? In addition, if the requirements are not frozen, it means that you can't freeze your design, because any changes to the requirements are bound to affect the design. The right attitude is: as long as your code is still changing, it's not over.

These are all the contents of the article "what should be paid attention to in the process 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.