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

This article mainly introduces what are the misunderstandings of UML modeling, the article is very detailed, has a certain reference value, interested friends must read it!

Misunderstanding of 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.

UML modeling myth 1: UML modeling is tantamount 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 *.

UML modeling 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).

UML modeling myth 3: UML modeling means that a heavyweight software development process is needed.

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 of UML modeling: requirements 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.

UML modeling myth # 5: design is immutable

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.

UML modeling myth # 6: must use CASE tools

UML modeling is often considered to be a complex task, so it needs to be assisted by a lot of CASE tools.

Fact analysis: yes, UML modeling can be very complex. But you can build an effective and simple model to express the key information, rather than include some unimportant details.

For example, I often use UML to model classes, their properties, and some key business operations, but do not draw access operations for attributes (get and set), framework code to maintain relationships with other classes, or other trivial implementation details. I found a solution to the problem through UML modeling so that my colleagues and I could move on to implement the model. In such a flexible way, in most cases I don't need a CASE tool to support UML modeling, a whiteboard, or a digital camera is enough. In this way, I don't have to take the time to evaluate CASE tools, discuss licenses with tool vendors, and save staff training expenses. CASE tools are worth buying only if they are cost-effective (relative to your own situation). In most cases, I can achieve my goal without it (complete UML modeling). One of the things I often use is Together/J (http://www.togethersoft.com/)-because it produces a significant amount of Java framework code; and ERWin (http://www.cai.com/)-because it can plan databases. These two tools really help me achieve the purpose of software development-to make software that meets the requirements of users. But most of my UML modeling work still uses simple tools rather than CASE tools.

UML modeling myth 7: UML modeling is a waste of time

Many beginners think so, mainly because their education is limited to how to write code and has little contact with the complete development process. And their experience is limited to how to implement code, just like junior programmers. They give up opportunities to improve efficiency and learn skills that make it easy for them to adapt to different projects or organizations. They should be ashamed of it.

Fact analysis: in most cases, drawing a sketch, developing a rough prototype, or making some index cards before you start coding can improve your productivity. Efficient developers have to do UML modeling before coding. In addition, UML modeling is a good way to communicate between project team members and project leaders. You explore the problem in the process so that you can get a better understanding of what you want, and each member of the project can also get a sub-understanding of the project.

UML modeling myth 8: data model (DataModel) is everything

Many organizations stumble to start new development work based on data models, perhaps as in your organization: the IT department has very strict rules on data and controls your development projects, or your previous database is a mess and has no choice.

Fact analysis: the data model is an important but not the most important UML modeling, it is based on another model. (see "ExtremeModeling", ThinkingObjectively,Nov.2000). This is true even in data-oriented projects such as data warehouses. Without a good understanding of how users use the data warehouse (not represented in the data model), these projects often end up with sad failures. There are many models you can use-use cases (usecases), business rules (businessrules), activitydiagrams, class diagrams (classdiagrams), componentdiagrams, user interface flowcharts (userinterfaceflowdiagrams) and CRC, etc. The data model is just one of them. Each model has its strengths and weaknesses and should be used correctly.

UML modeling myth #: all developers know how to UML modeling

We are now faced with a serious problem: many people who are not developers, including senior managers and users, do not know how the software is built. As a result, they cannot distinguish between skilled developers and ordinary programmers (and, of course, senior programmers), and they take it for granted that all developers have the skills to develop the entire system from beginning to end.

Factual analysis: this is definitely incorrect. The skill of UML modeling can only be mastered by a developer through learning it and long-term practice. Some very smart programmers often believe that they can do anything. After all, they are just programmers. Because of such arrogance, they undertake some tasks that they simply do not have the skills to accomplish. Software development is so complex that it is difficult for a single person to have all the skills to develop successfully or even to configure a system with a certain degree of complexity. Developers should be self-aware, understand their own weaknesses, and learn endlessly. By learning from each other, UML modelers can learn the details of a technology from programmers, and programmers can learn valuable design and architecture techniques from UML modelers. Personally, I think all people, including myself, are beginners.

AgileModeling

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).

These are all the contents of this article entitled "what are the misunderstandings in UML Modeling?" Thank you for reading! Hope to share the content to help you, more related 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.