Misunderstanding of modeling-getting out of general design mistakes and moving towards success

Whether you follow heavyweight methods, such as Enterprise Unified Process (EUP) or lightweight development processes, such as Extreme Programming (XP), modeling is indispensable in software development. Unfortunately, there are various errors and misunderstandings.
This comes from a variety of aspects, from the study of theoretical errors, cultural deposits in the field of information technology for decades, the hype of Software Tool developers, and Object Management Group (OMG) and IEEE standards. This month, I will reveal the misunderstandings in modeling and point out the facts.

Misunderstanding 1: modeling is equivalent to writing documents.

This is probably the most destructive one, because developers can give up modeling on the pretext. Many good software developers say they don't want to waste their time on these "useless" documents. They indulge in coding and create fragile and inferior systems.
In addition, even many responsible developers now think that modeling is annoying, rather than learning the corresponding modeling technology.

Fact analysis: the "model" and "document" are conceptually different-you can have a document that is not a document or a model. A design drawing is a model, either painted on the back of a napkin, written on a whiteboard, or on a Class Responsibility Collaboration (CRC) card, or a rough User Interface prototype generated based on the flowchart recorded on the newspaper and paper. Although none of these can be said to be documents, they are all valuable models.

Modeling is like planning: the value of planning lies in the planning process, rather than the planning itself. The value is embodied in modeling activities rather than the model itself. In fact, models are not a part of formal documents in your system and can be discarded after their mission is fulfilled. You will find that there are only a few models worth retaining, and they must be perfect.
Misunderstanding 2: You can consider everything from the beginning.

This is a popular term between the 1970s s and the 1980s S. Many managers are studying software development at that time. The superstition of this will lead to investing considerable time in the early stage to model everything in order to make everything right, try to "freeze" all the requirements before coding starts (see misunderstanding 4), so that you will suffer from "Analytical paralysis"-Wait until the model is perfect before you dare to move forward. Based on this point of view, the project team has developed a large number of documents, rather than what they really want-to develop software that meets their needs.

Fact analysis: How can we get out of this misunderstanding? First, you must realize that you cannot consider all the details. Second, realize that the coders may disagree with the modeler's work (this is possible, in fact, The Modeler's work is only a small part of the actual value ), they may say that the model does not reflect the actual situation. Third, realize that no matter how good your original specification is, the code will soon be out of sync, even if you build your own code. The basic principle is that the Code will always be consistent with the code. Fourth, it is recognized that iterative methods (small-scale modeling, code compilation, testing, and a small working version) are the principles of software development. It is a modern heavyweight software development process (such as EUP), as well as the basic principles of lightweight (such as XP.

Misunderstanding 3: Modeling requires a heavyweight software development process

A project team that has gone into this misunderstanding (often associated with the misunderstanding) often gave up the software development process completely. It should be too complicated and too heavy for them. This is no less than a natural disaster.

Fact analysis: you can replace it with a simple method. For more information about Simple Modeling with simple tools, see Agile Modeling (AM ). In addition, you can discard your model. After the mission is complete, you can also perform Modeling in a basic way (for example, starting from a public table, create a sketch before the Whiteboard is reached ). You can easily build a model as long as you want.

Misunderstanding 4: the demand must be "Frozen"

This requirement often comes from senior managers who want to know exactly what they can get from this project group. The advantage is that you can know exactly what you want when you determine the requirements at the early stage of the development cycle; the disadvantage is that they may not get what they actually need (incomplete or wrong requirements, the translator ).

Fact analysis: Changes always happen. The changes in priority and the gradual understanding of the system will lead to changes in requirements. In contrast to Freezing demand, the risk of project success is estimated, and changes should be accepted as much as possible and actions should be taken accordingly, just as XP suggested.

Misunderstanding 5: design cannot be changed

Like misunderstanding 4, every developer must strictly follow the "design", which leads the developer to do wrong things or do the right things in the wrong way to conform to the "design. Or simply ignoring the design, denying all possible benefits of the design. Once the design is frozen, you will not be able to further benefit from the knowledge you have learned in the project process. Another major trend is to develop a large number of documents rather than real-world software, and use case-oriented document tools instead of application-oriented tools that bring practical value to the project.

Fact analysis: in fact, the design is often modified based on feedback from developers and database administrators, because they are the people closest to the actual application, generally, their understanding of the technical environment is better than that of the modeler. We must face the fact that no one is perfect and their work cannot be perfect. Do you really want to fix an imperfect design and stop modifying the errors? In addition, if the demand is not frozen, it means that you cannot freeze your design, because any modifications to the demand will inevitably affect the design. Right, the correct attitude is: as long as your code is still being modified, it will not be complete.

Misunderstanding 6: CASE tools must be used

Modeling is often considered a complex task and therefore requires a large number of CASE tools.

Fact analysis: Yes, modeling can be complex. However, you can create an effective and simple model to express the key information, rather than include irrelevant details.

For example, I often use UML to create models to represent classes, their attributes, and some key business operations, but do not draw the access operations (get and set) for attributes ), and framework code that maintains relationships with other classes, or other trivial implementation details. I used modeling to find a solution to the problem so that my colleagues and I could continue to implement this model. In this flexible way, in most cases I Don't Need A CASE tool to support modeling, a whiteboard, or a digital camera. In this way, I don't need to spend time evaluating the case tool. I don't need to discuss the license with the tool supplier, and I also need to avoid training expenses. The case tool is worth buying only when it shows the best price/performance ratio (in your own case. In most cases, I don't need it for the purpose (to complete modeling ). The tools I often use are together/J (http://www.togethersoft.com/)-because it can generate a considerable number 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 create software that meets user requirements. However, most of my modeling work still uses simple tools instead of CASE tools.

Misunderstanding 7: modeling is a waste of time

Many new users believe that this is mainly because their education is limited to writing code and there is little access to the complete development process. In addition, their experience is limited to how to implement code, just like Junior programmers. They give up on 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 this.

Fact analysis: In most cases, drawing a sketch before coding, developing a crude prototype, or creating some index cards can improve your production efficiency. Efficient developers must perform modeling before coding. In addition, modeling is a good way to communicate between project team members and project owners. In this process, you will discuss the problem and get a better understanding of what you want, each member involved in the project can also get an understanding of the project.

Misunderstanding 8: Data Model is everything

Many organizations initiate new development jobs based on data models. Maybe, just as your organization: the IT department has very strict rules on data and controls your development projects; or your previous database is a mess and you have no choice.

Fact analysis: the data model is an important but not the most important modeling. It is best to build on another model. (See "Extreme Modeling", Thinking Objectively, Nov.2000 ). This is even true for data-oriented projects such as data warehouses. Without a good understanding of how users use the data warehouse (not expressed in the Data Model), these projects often end with a miserable failure. You can use many models-use cases, business rules, activity diagrams, class diagrams, and component diagrams, user interface flow diagrams, CRC, and so on. The data model is only one of them. Each model has its own strengths and weaknesses.
Correct use.

Misunderstanding 9: All developers know how to build models.

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 general programmers (of course, Senior programmers and general programmers ), they assume that all developers have the skills to develop the entire system from start to end.

Fact analysis: This is definitely incorrect. Modeling skills can be mastered only when a developer learns it and has been practicing it for a long time. Some very intelligent programmers often believe that they are omnipotent. After all, they are only programmers. Because of this arrogance, some of the tasks they undertake are simply not completed with the corresponding skills. Software development is so complex that it is difficult for a single person to have all the skills to successfully develop, or even to configure a complex system. Development should be self-aware, understand their own weaknesses, and there is no end to learning. By complementing each other, modelers can learn the details of a technology from programmers, and programmers can also learn valuable design and architecture technologies from modelers. I personally think that everyone, including myself, is a newbie.

Agile Modeling

By understanding and avoiding the misunderstanding of modeling, you can develop software more effectively by yourself, your project team, and your organization. I have already expressed many principles of Agile Modeling (AM) in the process of revealing these common mistakes. Agile Modeling is previously called Extreme Modeling (XM ). I hope that what I give you is spiritual food.

Here I would like to thank Doug Smith of Blueprint Technologies (http://www.blueprinttech.com), Gary Evans of Evanetics (http://www.evanetics.com), and those who have contributed to this article in the Agile Modeling mailing list (accessible to http://www.agilemodeling.com. I would also like to thank Martin Fowler, Ron Jeffries and some other members of the XP community because I think I have integrated some of their ideas.

Ten modeling principles

Only data models are not enough for modern software.
Receives changes and allows your model to be improved over time. You can't freeze them, and you will expect success.
A model is not necessarily a document, nor a document is a model.
Most models may also be discarded.
Only the code can be truly synchronized with the code.
Some simple tools, such as whiteboards, are enough to handle most modeling tasks.
Think, and then encode it.
You can always learn from others.
Modeling can be lightweight.
The design is not completed until the code is released.